📅 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.
>
I don't really care the exact location it's put in. I just thought there
wasn't an explicit need to put it in the header (via a bit of nVersion),
and the scriptSig is already used for many things (block height, merged
mining hash, "\"P2SH\"", miner identifier). And voting to keep the block
size the same by not voting is fine by me.
> 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.
>
Yeah, that was the conclusion we came to chatting on #bitcoin-wizards the
other day. I now think that this could be useful to dynamically increase a
lower limit, but that there should still be a hard upper limit like 20 MB.
I think that just changing the upper limit might be simpler and better,
though.
- Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150602/71c4ecb9/attachment.html>;
Stephen Morse [ARCHIVE] /
npub1ja…q0j2u
2023-06-07 15:36:32
in reply to nevent1q…d8yp
Author Public Key
npub1ja0fa5k6j04r2h7jp33lvdy2kzpv5yj60ce4wvcca7fvxe99hw5qqq0j2uPublished at
2023-06-07 15:36:32Event JSON
{
"id": "759810d36169be9c3e091b349564db8c101c62243bda268c6554a116a89b2d94",
"pubkey": "975e9ed2da93ea355fd20c63f6348ab082ca125a7e33573318ef92c364a5bba8",
"created_at": 1686152192,
"kind": 1,
"tags": [
[
"e",
"3d1ec264de3f692858c8c6e2d21675624efe6b3d119ec3523f92a80da82b7c07",
"",
"root"
],
[
"e",
"96c0100253199df32baac71eb21170872ea8fcfe13268997c47079492c406afc",
"",
"reply"
],
[
"p",
"f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91"
]
],
"content": "📅 Original date posted:2015-06-02\n📝 Original message:\u003e\n\u003e Why do it as an OP_RETURN output? It could be a simple token in the\n\u003e coinbase input script, similar to how support for P2SH was signaled among\n\u003e miners. And why should there be an explicit token for voting for the status\n\u003e quo? Simply omitting any indication should be an implicit vote for the\n\u003e status quo. A miner would only need to insert an indicator into their block\n\u003e if they wished for a larger block.\n\u003e\n\nI don't really care the exact location it's put in. I just thought there\nwasn't an explicit need to put it in the header (via a bit of nVersion),\nand the scriptSig is already used for many things (block height, merged\nmining hash, \"\\\"P2SH\\\"\", miner identifier). And voting to keep the block\nsize the same by not voting is fine by me.\n\n\n\u003e That said, proposals of this type have been discussed before, and the\n\u003e objection is always that miners would want larger blocks than the rest of\n\u003e the network could bear. Unless you want Bitcoin to become centralized in\n\u003e the hands of a few large mining pools, you shouldn't hand control over the\n\u003e block size limits to the miners.\n\u003e\n\nYeah, that was the conclusion we came to chatting on #bitcoin-wizards the\nother day. I now think that this could be useful to dynamically increase a\nlower limit, but that there should still be a hard upper limit like 20 MB.\nI think that just changing the upper limit might be simpler and better,\nthough.\n\n- Stephen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150602/71c4ecb9/attachment.html\u003e",
"sig": "f26301748b2910a7cb825d60c7eb4be216f541aa6b62dfe1cb018211389a14407dfbb8a051ac4cc6634eaa3225131c0f26dcaf15d0e3219c772e48c55012f25a"
}