📅 Original date posted:2017-11-11
📝 Original message:> On Nov 6, 2017, at 20:38, Devrandom <c1.bitcoin at niftybox.net> wrote:
>
> A hard-fork is a situation where non-upgraded nodes reject a block mined and relayed by upgraded nodes.
As Peter pointed out, that is the case here.
> This creates a fork that cannot heal regardless of what follows.
That is not a condition of the hard fork concept.
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki
Softfork
A consensus fork wherein everything that was previously invalid remains invalid while blocks that would have previously considered valid become invalid. A hashrate majority of miners can impose the new rules. They have some deployment advantages like backward compatibility.
Hardfork
A consensus fork that makes previously invalid blocks valid. Hardforks require all users to upgrade.
The essential element of a hard fork is that the new rule may cause rejection of blocks that are not rejected by old rules (thereby requiring that all users adopt the new rule in order to avoid a split). The reason a hard fork is interesting is that it can create a chain split even if it is enforced by majority hash power.
That is not the case with a soft fork and it is not the case here. A split can occur. The fact that it is possible for the split to also eventually orphan the old nodes does not make it a soft fork. A soft fork requires that a hash power majority can impose the rule. However, under the proposed new rule the hash power majority (according to the new rule) cannot impose the rule on existing nodes.
> This proposal is not a hard-fork, because the non-upgraded node *will heal* if the attack has less than 1/2 of the original-POW power in the long term.
Nothing about this proposal implies an attack. From the Motivation section:
Mitigate centralization pressures by introducing a POW that does not have economies of scale
Introduce an intermediary confirmation point, reducing the impact of mining power fluctuations
> The cost of such an attack is the cost of a normal "51%" attack, multiplied by the fractional weight of the original POW (e.g. 0.75 or 0.5).
>
> So rather than saying this is a hard-fork, I would say that this is a soft-fork with reduced security for non-upgraded nodes.
Presumably this preference exists because it implies the new rule would not cause a chain split, making it more acceptable to a risk-averse economy. This is precisely why it should be described correctly.
> I would also say that the reduction in security is proportional to the reduction in weight of the original POW at the time of attack.
>
> As mentioned before, the original-POW weight starts at 1.0 and is reduced over a long period of time. I would set up the transition curve so that all nodes upgrade by the time the weight is, say, 0.75. In reality, nodes protecting high economic value would upgrade early.
In reality you have no way to know if/when people would adopt this rule. What matters in the proposal is that people who do adopt it are well aware of its ability to split them from the existing economy.
e
>> On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> If a block that would be discarded under previous rules becomes accepted after a rule addition, there is no reason to not simply call the new rule a hard fork. IOW it's perfectly rational to consider a weaker block as "invalid" relative to the strong chain. As such I don't see any reason to qualify the term, it's a hard fork. But Peter's observation (the specific behavior) is ultimately what matters.
>>
>> e
>>
>>> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> +1 to all of Peter Todd's comments
>>>
>>>> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
>>>>
>>>> Some quick thoughts...
>>>>
>>>> > Hi all,
>>>> >
>>>> > Feedback is welcome on the draft below. In particular, I want to see if
>>>> > there is interest in further development of the idea and also interested in
>>>> > any attack vectors or undesirable dynamics.
>>>> >
>>>> > (Formatted version available here:
>>>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>>>> >
>>>> > # Soft-fork Introduction of a New POW
>>>>
>>>> First of all, I don't think you can really call this a soft-fork; I'd call it a
>>>> "pseudo-soft-fork"
>>>>
>>>> My reasoning being that after implementation, a chain with less total work than
>>>> the main chain - but more total SHA256^2 work than the main chain - might be
>>>> followed by non-supporting clients. It's got some properties of a soft-fork,
>>>> but it's security model is definitely different.
>>>>
>>>> > ### Aux POW intermediate block
>>>> >
>>>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
>>>> > alternates between the two POWs.
>>>> > Each aux-POW block points to the previous normal block and contains
>>>> > transactions just like a normal block.
>>>> > Each normal block points to the previous aux-POW block and must contain all
>>>> > transactions from the aux-POW block.
>>>>
>>>> Note how you're basically proposing for the block interval to be decreased,
>>>> which has security implications due to increased orphan rates.
>>>>
>>>> > ### Heaviest chain rule change
>>>> >
>>>> > This is a semi-hard change, because non-upgraded nodes can get on the wrong
>>>> > chain in case of attack. However,
>>>>
>>>> Exactly! Not really a soft-fork.
>>>>
>>>> --
>>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> 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/20171111/1ce6f87b/attachment.html>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 18:07:25
in reply to nevent1q…watv
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cSeen on
wss://relay.noswhere.comPublished at
2023-06-07 18:07:25Event JSON
{
"id": "02e540269d8b204470bfb76eed5b5dcccd2b4634fed2ea34d418c11b3d42cbe9",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686161245,
"kind": 1,
"tags": [
[
"e",
"712d2d7becdfc1f327fb6ef0f23f68f1502b313c103dbc4a20a9e4d0fb581029",
"",
"root"
],
[
"e",
"0f0f5cb57cbe9b28ff6c4f9bc21c3b3c5f85b505722aa99d6a1292ea45bc5ed2",
"",
"reply"
],
[
"p",
"93e50f297b9985b1adba93e5476189e5e00720066bac1db9471ef7c229448b85"
]
],
"content": "📅 Original date posted:2017-11-11\n📝 Original message:\u003e On Nov 6, 2017, at 20:38, Devrandom \u003cc1.bitcoin at niftybox.net\u003e wrote:\n\u003e \n\u003e A hard-fork is a situation where non-upgraded nodes reject a block mined and relayed by upgraded nodes.\n\nAs Peter pointed out, that is the case here.\n\n\u003e This creates a fork that cannot heal regardless of what follows.\n\nThat is not a condition of the hard fork concept.\n\nhttps://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki\nSoftfork\nA consensus fork wherein everything that was previously invalid remains invalid while blocks that would have previously considered valid become invalid. A hashrate majority of miners can impose the new rules. They have some deployment advantages like backward compatibility.\nHardfork\nA consensus fork that makes previously invalid blocks valid. Hardforks require all users to upgrade.\n\nThe essential element of a hard fork is that the new rule may cause rejection of blocks that are not rejected by old rules (thereby requiring that all users adopt the new rule in order to avoid a split). The reason a hard fork is interesting is that it can create a chain split even if it is enforced by majority hash power.\n\nThat is not the case with a soft fork and it is not the case here. A split can occur. The fact that it is possible for the split to also eventually orphan the old nodes does not make it a soft fork. A soft fork requires that a hash power majority can impose the rule. However, under the proposed new rule the hash power majority (according to the new rule) cannot impose the rule on existing nodes.\n\n\u003e This proposal is not a hard-fork, because the non-upgraded node *will heal* if the attack has less than 1/2 of the original-POW power in the long term.\n\nNothing about this proposal implies an attack. From the Motivation section:\n\nMitigate centralization pressures by introducing a POW that does not have economies of scale\nIntroduce an intermediary confirmation point, reducing the impact of mining power fluctuations\n\n\u003e The cost of such an attack is the cost of a normal \"51%\" attack, multiplied by the fractional weight of the original POW (e.g. 0.75 or 0.5).\n\u003e \n\u003e So rather than saying this is a hard-fork, I would say that this is a soft-fork with reduced security for non-upgraded nodes.\n\nPresumably this preference exists because it implies the new rule would not cause a chain split, making it more acceptable to a risk-averse economy. This is precisely why it should be described correctly.\n\n\u003e I would also say that the reduction in security is proportional to the reduction in weight of the original POW at the time of attack.\n\u003e \n\u003e As mentioned before, the original-POW weight starts at 1.0 and is reduced over a long period of time. I would set up the transition curve so that all nodes upgrade by the time the weight is, say, 0.75. In reality, nodes protecting high economic value would upgrade early.\n\nIn reality you have no way to know if/when people would adopt this rule. What matters in the proposal is that people who do adopt it are well aware of its ability to split them from the existing economy.\n\ne\n\n\u003e\u003e On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e If a block that would be discarded under previous rules becomes accepted after a rule addition, there is no reason to not simply call the new rule a hard fork. IOW it's perfectly rational to consider a weaker block as \"invalid\" relative to the strong chain. As such I don't see any reason to qualify the term, it's a hard fork. But Peter's observation (the specific behavior) is ultimately what matters.\n\u003e\u003e \n\u003e\u003e e\n\u003e\u003e \n\u003e\u003e\u003e On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \n\u003e\u003e\u003e +1 to all of Peter Todd's comments\n\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e On Nov 6, 2017 11:50 AM, \"Peter Todd via bitcoin-dev\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Some quick thoughts...\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \u003e Hi all,\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e Feedback is welcome on the draft below. In particular, I want to see if\n\u003e\u003e\u003e\u003e \u003e there is interest in further development of the idea and also interested in\n\u003e\u003e\u003e\u003e \u003e any attack vectors or undesirable dynamics.\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e (Formatted version available here:\n\u003e\u003e\u003e\u003e \u003e https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e # Soft-fork Introduction of a New POW\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e First of all, I don't think you can really call this a soft-fork; I'd call it a\n\u003e\u003e\u003e\u003e \"pseudo-soft-fork\"\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e My reasoning being that after implementation, a chain with less total work than\n\u003e\u003e\u003e\u003e the main chain - but more total SHA256^2 work than the main chain - might be\n\u003e\u003e\u003e\u003e followed by non-supporting clients. It's got some properties of a soft-fork,\n\u003e\u003e\u003e\u003e but it's security model is definitely different.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \u003e ### Aux POW intermediate block\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e Auxiliary POW blocks are introduced between normal blocks - i.e. the chain\n\u003e\u003e\u003e\u003e \u003e alternates between the two POWs.\n\u003e\u003e\u003e\u003e \u003e Each aux-POW block points to the previous normal block and contains\n\u003e\u003e\u003e\u003e \u003e transactions just like a normal block.\n\u003e\u003e\u003e\u003e \u003e Each normal block points to the previous aux-POW block and must contain all\n\u003e\u003e\u003e\u003e \u003e transactions from the aux-POW block.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Note how you're basically proposing for the block interval to be decreased,\n\u003e\u003e\u003e\u003e which has security implications due to increased orphan rates.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e \u003e ### Heaviest chain rule change\n\u003e\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e\u003e \u003e This is a semi-hard change, because non-upgraded nodes can get on the wrong\n\u003e\u003e\u003e\u003e \u003e chain in case of attack. However,\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e Exactly! Not really a soft-fork.\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e --\n\u003e\u003e\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e\u003e\u003e \n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171111/1ce6f87b/attachment.html\u003e",
"sig": "e68d79ad022ca299a062b4231d57515c73a663a53d9087e2d42b39f8c070caba6583479596f8ace0ff56c86a155b6ca51653940ca978aeccc09d11c275d8e702"
}