📅 Original date posted:2015-06-12
📝 Original message:Why should miners only be able to vote for "double the limit" or "halve" the limit? If you're going to use bits, I think you need to use two bits:
0 0 = no preference ("wildcard" vote)
0 1 = vote for the limit to remain the same
1 0 = vote for the limit to be halved
1 1 = vote for the limit to be doubled
User transactions would follow the same usage. In particular, a user vote of "0 0" (no preference) could be included in a block casting any vote, but a block voting "0 0" (no preference) could only contain transactions voting "0 0" as well.
Incidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users.
On Friday, 12 June 2015, at 2:11 pm, Peter Todd wrote:
> Jeff Garzik recently proposed that the upper blocksize limit be removed
> entirely, with a "soft" limit being enforced via miner vote, recorded by
> hashing power.
>
> This mechanism within the protocol for users to have any influence over
> the miner vote. We can add that back by providing a way for transactions
> themselves to set a flag determining whether or not they can be included
> in a block casting a specific vote.
>
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by some
> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> nVersion bit in transactions themselves, also voting for an increase or
> decrease. Transactions may only be included in blocks with an
> indentical vote, thus providing miners with a monetary incentive via
> fees to vote according to user wishes.
>
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions. Equally we
> can even have different versions with different fees, broadcast via a
> mechanism such as replace-by-fee.
>
>
> See also John Dillon's proposal for proof-of-stake blocksize voting:
>
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:37:28
in reply to nevent1q…7r7j
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetPublished at
2023-06-07 15:37:28Event JSON
{
"id": "f7313900e4fa268b8ac3799dfaed06b674e8ac32fe7536440f07dab089f0dde5",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686152248,
"kind": 1,
"tags": [
[
"e",
"8a807127e1ae5b585bcc8f3578413a7d3eb1bd30e75c19cd4a3a0a256adcb61c",
"",
"root"
],
[
"e",
"cc8f74e2be7a56edd0e7d86f6c07a659632e9411a48fcf3d2a97b0bb05802334",
"",
"reply"
],
[
"p",
"f05699fae959fb582a8bd56a55b613bafd61c2c239a00bc5ea66faf0cb7a2aa8"
]
],
"content": "📅 Original date posted:2015-06-12\n📝 Original message:Why should miners only be able to vote for \"double the limit\" or \"halve\" the limit? If you're going to use bits, I think you need to use two bits:\n\n\t0 0 = no preference (\"wildcard\" vote)\n\t0 1 = vote for the limit to remain the same\n\t1 0 = vote for the limit to be halved\n\t1 1 = vote for the limit to be doubled\n\nUser transactions would follow the same usage. In particular, a user vote of \"0 0\" (no preference) could be included in a block casting any vote, but a block voting \"0 0\" (no preference) could only contain transactions voting \"0 0\" as well.\n\nIncidentally, I love this idea, as it addresses a concern I immediately had with Jeff's proposal, which is that it hands control exclusively to the miners. And your proposal here fixes that shortcoming in a economically powerful way: miners lose out on fees if they don't represent the wishes of the users.\n\n\nOn Friday, 12 June 2015, at 2:11 pm, Peter Todd wrote:\n\u003e Jeff Garzik recently proposed that the upper blocksize limit be removed\n\u003e entirely, with a \"soft\" limit being enforced via miner vote, recorded by\n\u003e hashing power.\n\u003e \n\u003e This mechanism within the protocol for users to have any influence over\n\u003e the miner vote. We can add that back by providing a way for transactions\n\u003e themselves to set a flag determining whether or not they can be included\n\u003e in a block casting a specific vote.\n\u003e \n\u003e We can simplify Garzik's vote to say that one of the nVersion bits\n\u003e either votes for the blocksize to be increased, or decreased, by some\n\u003e fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a\n\u003e nVersion bit in transactions themselves, also voting for an increase or\n\u003e decrease. Transactions may only be included in blocks with an\n\u003e indentical vote, thus providing miners with a monetary incentive via\n\u003e fees to vote according to user wishes.\n\u003e \n\u003e Of course, to cast a \"don't care\" vote we can either define an\n\u003e additional bit, or sign the transaction with both versions. Equally we\n\u003e can even have different versions with different fees, broadcast via a\n\u003e mechanism such as replace-by-fee.\n\u003e \n\u003e \n\u003e See also John Dillon's proposal for proof-of-stake blocksize voting:\n\u003e \n\u003e https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html\n\u003e \n\u003e -- \n\u003e 'peter'[:-1]@petertodd.org\n\u003e 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778",
"sig": "dfff17d757942ed80a785a3f551ee77032e632ffe3cda1c6d1c4fe63361e83efe06f211aa556a8550537351d6eb6a9f1490db00be8515dbd7c851017b85e96ff"
}