Matt Whitlock [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-02 📝 Original message:Why do it as an OP_RETURN ...
📅 Original date posted:2015-06-02
📝 Original message:Why do it as an OP_RETURN output? It could be a simple token in the coinbase input script, similar to how support for P2SH was signaled among miners. And why should there be an explicit token for voting for the status quo? Simply omitting any indication should be an implicit vote for the status quo. A miner would only need to insert an indicator into their block if they wished for a larger block.
That said, proposals of this type have been discussed before, and the objection is always that miners would want larger blocks than the rest of the network could bear. Unless you want Bitcoin to become centralized in the hands of a few large mining pools, you shouldn't hand control over the block size limits to the miners.
On Sunday, 31 May 2015, at 3:04 pm, Stephen Morse wrote:
> This is likely very similar to other proposals, but I want to bring voting
> procedures back into the discussion. The goal here is to create a voting
> procedure that is as simple as possible to increase the block size limit.
>
> Votes are aggregated over each 2016 block period. Each coinbase transaction
> may have an output at tx.vout[0] with OP_RETURN data in it of the format:
>
> OP_RETURN {OP_1 or OP_2}
>
> OP_2 means the miner votes to increase the block size limit. OP_1 means the
> miner votes to not increase the block size limit. *Not including such a
> vote is equivalent to voting to NOT increase the block size. *I first
> thought that not voting should mean that you vote with your block size, but
> then decided that it would be too gameable by others broadcasting
> transactions to affect your block size.
>
> If in a 2016 block round there were more than 1008 blocks that voted to
> increase the block size limit, then the max block size increases by 500 kb.
> The votes can start when there is a supermajority of miners signaling
> support for the voting procedure.
>
> A few important properties of this simple voting:
>
> - It's not gameable via broadcasting transactions (assuming miners don't
> set their votes to be automatic, based on the size of recent blocks).
> - Miners don't have to bloat their blocks artificially just to place a
> vote for larger block sizes, and, similarly, don't need to exclude
> transactions even when they think the block size does not need to be raised.
> - The chain up until the point that this goes into effect may be
> interpreted as just lacking votes to increase the block size.
>
> We can't trust all miners, but we have to trust that >50% of them are
> honest for the system to work. This system makes it so that altering the
> maximum block size requires >50% of miners (hash power) to vote to increase
> the consensus-limit.
>
> Thanks for your time. I think this is an important time in Bitcoin's
> history. I'm not married to this proposal, but I think it would work. I
> think a lot of the proposals mentioned on this mailing list would work. I
> think it's time we just pick one and run with it.
>
> Please let me know your thoughts. I will start working on a pull request if
> this receives any support from miners/core devs/community members, unless
> someone with more experience volunteers.
>
> Best,
> Stephen
Published at
2023-06-07 15:36:31Event JSON
{
"id": "96c0100253199df32baac71eb21170872ea8fcfe13268997c47079492c406afc",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686152191,
"kind": 1,
"tags": [
[
"e",
"3d1ec264de3f692858c8c6e2d21675624efe6b3d119ec3523f92a80da82b7c07",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-06-02\n📝 Original message:Why do it as an OP_RETURN output? It could be a simple token in the coinbase input script, similar to how support for P2SH was signaled among miners. And why should there be an explicit token for voting for the status quo? Simply omitting any indication should be an implicit vote for the status quo. A miner would only need to insert an indicator into their block if they wished for a larger block.\n\nThat said, proposals of this type have been discussed before, and the objection is always that miners would want larger blocks than the rest of the network could bear. Unless you want Bitcoin to become centralized in the hands of a few large mining pools, you shouldn't hand control over the block size limits to the miners.\n\n\nOn Sunday, 31 May 2015, at 3:04 pm, Stephen Morse wrote:\n\u003e This is likely very similar to other proposals, but I want to bring voting\n\u003e procedures back into the discussion. The goal here is to create a voting\n\u003e procedure that is as simple as possible to increase the block size limit.\n\u003e \n\u003e Votes are aggregated over each 2016 block period. Each coinbase transaction\n\u003e may have an output at tx.vout[0] with OP_RETURN data in it of the format:\n\u003e \n\u003e OP_RETURN {OP_1 or OP_2}\n\u003e \n\u003e OP_2 means the miner votes to increase the block size limit. OP_1 means the\n\u003e miner votes to not increase the block size limit. *Not including such a\n\u003e vote is equivalent to voting to NOT increase the block size. *I first\n\u003e thought that not voting should mean that you vote with your block size, but\n\u003e then decided that it would be too gameable by others broadcasting\n\u003e transactions to affect your block size.\n\u003e \n\u003e If in a 2016 block round there were more than 1008 blocks that voted to\n\u003e increase the block size limit, then the max block size increases by 500 kb.\n\u003e The votes can start when there is a supermajority of miners signaling\n\u003e support for the voting procedure.\n\u003e \n\u003e A few important properties of this simple voting:\n\u003e \n\u003e - It's not gameable via broadcasting transactions (assuming miners don't\n\u003e set their votes to be automatic, based on the size of recent blocks).\n\u003e - Miners don't have to bloat their blocks artificially just to place a\n\u003e vote for larger block sizes, and, similarly, don't need to exclude\n\u003e transactions even when they think the block size does not need to be raised.\n\u003e - The chain up until the point that this goes into effect may be\n\u003e interpreted as just lacking votes to increase the block size.\n\u003e \n\u003e We can't trust all miners, but we have to trust that \u003e50% of them are\n\u003e honest for the system to work. This system makes it so that altering the\n\u003e maximum block size requires \u003e50% of miners (hash power) to vote to increase\n\u003e the consensus-limit.\n\u003e \n\u003e Thanks for your time. I think this is an important time in Bitcoin's\n\u003e history. I'm not married to this proposal, but I think it would work. I\n\u003e think a lot of the proposals mentioned on this mailing list would work. I\n\u003e think it's time we just pick one and run with it.\n\u003e \n\u003e Please let me know your thoughts. I will start working on a pull request if\n\u003e this receives any support from miners/core devs/community members, unless\n\u003e someone with more experience volunteers.\n\u003e \n\u003e Best,\n\u003e Stephen",
"sig": "745d7f27bc33b65156521e37f49388d6a0aed3843ad975e62d97c7e465825ad6918b7622ec7903a00e9af9df7a5c6adcdb9edc8e9ea520a235f2f29b2ca3ff78"
}