📅 Original date posted:2015-09-28
📝 Original message:Perhaps Adam won't go into the rationale...but I think it is important we clarify this.
For better or worse, the only "voting" system available to Bitcoin that cannot be trivially attacked is hashing power. Soft forks are essentially miner-enforced rule changes...rules they could have decided to enforce without the consensus of anyone else. For instance, as far as old nodes are concerned, a p2sh output can be redeemed by a simple preimage of the hash...with no signatures. The point, however, is that as long as the majority of hashpower enforces the new rule, such attempts to redeem the output will never end up on the blockchain. Therefore, transactions that attempt to redeem the output with a simple preimage are as good as invalid...and effectively have become invalid.
I concede that this mechanism has some issues. Moreover, I agree that it is important that the Bitcoin community be aware of these things. I've been proposing making these rule changes explicit in the BIPs (https://github.com/CodeShark/bips/blob/BIP_Classification/bip-layers.mediawiki). I believe it is important that people weigh in on such rule changes. However, the above stated mechanism does not fall under the definition of "hard fork" we've come to accept.
Go ahead and object to soft forks...but at least try not to make arguments based on changing the definitions of terms we all generally agree upon.
- Eric
On September 28, 2015 4:40:35 AM PDT, Mike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> The rationale for soft vs hard-forks is well known, so I wont go over
>them.
>>
>
>The rationale of "backwards compatibility" is well known, yet wrong.
>I've
>gone over the arguments here and explained why the concept makes no
>sense:
>
>https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
>
>Eric - no, it's not sophisticated humour. I've been objecting to soft
>forks
>since this idea first appeared.
>
>There is no consensus. Now pick. Lose the requirement that everyone
>agree
>for consensus changes, and tell people you've done it. Change the spec.
>Or
>do nothing.
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/3812b096/attachment.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:41:28
in reply to nevent1q…jx7w
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:41:28Event JSON
{
"id": "20413ce706743e2a8ad1db5d5fef94a93082f704c1a76a5f207f024c8739900b",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159688,
"kind": 1,
"tags": [
[
"e",
"f5bb1bf208994917ac3ec4154383520df2a8573df815c54d28bae4e41ef024c8",
"",
"root"
],
[
"e",
"c30fe14befb40b64ea4715c6f47aa3f1c2759e87801c8f6dd05ce79c0fdd1dfa",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-09-28\n📝 Original message:Perhaps Adam won't go into the rationale...but I think it is important we clarify this.\n\nFor better or worse, the only \"voting\" system available to Bitcoin that cannot be trivially attacked is hashing power. Soft forks are essentially miner-enforced rule changes...rules they could have decided to enforce without the consensus of anyone else. For instance, as far as old nodes are concerned, a p2sh output can be redeemed by a simple preimage of the hash...with no signatures. The point, however, is that as long as the majority of hashpower enforces the new rule, such attempts to redeem the output will never end up on the blockchain. Therefore, transactions that attempt to redeem the output with a simple preimage are as good as invalid...and effectively have become invalid.\n\nI concede that this mechanism has some issues. Moreover, I agree that it is important that the Bitcoin community be aware of these things. I've been proposing making these rule changes explicit in the BIPs (https://github.com/CodeShark/bips/blob/BIP_Classification/bip-layers.mediawiki). I believe it is important that people weigh in on such rule changes. However, the above stated mechanism does not fall under the definition of \"hard fork\" we've come to accept.\n\nGo ahead and object to soft forks...but at least try not to make arguments based on changing the definitions of terms we all generally agree upon.\n\n- Eric\n\nOn September 28, 2015 4:40:35 AM PDT, Mike Hearn via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e The rationale for soft vs hard-forks is well known, so I wont go over\n\u003ethem.\n\u003e\u003e\n\u003e\n\u003eThe rationale of \"backwards compatibility\" is well known, yet wrong.\n\u003eI've\n\u003egone over the arguments here and explained why the concept makes no\n\u003esense:\n\u003e\n\u003ehttps://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7\n\u003e\n\u003eEric - no, it's not sophisticated humour. I've been objecting to soft\n\u003eforks\n\u003esince this idea first appeared.\n\u003e\n\u003eThere is no consensus. Now pick. Lose the requirement that everyone\n\u003eagree\n\u003efor consensus changes, and tell people you've done it. Change the spec.\n\u003eOr\n\u003edo nothing.\n\u003e\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/3812b096/attachment.html\u003e",
"sig": "5bc82bd5eebdc243627c8640424c1a87ca1b9dc55d1238ba9164c7fa2fca2fe2dcbb2f3151949c05c3f026a53619383909946aa3ed3f958059c325bd338a9102"
}