Tom [ARCHIVE] on Nostr: š Original date posted:2016-09-24 š Original message:Thank you Luke, this makes ...
š
Original date posted:2016-09-24
š Original message:Thank you Luke, this makes it clearer.
It doesn't change that this scenario is an attack that doesn't give the
attacker any benefit and the attacked doesn't loose anything either (as
Dave pointed out).
This is a completely academical problem that assumes so many stupid
mistakes from software and from people that its very unlikely. On top of
that it assumes a rather lengthy 51% attack in concert with this already
extremely unlikely usecase.
In the scenario you assume stupid people and then you solve it by requiring
the victim to suddenly be super smart and use a solution specifically
designed for this super unlikely usecase that probably will never actually
happen...
I don't buy it.
On Friday, 23 September 2016 22:34:41 CEST Luke Dashjr wrote:
> Joe sends Alice 5 BTC (UTXO 0).
> Fred sends Alice 4 BTC (UTXO 1).
> Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2).
> Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's
> transfer to Bob.
> Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so,
> it is possible that UTXO 0 could be mined, and then both UTXO 2 and UTXO
> 3 which would result in her giving Bob a total of 8 BTC rather than
> merely 4 BTC. Even if Alice waits until Fred's UTXO 1-B confirms 10
> blocks deep, it is not impossible for a reorganization to reverse those
> 10 blocks and confirm UTXO 1 again.
> Using OP_CHECKBLOCKATHEIGHT, however, Alice can create UTXO 3 such that
> it is valid only in the blockchain where Fred's UTXO 1-B has confirmed.
> This way, if that block is reorganized out, UTXO 3 is invalid, and
> either Bob receives only the original UTXO 2, or Alice can create a UTXO
> 3-B which is valid in the reorganized blockchain if it again confirms
> the UTXO 1-B double-spend.
>
> Luke
>
> On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote:
> > On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote:
> > > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the
> > > Bitcoin
> > > scripting system to address reissuing bitcoin transactions when the
> > > coins they spend have been conflicted/double-spent.
> > >
> > > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
> >
> > Can you walk us through a real live usecase which this solves? I read
> > it and I think I understand it, but I can't see the attack every
> > giving the attacker any benefit (or the attacked losing anything).
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
š Original message:Thank you Luke, this makes it clearer.
It doesn't change that this scenario is an attack that doesn't give the
attacker any benefit and the attacked doesn't loose anything either (as
Dave pointed out).
This is a completely academical problem that assumes so many stupid
mistakes from software and from people that its very unlikely. On top of
that it assumes a rather lengthy 51% attack in concert with this already
extremely unlikely usecase.
In the scenario you assume stupid people and then you solve it by requiring
the victim to suddenly be super smart and use a solution specifically
designed for this super unlikely usecase that probably will never actually
happen...
I don't buy it.
On Friday, 23 September 2016 22:34:41 CEST Luke Dashjr wrote:
> Joe sends Alice 5 BTC (UTXO 0).
> Fred sends Alice 4 BTC (UTXO 1).
> Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2).
> Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's
> transfer to Bob.
> Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so,
> it is possible that UTXO 0 could be mined, and then both UTXO 2 and UTXO
> 3 which would result in her giving Bob a total of 8 BTC rather than
> merely 4 BTC. Even if Alice waits until Fred's UTXO 1-B confirms 10
> blocks deep, it is not impossible for a reorganization to reverse those
> 10 blocks and confirm UTXO 1 again.
> Using OP_CHECKBLOCKATHEIGHT, however, Alice can create UTXO 3 such that
> it is valid only in the blockchain where Fred's UTXO 1-B has confirmed.
> This way, if that block is reorganized out, UTXO 3 is invalid, and
> either Bob receives only the original UTXO 2, or Alice can create a UTXO
> 3-B which is valid in the reorganized blockchain if it again confirms
> the UTXO 1-B double-spend.
>
> Luke
>
> On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote:
> > On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote:
> > > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the
> > > Bitcoin
> > > scripting system to address reissuing bitcoin transactions when the
> > > coins they spend have been conflicted/double-spent.
> > >
> > > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
> >
> > Can you walk us through a real live usecase which this solves? I read
> > it and I think I understand it, but I can't see the attack every
> > giving the attacker any benefit (or the attacked losing anything).
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev