I disagree. I think all client-side adoption of SW reliably tells you is that those implementers saw value in it greater than the cost of implementation. It's possible what they valued was the malleability fix and didn't see the limited potential circumvention of MAX_BLOCK_SIZE material to their decision.
They could just as easily attach an OP_RETURN output to all of their transactions which pushes "big blocks please" which would more directly indicate their preference for larger blocks. You could also let hand-signed letters from the heads of businesses explicitly stating their desire speak for their intentions vs. any of this nonsense. Or the media interviews, forum comments, tweets, etc... 19.12.2015, 20:43, "Peter Todd via bitcoin-dev" <[email protected]>: > On Sat, Dec 19, 2015 at 11:49:25AM -0500, jl2012 via bitcoin-dev wrote: >> I have done some calculation for the effect of a SW softfork on the >> actual total block size. > > Note how the fact that segwit needs client-side adoption to enable an > actual blocksize increase can be a good thing: it's a clear sign that > the ecosystem as a whole has opted-into a blocksize increase. > > Not as good as a direct proof-of-stake vote, and somewhat coercive as a > vote as you pay lower fees, but it's an interesting side-effect. > > -- > 'peter'[:-1]@petertodd.org > 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d > , > > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
