Tao Effect [ARCHIVE] on Nostr: ð Original date posted:2017-06-06 ð Original message:> Replay is a solved ...
ð
Original date posted:2017-06-06
ð Original message:> Replay is a solved problem.
Point to this solved problem?
Your "solution" here is not a solution:
https://www.reddit.com/r/Bitcoin/comments/6f1urd/i_think_its_time_we_have_an_educated_discussion/diey21t/?context=3 <https://www.reddit.com/r/Bitcoin/comments/6f1urd/i_think_its_time_we_have_an_educated_discussion/diey21t/?context=3>;
> This is nothing but unfounded FUD. It is very simple to implement and
> guaranteed to work eventually. It may be time consuming, but that is the only
> truth here. The only risk is that of a long reorg, the same as double spend
> attacks.
Let's assume you invented a simple way to double-spend txns to self (which you haven't, fyi), then that is an issue in of itself as the point of bitcoin is to *prevent* double-spending to self.
There would need to be much more time for the community to discuss the implications of wallets have a "double-spend to self" button in them.
> What kind of "fungibility" does this FUD claim it destroys? Destroying cross-
> chain fungibility is the very *intent* of replay protection. And it does not
> destroy same-chain fungibility any more than any other miner spending.
Yes it does destroy same-chain fungibility, as discussed on twitter [1], you're making miner coins special on both chains.
> Lack of replay protection does not mean there is no coin.
It effectively does. If people want to proceed blindly, ignoring replay, they're welcome to read about the consequences [2].
[1] https://twitter.com/taoeffect/status/872226556571131905 <https://twitter.com/taoeffect/status/872226556571131905>;
[2] http://gist.github.com/taoeffect/c910ebb16d9f6d248e9f1f3c6e10b1b8 <http://gist.github.com/taoeffect/c910ebb16d9f6d248e9f1f3c6e10b1b8>;
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 4:08 PM, Luke Dashjr <luke at dashjr.org <mailto:luke at dashjr.org>> wrote:
>
> On Tuesday 06 June 2017 10:39:28 PM Tao Effect via bitcoin-dev wrote:
>> I believe the severity of replay attacks is going unvoiced and is not
>> understood within the bitcoin community because of their lack of
>> experience with them.
>
> Replay is a solved problem. It can be improved on and made simpler, but at
> this point, replay only occurs when the sender is either negligent or
> intending it.
>
>> Both of the coin-splitting techniques given so far by the proponents BIP148
>> are also untenable:
>>
>> - Double-spending to self with nLockTime txns is insanely complicated,
>> risky, not guaranteed to work, extremely time consuming, and would likely
>> result in a massive increase in backlogged transactions and increased
>> fees.
>
> This is nothing but unfounded FUD. It is very simple to implement and
> guaranteed to work eventually. It may be time consuming, but that is the only
> truth here. The only risk is that of a long reorg, the same as double spend
> attacks.
>
>> - Mixing with 148 coinbase txns destroys fungibility.
>
> What kind of "fungibility" does this FUD claim it destroys? Destroying cross-
> chain fungibility is the very *intent* of replay protection. And it does not
> destroy same-chain fungibility any more than any other miner spending.
>
>> Without a coin, there is no real threat from BIP148.
>
> Lack of replay protection does not mean there is no coin. Replay protection is
> equally a concern for the main (BIP148) chain and any legacy chains malicious
> miners might choose to split off. And none of this changes the fact that such
> miners will be unable to sell their legacycoins at Bitcoin market prices,
> because whether other transactions are replayed or not, *their* coins won't be
> valid on the main chain.
>
> Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/1e3823f1/attachment.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/1e3823f1/attachment.sig>;
ð Original message:> Replay is a solved problem.
Point to this solved problem?
Your "solution" here is not a solution:
https://www.reddit.com/r/Bitcoin/comments/6f1urd/i_think_its_time_we_have_an_educated_discussion/diey21t/?context=3 <https://www.reddit.com/r/Bitcoin/comments/6f1urd/i_think_its_time_we_have_an_educated_discussion/diey21t/?context=3>;
> This is nothing but unfounded FUD. It is very simple to implement and
> guaranteed to work eventually. It may be time consuming, but that is the only
> truth here. The only risk is that of a long reorg, the same as double spend
> attacks.
Let's assume you invented a simple way to double-spend txns to self (which you haven't, fyi), then that is an issue in of itself as the point of bitcoin is to *prevent* double-spending to self.
There would need to be much more time for the community to discuss the implications of wallets have a "double-spend to self" button in them.
> What kind of "fungibility" does this FUD claim it destroys? Destroying cross-
> chain fungibility is the very *intent* of replay protection. And it does not
> destroy same-chain fungibility any more than any other miner spending.
Yes it does destroy same-chain fungibility, as discussed on twitter [1], you're making miner coins special on both chains.
> Lack of replay protection does not mean there is no coin.
It effectively does. If people want to proceed blindly, ignoring replay, they're welcome to read about the consequences [2].
[1] https://twitter.com/taoeffect/status/872226556571131905 <https://twitter.com/taoeffect/status/872226556571131905>;
[2] http://gist.github.com/taoeffect/c910ebb16d9f6d248e9f1f3c6e10b1b8 <http://gist.github.com/taoeffect/c910ebb16d9f6d248e9f1f3c6e10b1b8>;
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 4:08 PM, Luke Dashjr <luke at dashjr.org <mailto:luke at dashjr.org>> wrote:
>
> On Tuesday 06 June 2017 10:39:28 PM Tao Effect via bitcoin-dev wrote:
>> I believe the severity of replay attacks is going unvoiced and is not
>> understood within the bitcoin community because of their lack of
>> experience with them.
>
> Replay is a solved problem. It can be improved on and made simpler, but at
> this point, replay only occurs when the sender is either negligent or
> intending it.
>
>> Both of the coin-splitting techniques given so far by the proponents BIP148
>> are also untenable:
>>
>> - Double-spending to self with nLockTime txns is insanely complicated,
>> risky, not guaranteed to work, extremely time consuming, and would likely
>> result in a massive increase in backlogged transactions and increased
>> fees.
>
> This is nothing but unfounded FUD. It is very simple to implement and
> guaranteed to work eventually. It may be time consuming, but that is the only
> truth here. The only risk is that of a long reorg, the same as double spend
> attacks.
>
>> - Mixing with 148 coinbase txns destroys fungibility.
>
> What kind of "fungibility" does this FUD claim it destroys? Destroying cross-
> chain fungibility is the very *intent* of replay protection. And it does not
> destroy same-chain fungibility any more than any other miner spending.
>
>> Without a coin, there is no real threat from BIP148.
>
> Lack of replay protection does not mean there is no coin. Replay protection is
> equally a concern for the main (BIP148) chain and any legacy chains malicious
> miners might choose to split off. And none of this changes the fact that such
> miners will be unable to sell their legacycoins at Bitcoin market prices,
> because whether other transactions are replayed or not, *their* coins won't be
> valid on the main chain.
>
> Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/1e3823f1/attachment.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/1e3823f1/attachment.sig>;