Tao Effect [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-06 📝 Original message:> Please read my email ...
📅 Original date posted:2017-06-06
📝 Original message:> Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on,
In order to *get to that point*, you need >51%.
Not only that, but, if you started out with <51%, then you need >>51% in order to *catch up* and replace the large number of blocks added to the legacy chain in the mean time.
So, since >51% is _required_ for BIP148 to succeed (and likely >>51%)... you might as well do as SegWit did originally, or lower the threshold to 80% or something (as BIP91 does).
Without replay protection at the outset, BIP148, as far as I can tell, isn't a threat to miners.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 5:29 PM, Kekcoin <kekcoin at protonmail.com <mailto:kekcoin at protonmail.com>> wrote:
>
> Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on, as the non-148 chain would have been reorganized into oblivion.
>
>
> Sent with ProtonMail <https://protonmail.com/>; Secure Email.
>
>> -------- Original Message --------
>> Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
>> Local Time: June 7, 2017 3:26 AM
>> UTC Time: June 7, 2017 12:26 AM
>> From: contact at taoeffect.com <mailto:contact at taoeffect.com>
>> To: Kekcoin <kekcoin at protonmail.com <mailto:kekcoin at protonmail.com>>
>> Anthony Towns <aj at erisian.com.au <mailto:aj at erisian.com.au>>, bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
>>
>> I don't know what you mean by "render the replay threat moot."
>>
>> If you don't have replay protection, replay is always a threat. A very serious one.
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>
>>> On Jun 6, 2017, at 5:19 PM, Kekcoin <kekcoin at protonmail.com <mailto:kekcoin at protonmail.com>> wrote:
>>>
>>> Hmm, that's not the difference I was talking about. I was referring to the fact that using "post-chainsplit coinbases from the non-148 chain" to unilaterally (ie. can be done without action on the 148-chain) taint coins is more secure in extreme-adverserial cases such as secret-mining reorg attacks (as unfeasibly expensive they may be); the only large-scale (>100 block) reorganization the non-148 chain faces should be a resolution of the chainsplit and therefore render the replay threat moot.
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/99784c2b/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/99784c2b/attachment-0001.sig>;
📝 Original message:> Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on,
In order to *get to that point*, you need >51%.
Not only that, but, if you started out with <51%, then you need >>51% in order to *catch up* and replace the large number of blocks added to the legacy chain in the mean time.
So, since >51% is _required_ for BIP148 to succeed (and likely >>51%)... you might as well do as SegWit did originally, or lower the threshold to 80% or something (as BIP91 does).
Without replay protection at the outset, BIP148, as far as I can tell, isn't a threat to miners.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 5:29 PM, Kekcoin <kekcoin at protonmail.com <mailto:kekcoin at protonmail.com>> wrote:
>
> Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on, as the non-148 chain would have been reorganized into oblivion.
>
>
> Sent with ProtonMail <https://protonmail.com/>; Secure Email.
>
>> -------- Original Message --------
>> Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
>> Local Time: June 7, 2017 3:26 AM
>> UTC Time: June 7, 2017 12:26 AM
>> From: contact at taoeffect.com <mailto:contact at taoeffect.com>
>> To: Kekcoin <kekcoin at protonmail.com <mailto:kekcoin at protonmail.com>>
>> Anthony Towns <aj at erisian.com.au <mailto:aj at erisian.com.au>>, bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
>>
>> I don't know what you mean by "render the replay threat moot."
>>
>> If you don't have replay protection, replay is always a threat. A very serious one.
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>
>>> On Jun 6, 2017, at 5:19 PM, Kekcoin <kekcoin at protonmail.com <mailto:kekcoin at protonmail.com>> wrote:
>>>
>>> Hmm, that's not the difference I was talking about. I was referring to the fact that using "post-chainsplit coinbases from the non-148 chain" to unilaterally (ie. can be done without action on the 148-chain) taint coins is more secure in extreme-adverserial cases such as secret-mining reorg attacks (as unfeasibly expensive they may be); the only large-scale (>100 block) reorganization the non-148 chain faces should be a resolution of the chainsplit and therefore render the replay threat moot.
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/99784c2b/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/99784c2b/attachment-0001.sig>;