Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-27 📝 Original message:The economic policy’s ...
đź“… Original date posted:2015-06-27
📝 Original message: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 <jtimon at jtimon.cc> wrote:
>
> On Sat, Jun 27, 2015 at 12:29 PM, NxtChg <nxtchg at hush.com> wrote:
>>
>> On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" <laanwj at gmail.com> 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
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/8faed6e6/attachment-0001.sig>;
📝 Original message: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 <jtimon at jtimon.cc> wrote:
>
> On Sat, Jun 27, 2015 at 12:29 PM, NxtChg <nxtchg at hush.com> wrote:
>>
>> On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" <laanwj at gmail.com> 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
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/8faed6e6/attachment-0001.sig>;