📅 Original date posted:2015-12-08
📝 Original message:Agree. This data does not belong in the coinbase. That space is for miners to use, not devs.
I also think that a hard fork is better for SegWit, as it reduces the size of fraud proofs considerably, makes the whole design more elegant and less kludgey, and is safer for clients who do not upgrade in a timely fashion. I don't like the idea that SegWit would invalidate the security assumptions of non-upgraded clients (including SPV wallets). I think that for these clients, no data is better than invalid data. Better to force them to upgrade by cutting them off the network than to let them think they're validating transactions when they're not.
On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> If such a change is going to be deployed via a soft fork instead of a
> hard fork, then the coinbase is the worst place to put the segwitness
> merkle root.
>
> Instead, put it in the first output of the generation transaction as an
> OP_RETURN script.
>
> This is a better pattern because coinbase space is limited while output
> space is not. The next time there's a good reason to tie another merkle
> tree to a block, that proposal can be designated for the second output
> of the generation transaction.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/a4037777/attachment.sig>;
Jonathan Toomim [ARCHIVE] /
npub1pl…yj0hj
2023-06-07 17:45:39
in reply to nevent1q…5l4w
Author Public Key
npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hjPublished at
2023-06-07 17:45:39Event JSON
{
"id": "e8304636244a8359ae19c73b08f577809efb0a460eff0a0133093d74c866fc20",
"pubkey": "0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569",
"created_at": 1686159939,
"kind": 1,
"tags": [
[
"e",
"558b0da1f3869961bbef0556878e1dd6b9ae37e86128bc130bab17f5332c918d",
"",
"root"
],
[
"e",
"f5b84d341a9f3b2e14696a0e87dcbc7f65020407440332d8071f0586ebe1da62",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2015-12-08\n📝 Original message:Agree. This data does not belong in the coinbase. That space is for miners to use, not devs.\n\nI also think that a hard fork is better for SegWit, as it reduces the size of fraud proofs considerably, makes the whole design more elegant and less kludgey, and is safer for clients who do not upgrade in a timely fashion. I don't like the idea that SegWit would invalidate the security assumptions of non-upgraded clients (including SPV wallets). I think that for these clients, no data is better than invalid data. Better to force them to upgrade by cutting them off the network than to let them think they're validating transactions when they're not.\n\n\nOn Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e If such a change is going to be deployed via a soft fork instead of a\n\u003e hard fork, then the coinbase is the worst place to put the segwitness\n\u003e merkle root.\n\u003e \n\u003e Instead, put it in the first output of the generation transaction as an\n\u003e OP_RETURN script.\n\u003e \n\u003e This is a better pattern because coinbase space is limited while output\n\u003e space is not. The next time there's a good reason to tie another merkle\n\u003e tree to a block, that proposal can be designated for the second output\n\u003e of the generation transaction.\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/a4037777/attachment.sig\u003e",
"sig": "ccf9ce6e48b3509adc5916a4caea0d0cd8745bfe6ac495972dfaa60908c576413f37864843d2a68d489172c18afcf0396ee5b27725d8f2e44f739fc12b1a5d23"
}