The economic policy’s status quo has been to avoid fee pressure. But the consensus status quo obviously is not to have a hard fork.
There’s clearly a contradiction between these two policies, which is a big part of the reason this issue has come to this point. These two policies are fundamentally at odds. - Eric Lombrozo > On Jun 27, 2015, at 4:04 AM, Jorge Timón <[email protected]> wrote: > > On Sat, Jun 27, 2015 at 12:29 PM, NxtChg <[email protected]> wrote: >> >> On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" <[email protected]> wrote: >> >>> Then you won't risk the other 'passengers' who don't consent to it. >> >> But you can look at it the other way: what about risking the 'passengers' >> when the plane suddenly doesn't fly anymore? >> >> Increasing block limit increases the risk of centralization, but it also >> keeps the current status quo of blocks not being filled, rather then risking >> an unknown option of hitting the limit hard. > > But that option is not unknown, that's the point of this thread. > "Doing nothing" would require to fix the mempool to scale with the > number of unconfirmed transaction. This is something that we will > eventually have to fix unless the plan is to eventually remove the > blocksize limit. > What will happen with full blocks is that fees will likely rise and > the transactions with bigger fees will get confirmed first. This is > something that will eventually happen unless the blocksize limit is > removed before ever being hit. > What this thread is saying is that this option (the so-called "doing > nothing" option, which actually requires more work than any of the > current proposals for increasing the blocksize) is perfectly valid, > which is in contradiction to a perceived "need to increase the > blocksize limit soon". Increasing the block size is only an option, > not a "need". And changing the consensus rules and forcing everybody > to adapt their software to the changes is certainly not "maintaining > the status quo", I'm getting tired of hearing that absurd notion. > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
