📅 Original date posted:2015-05-13
📝 Original message:On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine <voisine at gmail.com> wrote:
> Conservative is a relative term. Dropping transactions in a way that is
> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
> increasing the blocksize, drastic as it is, is the more conservative choice.
>
Transactions are already being dropped, in a more indirect way: by people
and businesses deciding to not use on-chain settlement. That is very sad,
but it's completely inevitable that there is space for some use cases and
not for others (at whatever block size). It's only a "things don't fit
anymore" when you see on-chain transactions as the only means for doing
payments, and that is already not the case. Increasing the block size
allows for more utility on-chain, but it does not fundamentally add more
use cases - only more growth space for people already invested in being
able to do things on-chain while externalizing the costs to others.
> I would recommend that the fork take effect when some specific large
> supermajority of the pervious 1000 blocks indicate they have upgraded, as a
> safer alternative to a simple flag date, but I'm sure I wouldn't have to
> point out that option to people here.
>
That only measures miner adoption, which is the least relevant. The
question is whether people using full nodes will upgrade. If they do, then
miners are forced to upgrade too, or become irrelevant. If they don't, the
upgrade is risky with or without miner adoption.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/e909c936/attachment.html>;
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:34:47
in reply to nevent1q…dm7k
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:34:47Event JSON
{
"id": "ea5a58ea75a6f3d5084c3e01894ee9de604e1fcdc37fb0214667f974f34a7261",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686152087,
"kind": 1,
"tags": [
[
"e",
"4fca8766cb3622944ad3338913b2eaab58533c317983b04a538d878303c3c989",
"",
"root"
],
[
"e",
"7c6e2fb933bc9feb59b2e6e005d83299c3f875bf2340444a448aad0f1c1d03d4",
"",
"reply"
],
[
"p",
"3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3"
]
],
"content": "📅 Original date posted:2015-05-13\n📝 Original message:On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine \u003cvoisine at gmail.com\u003e wrote:\n\n\u003e Conservative is a relative term. Dropping transactions in a way that is\n\u003e unpredictable to the sender sounds incredibly drastic to me. I'm suggesting\n\u003e increasing the blocksize, drastic as it is, is the more conservative choice.\n\u003e\n\nTransactions are already being dropped, in a more indirect way: by people\nand businesses deciding to not use on-chain settlement. That is very sad,\nbut it's completely inevitable that there is space for some use cases and\nnot for others (at whatever block size). It's only a \"things don't fit\nanymore\" when you see on-chain transactions as the only means for doing\npayments, and that is already not the case. Increasing the block size\nallows for more utility on-chain, but it does not fundamentally add more\nuse cases - only more growth space for people already invested in being\nable to do things on-chain while externalizing the costs to others.\n\n\n\u003e I would recommend that the fork take effect when some specific large\n\u003e supermajority of the pervious 1000 blocks indicate they have upgraded, as a\n\u003e safer alternative to a simple flag date, but I'm sure I wouldn't have to\n\u003e point out that option to people here.\n\u003e\n\nThat only measures miner adoption, which is the least relevant. The\nquestion is whether people using full nodes will upgrade. If they do, then\nminers are forced to upgrade too, or become irrelevant. If they don't, the\nupgrade is risky with or without miner adoption.\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150513/e909c936/attachment.html\u003e",
"sig": "65f53a8f9c2c46492f2a4598e86b804dedfc8b017170b53799eee9765a4373c4cb1d620f4d8614ff53d4d73e0e01caeda7625cc751695219d7d58047a07f260f"
}