Topic: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) - page 52. (Read 378992 times)

Just in case some plan for a "reasonable" block size increase (not 101) will be agreed to after the HK workshop, I'd like to humbly make a suggestion.

I can imagine some of the pro-XT/pro-101 people will want to claim "victory." If so, please consider just letting them claim victory. They've had a tough year. They clearly thought they were the majority, and the lack of XT adoption is clear evidence that they're wrong about this. Maybe it would help heal the community to let them dance on the 1MB grave for a bit, even if they're not getting what they really want.

Just to be clear, if the experts honestly believe raising the block size limit is a bad idea, I hope they don't give in the for the sake of "bringing the community together." But if a compromise is reached, fine, let's try to be nice to the people who wanted something "unlimited."

To answer your first question, you're right the average page is not 2MB, it is actually larger. 2099 KB to be precise.

http://www.soasta.com/wp-content/uploads/2015/06/page-bloat-feature.png

A webpage of 2Mb? Did gavin smoked something? I can't even think of a normal HTML/PHP page that is of 2Mb..... And i agree with what Nick Sza-toshi-bo told, because at the end, is what is going to happen with the increased block size

Yup, "be your own bank" imply running a bitcoin client by yourself, so that you actually dont rely on third parties.

Else, as Nick Sza-toshi-bo highlighted:

 

Well that one heck of a problem in fact.... everybody tries only to see the increase of size like if everybody already have the blockchain downloaded without thinking to who still doesn't have the wallet synced and have to download all that

In practice, imagine the pain for newcomers to just download the whole 50Gb blockchain, and despite all the cherry picking and sterile dialectic about general bandwidth evolution.

People arguing for bigger blocks at such stage in bitcoin existence are either corporatist shills or braindead morons. (opinion ergo fact ^^)

Thanks for the response Greg. Looks like I have some reading to do wrt mempool changes. Any thoughts on Wang Chun's suggested schedule?

Not so much, in that the fee required to get into the mempool in the first place goes up as transactions are dropped out; at least with the limited mempool in 0.12.  To the extent that a bigger block makes spam attacks more expensive it's only really through the action of making it much cheaper to inflict additional storage-in-perpetuity on the network. So far, the non-trivially funded spam attacks that we've seen have not been successful in driving the feel levels required to bypass them above negligible cents per transaction levels (e.g. significantly cheaper than what credit card networks charge merchants per transaction).... though obviously this has limits.

Right now, measuring the differential time it takes for mining pools to switch the blocks they're working on vs block size suggests an effective transfer rate of 723kbit/sec (less shockingly slow when you consider how inefficient TCP is for bursty conditions across links with worldwide latency), This is the amount of time it took for a block to reach half the monitored public pool's stratum endpoints after reaching the first one vs blocksize:  https://people.xiph.org/~greg/sp2.png  (Matt more recently did a similar measurement of relay network behavior and reached a similar but somewhat lower throughput).   If you take that offset (2.491s) and data rate, and drop it into formula for subsidy income loss cost for the last byte of a megabyte block, the break-even feerate is 0.00045054 BTC/KB. So that suggests that at least lower hashrate miners are accepting transactions at a price low enough to be a net-loss currently. (It may not be the case; e.g. if the low hashrate miners are all fast. and the high hashrate miners are all slow, or low hashrate doesn't process as many transactions; and the data is all over the map... etc.)

Bigger blocks (with at least some reasonable upper bound) make spam attacks more expensive, as tx's drop out of the mempool and fees can be recycled continuously. The point is not moot, because as we see now, even when the incentive to bloat blocks does exist, we aren't seeing it. This change would make it a more expensive proposition for the potential spammer. 

Except we all know that it is the same charlatans that have been pressuring the miners to include more transactions and create max-block-size blocks on average. - Who are also pressuring to increase the same max-block-size limit.

So the argument about max-size vs actual-size is a bit of a moot-point, really.

I probably don't need to remind you that max != actual, just like today. If luke doesn't have better internet in 2019 he'll have some splainin' to do.

This dose nothing to alleviate the genuine concerns of Luke Jr, and other Bitcoin Engineers that have good evidence and reason to believe that the 750kb blocks that we have now are already hitting the block size scaling limits that the network can safely manage.

People who propose such large blocks, such as 2mb or 4mb, never seem to address the concerns that the Bitcoin Network is *already* struggling under present loads.

First the fee market. People already pay fees, and blocks are 60-70%(?) or so to capacity on avg. (fudging a bit for reward only blocks). They will continue to do so with blocks smaller than max, as seen today. More of them, more fees. It really comes down to whether we force the fee market artificially now (soon), or let the miners set the prices for their services. Doing nothing, staying at 1MB max, is doing something, implementing an artificial fee market at 25 or 12.5 btc per block. This is a change from the state of the network up until now. And too early imo.

Impact on the decentralized node network is a valid concern, and I'm not dismissing it, that's why I'm liking this much more conservative proposal. It seems the reward schedule looks like it does, front loaded, in order to act as a sort of launching subsidy. This allows the network to grow faster than if all mining costs were placed directly on the user, ~$5 or more per tx. This can't have been an afterthought on satoshi's part, to me, it means grow as fast as possible (while maintaining a sufficiently wide attack surface) into the 2020's.

4MB blocks going towards 2020 seems like it's leaning towards protecting decentralization vs growth at all costs. And it's a number I bet most BIP101 fans would find absurdly small. As polarized as this debate has been, I think the winning proposal should be the one that equalizes displeasure between the XT-Unlimited and 1MB4EVA camps. Doubling max block size in tandem with halvings mimics and compliments the simplicity and predictability of the reward schedule. 

Gregory, that was only Hearn. In-fact Gavin said that he thinks that scenario is far-fetched (I am paraphrasing I can not remember the exact words). Gavin also said that he thinks Bitcoin will be successful either way.


As an aside, I wonder if there is a need for a PR person or liason for core development. Somebody who has decent technical knowledge but can devote most of their time to informing community of what is going on with development and its direction.

(yes all the information is already there in mailing lists, github etc. but it needs to be in easily digestible format, in locations where people will read it)


Many in the Bitcoin ecosystem have no knowledge about the direction of Bitcoin development. Thats actually a problem when talking about such a big economy. There is a gap between developers and eco-system. People need a long term vision to know where we stand and where we going. To many the changes come as total surprise, seemingly from up above.

People dont like surprises (in this context).

Implemented in Bitcoin Core git master a couple months ago, will be in 0.12; along with many other resource control tools. Though if widely used it will further congest getting blocks to begin with. It's a good trade-off, but not without costs. None of this is magic: cutting down this source of traffic or that is mostly just constant factor reductions. To operate the system needs a safety margin, and we're bumping up against actual limits.

You weren't looking hard enough , it's called -maxuploadtarget   see also doc/reduce-traffic.md (though not all of the features are documented yet).   (amusingly, this was one of the relatively few PR's that Mike Hearn commented on-- opposing it.)

This was one of the big fallacies involved in the "crash landing" spin by Gavin and Hearn; this notion that Bitcoin would willfully commit suicide.  Cranking the scale ahead of addressing scaliablity is/was controversial (not just among the most technical, though it's nearly universal there); but if it were strongly _necessary_, and better than the harm of not; then it would no longer be. That we're not there now, shows it isn't. QED.  And there is a tone of activity gone on to improve scalablity at all levels of the system, from micro optimizations, to protocol design.

Meet the new thermos.  Same as the old thermos.

lol rekt

This could cut either way and one is disastrous for security:

1) If the block space is being fully-utilised and the fee-market is producing optimal returns based on full blocks then doubling the block size at the same time as halving the reward would be a double whammy for miners as more blockspace will lead to a drop off in fees at the same time reward is halved.

2) the other way is speculative but what big-blockers use as an argument, block size doubles and miraculously fees do not drop but the number of transactions goes up so sweet nirvana, bigger blocks brings in more total fees.

Lots more here to think about than simply making blocks bigger. Fees need to pay increasingly for security out into the future and blocks cannot grow faster than the technological progress that can accommodate them on a sufficiently decentralised network. It seems there is probably an optimum blocksize for bringing in the maximal total fees and another optimum blocksize that maximises network decentralisation. Those two criteria are not necessarily compatible and neither of those two criteria maybe fully observable variables given the input metric data internally available to the network (in a control theoretic system analysis).

https://bitcoinmagazine.com/articles/bitcoin-mining-pool-f-pool-discus-fish-maintains-bip-not-an-option-1449003767

"On the Bitcoin development mailing list, Chun recently suggested raising the maximum block size in accordance with the block halving. As such, the block-size limit would be raised to 2 megabytes as soon as possible, followed by an increase to 4 megabytes halfway through 2016, up to 32 megabytes by 2028."

Hehe notice now the kids supplicating for daddy /u/memorydealers to come over and wave his magic freedom wand. Pathetic. ^^

XT was never going to work. The spirit of bitcoin lives within. XT Cannot exist when everyone has tasted the wonders of p2p.