Johnson Lau [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-25 📝 Original message:Yes, it’s similar. ...
đź“… Original date posted:2017-01-25
📝 Original message:Yes, it’s similar. I’ll quote your design if/when I formalise my BIP. But it seems they are not the same: yours is opt-out, while mine is opt-in.
However, my proposal in nowhere depends on standardness for the protection. It depends on the new network enforcing a new SignatureHash for txs with an nVersion not used in the existing network. This itself is a hardfork and the existing network would never accept such txs.
This is to avoid requiring any consensus changes to the existing network, as there is no guarantee that such softfork would be accepted by the existing network. If the new network wants to protect their users, it’d be trivial for them to include a SignatureHash hardfork like this, along with other other hardfork changes. Further hardforks will only require changing the network characteristic bit, but not the SignatureHash.
If the hardfork designers don’t like the fix of BIP143, there are many other options. The simplest one would be a trivial change to Satoshi’s SignatureHash, such as adding an extra value at the end of the algorithm. I just don’t see any technical reasons not to fix the O(n^2) problem altogether, if it is trivial (but not that trivial if the hardfork is not based on segwit)
> On 25 Jan 2017, at 02:52, Tom Harding <tomh at thinlink.com> wrote:
>
> On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote:
>> 9. If the network characteristic byte is non-zero, and the existing
>> network characteristic bit is set, the masked version is used to
>> determine whether a transaction should be mined or relayed (policy change)
>
> Johnson,
>
> Your proposal supports 8 opt-out bits compatible with may earlier
> description:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html.
>
> If the existing network really wants to play along, it should execute a
> soft fork as soon as possible to support its own hard-fork opt-out bit
> ("network characteristic bit"). It is totally inadequate for a new
> network to rely on non-standardness in the existing network to prevent
> replay there. Instead, in the absence of a supported opt-out bit in the
> existing network, a responsible new network would allow something that
> is invalid in the existing network, for transactions where replay to the
> existing network is undesirable.
>
> It is an overreach for your BIP to suggest specific changes to be
> included in the new network, such as the specific O(n^2) fix you
> suggest. This is a matter for the new network itself.
>
>
📝 Original message:Yes, it’s similar. I’ll quote your design if/when I formalise my BIP. But it seems they are not the same: yours is opt-out, while mine is opt-in.
However, my proposal in nowhere depends on standardness for the protection. It depends on the new network enforcing a new SignatureHash for txs with an nVersion not used in the existing network. This itself is a hardfork and the existing network would never accept such txs.
This is to avoid requiring any consensus changes to the existing network, as there is no guarantee that such softfork would be accepted by the existing network. If the new network wants to protect their users, it’d be trivial for them to include a SignatureHash hardfork like this, along with other other hardfork changes. Further hardforks will only require changing the network characteristic bit, but not the SignatureHash.
If the hardfork designers don’t like the fix of BIP143, there are many other options. The simplest one would be a trivial change to Satoshi’s SignatureHash, such as adding an extra value at the end of the algorithm. I just don’t see any technical reasons not to fix the O(n^2) problem altogether, if it is trivial (but not that trivial if the hardfork is not based on segwit)
> On 25 Jan 2017, at 02:52, Tom Harding <tomh at thinlink.com> wrote:
>
> On 1/24/2017 6:33 AM, Johnson Lau via bitcoin-dev wrote:
>> 9. If the network characteristic byte is non-zero, and the existing
>> network characteristic bit is set, the masked version is used to
>> determine whether a transaction should be mined or relayed (policy change)
>
> Johnson,
>
> Your proposal supports 8 opt-out bits compatible with may earlier
> description:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012917.html.
>
> If the existing network really wants to play along, it should execute a
> soft fork as soon as possible to support its own hard-fork opt-out bit
> ("network characteristic bit"). It is totally inadequate for a new
> network to rely on non-standardness in the existing network to prevent
> replay there. Instead, in the absence of a supported opt-out bit in the
> existing network, a responsible new network would allow something that
> is invalid in the existing network, for transactions where replay to the
> existing network is undesirable.
>
> It is an overreach for your BIP to suggest specific changes to be
> included in the new network, such as the specific O(n^2) fix you
> suggest. This is a matter for the new network itself.
>
>