📅 Original date posted:2015-12-08
📝 Original message:On Tuesday, December 08, 2015 11:40:42 PM Jonathan Toomim via bitcoin-dev
wrote:
> Agree. This data does not belong in the coinbase. That space is for miners
> to use, not devs.
This has never been guaranteed, nor are softforks a "dev action" in the first
place.
> 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.
How about we pursue the SegWit softfork, and at the same time* work on a
hardfork which will simplify the proofs and reduce the kludgeyness of merge-
mining in general? Then, if the hardfork is ready before the softfork, they
can both go together, but if not, we aren't stuck delaying the improvements of
SegWit until the hardfork is completed.
* I have been in fact working on such a proposal for a while now, since before
SegWit.
> 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.
There isn't an option for "no data", as non-upgraded nodes in a hardfork are
left completely vulnerable to attacking miners, even much lower hashrate than
the 51% attack risk. So the alternatives are:
- hardfork: complete loss of all security for the old nodes
- softfork: degraded security for old nodes
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 19:45:39
in reply to nevent1q…al02
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 19:45:39Event JSON
{
"id": "4d2ca85d95e0935516061cedc09b2339b8a18569f5702e9db5f602069265c4ca",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686159939,
"kind": 1,
"tags": [
[
"e",
"558b0da1f3869961bbef0556878e1dd6b9ae37e86128bc130bab17f5332c918d",
"",
"root"
],
[
"e",
"e8304636244a8359ae19c73b08f577809efb0a460eff0a0133093d74c866fc20",
"",
"reply"
],
[
"p",
"0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569"
]
],
"content": "📅 Original date posted:2015-12-08\n📝 Original message:On Tuesday, December 08, 2015 11:40:42 PM Jonathan Toomim via bitcoin-dev \nwrote:\n\u003e Agree. This data does not belong in the coinbase. That space is for miners\n\u003e to use, not devs.\n\nThis has never been guaranteed, nor are softforks a \"dev action\" in the first \nplace.\n\n\u003e I also think that a hard fork is better for SegWit, as it reduces the size\n\u003e of fraud proofs considerably, makes the whole design more elegant and less\n\u003e kludgey, and is safer for clients who do not upgrade in a timely fashion.\n\nHow about we pursue the SegWit softfork, and at the same time* work on a \nhardfork which will simplify the proofs and reduce the kludgeyness of merge-\nmining in general? Then, if the hardfork is ready before the softfork, they \ncan both go together, but if not, we aren't stuck delaying the improvements of \nSegWit until the hardfork is completed.\n\n* I have been in fact working on such a proposal for a while now, since before \nSegWit.\n\n\u003e I don't like the idea that SegWit would invalidate the security\n\u003e assumptions of non-upgraded clients (including SPV wallets). I think that\n\u003e for these clients, no data is better than invalid data. Better to force\n\u003e them to upgrade by cutting them off the network than to let them think\n\u003e they're validating transactions when they're not.\n\nThere isn't an option for \"no data\", as non-upgraded nodes in a hardfork are \nleft completely vulnerable to attacking miners, even much lower hashrate than \nthe 51% attack risk. So the alternatives are:\n- hardfork: complete loss of all security for the old nodes\n- softfork: degraded security for old nodes\n\nLuke",
"sig": "0c3f5573c18762e6418743df00d9594102f1f737de72a9e28ad2a0fa275fb0fd64582be96c2e533f7d858bf63c07e41a6a1047581b5cfc3408db1403e3f6ad73"
}