📅 Original date posted:2015-12-08 📝 Original message:On Dec 9, 2015 7:41 AM, ...

Jorge Timón [ARCHIVE] /

npub1fx9…l2d8

2023-06-07 17:45:39

in reply to nevent1q…2ac2

📅 Original date posted:2015-12-08
📝 Original message:On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> 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 agree, although I disagree with the last reason.

> 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.

I don't undesrtand. SPV nodes won't think they are validating transactions
with the new version unless they adapt to the new format. They will be
simply unable to receive payments using the new format if it is a softfork
(although as said I agree with making it a hardfork on the simpler design
and smaller fraud proofs grounds alone).

>
> 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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/2af9dc6d/attachment.html>;

Author Public Key

npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8

Show more details

Published at

2023-06-07 17:45:39

Kind type

1 Short Text Note

Event JSON

{ "id": "326443ebf6978b7c1dcc408a41165afb12fd718b34cb60dc1be8c84109931706", "pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84", "created_at": 1686159939, "kind": 1, "tags": [ [ "e", "558b0da1f3869961bbef0556878e1dd6b9ae37e86128bc130bab17f5332c918d", "", "root" ], [ "e", "9b4d62810e5ad106b647df60ee92fe80c6ed5b9d519163e736a707c557a61ea8", "", "reply" ], [ "p", "0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569" ] ], "content": "📅 Original date posted:2015-12-08\n📝 Original message:On Dec 9, 2015 7:41 AM, \"Jonathan Toomim via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I also think that a hard fork is better for SegWit, as it reduces the\nsize of fraud proofs considerably, makes the whole design more elegant and\nless kludgey, and is safer for clients who do not upgrade in a timely\nfashion.\n\nI agree, although I disagree with the last reason.\n\n\u003e I don't like the idea that SegWit would invalidate the security\nassumptions of non-upgraded clients (including SPV wallets). I think that\nfor these clients, no data is better than invalid data. Better to force\nthem to upgrade by cutting them off the network than to let them think\nthey're validating transactions when they're not.\n\nI don't undesrtand. SPV nodes won't think they are validating transactions\nwith the new version unless they adapt to the new format. They will be\nsimply unable to receive payments using the new format if it is a softfork\n(although as said I agree with making it a hardfork on the simpler design\nand smaller fraud proofs grounds alone).\n\n\u003e\n\u003e On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e \u003e If such a change is going to be deployed via a soft fork instead of a\n\u003e \u003e hard fork, then the coinbase is the worst place to put the segwitness\n\u003e \u003e merkle root.\n\u003e \u003e\n\u003e \u003e Instead, put it in the first output of the generation transaction as an\n\u003e \u003e OP_RETURN script.\n\u003e \u003e\n\u003e \u003e This is a better pattern because coinbase space is limited while output\n\u003e \u003e space is not. The next time there's a good reason to tie another merkle\n\u003e \u003e tree to a block, that proposal can be designated for the second output\n\u003e \u003e of the generation transaction.\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/2af9dc6d/attachment.html\u003e", "sig": "0e4567ad40ffb176361181fc624c39bc8e42a6c6d1e7038de633cd00163ff653ad29edf419b5530db7499f52fbb195a17dd2300f5c2c3feed9ea43affa805a81" }