📅 Original date posted:2015-06-27
📝 Original message: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.
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 15:40:39
in reply to nevent1q…jpsh
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 15:40:39Event JSON
{
"id": "56225daea3bb2a6a1ff0e39dd31ea9d551817654b123536f845f75fd5244ab89",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686152439,
"kind": 1,
"tags": [
[
"e",
"6b97b8772e4c3c0f5eb751746063b4217197a3eb7cab2fa3b16264082ad573c4",
"",
"root"
],
[
"e",
"87ec76a5805601c4a48532942ed33570ea595e7b56c9ac71b843147ebebf1eca",
"",
"reply"
],
[
"p",
"238bb115101f2c05433c2b8aefc80ed5b4af9d3ff844748859d7a2298b116b49"
]
],
"content": "📅 Original date posted:2015-06-27\n📝 Original message:On Sat, Jun 27, 2015 at 12:29 PM, NxtChg \u003cnxtchg at hush.com\u003e wrote:\n\u003e\n\u003e On 6/27/2015 at 1:04 PM, \"Wladimir J. van der Laan\" \u003claanwj at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e Then you won't risk the other 'passengers' who don't consent to it.\n\u003e\n\u003e But you can look at it the other way: what about risking the 'passengers' when the plane suddenly doesn't fly anymore?\n\u003e\n\u003e 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.\n\nBut that option is not unknown, that's the point of this thread.\n\"Doing nothing\" would require to fix the mempool to scale with the\nnumber of unconfirmed transaction. This is something that we will\neventually have to fix unless the plan is to eventually remove the\nblocksize limit.\nWhat will happen with full blocks is that fees will likely rise and\nthe transactions with bigger fees will get confirmed first. This is\nsomething that will eventually happen unless the blocksize limit is\nremoved before ever being hit.\nWhat this thread is saying is that this option (the so-called \"doing\nnothing\" option, which actually requires more work than any of the\ncurrent proposals for increasing the blocksize) is perfectly valid,\nwhich is in contradiction to a perceived \"need to increase the\nblocksize limit soon\". Increasing the block size is only an option,\nnot a \"need\". And changing the consensus rules and forcing everybody\nto adapt their software to the changes is certainly not \"maintaining\nthe status quo\", I'm getting tired of hearing that absurd notion.",
"sig": "38b008aca02b954993c8776ca8b6b5c3c814a4d74b54da49b4e6da157ac235fd7c003a8cfc920184e5f6f58952e980ad5c29376ef085a63a9b9ca5ec6a565845"
}