You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
After researching the issue, chatting w @LukeDashjr and touching base w @pyskell, I support both Bitcoin & ETC efforts to reduce block sizes to align chain growth w long term average bandwidth growth so chain download times do not stretch excluding users from running full nodes.
Bandwidth growth is not very predictable, and demand for transactions (and thus for such bandwidth) far less still.
Bandwidth growth may not be *precisely* predictable, but there are reasonable expectations. Demand for transactions should not be a factor in such limits at all.
Luke, what do you think of Dash's system for remunerating full nodes? This debate is consequent of a glaring (but perhaps unsolvable) imperfection where miners and exchanges earn (at 2 different levels) transaction fees but full nodes don't. Dash claims to have solved this.
I haven't looked at Dash specifically, but it seems difficult. After all, it's not merely running full nodes that needs to happen, but using your own to verify payments to you. It's hard to prove this.
Having your own full node to verify payments received is incentive compatible *if* either you have frequent large payments incoming or you've already funded your node by other means (like Dash?), making the ability to .verify small or uncommon incoming payments icing on the cake.
I haven't seen anybody look into this particular Dash feature in any sufficient detail though.
That wasn't an argument for a larger block size, or even to not reduce the block size. It may be an argument for an algorithmically adaptable block size, if such is possible.
I also want to add that burstable internet speed != available bandwidth capacity. It is industry standard for telecoms to overcommit, similar to fractional reserve.
A 100mbit internet connection doesn’t guarantee 100mbit connectivity. It’s *up to* 100mbits. When upstream connections become saturated, downstream speeds are impacted.
yeah, i expressed myself incorrectly...should have stated that I just have a 100-mbps 'plan' from Century Link, nothing more than a promise!! [just as a datapoint they upgraded us to 'fiber' and will have 5G in the early rounds of the rollout, but don't know when]
Why not fix initial sync by utxo set digest commitment on chain at certain intervals enforced in protocol? Why do we need to download full chain, instead of just the details for the outstanding utxo set at certain heights? Is this technically impossible?
The protocol doesn't and can't enforce anything itself - nodes need to enforce the protocol. If you don't download the full chain, you cannot verify the commitment, and therefore cannot enforce it. If you trust the UTXO set commitment, you are BLINDLY trusting miners.
Miners can change the rules at will. So, there's no 21MBTC limit - inflation is possible. Your private keys are also worthless if miners decide to take your bitcoins. Etc.
That's why, fixing the initial sync issues for everybody once and for all should be the top priority. Any method that my feeble mind can't comprehend, that would allow trustless kick-start of a pruned node would allow even cell phones to be nodes.
"fixing the initial sync issues for everybody once and for all should be the top priority"
fascinating that @LukeDashjr proposes a block reduction to slow chain growth and that @NickSzabo4 is thinking of full node incentives thru compensation models.
interesting times!
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
