From: Tom <tomz@freedommail.ch>
To: Luke Dashjr <luke@dashjr.org>
Date: Sat, 24 Sep 2016 11:37:52 +0200
Message-ID: <4508352.RUQdqZv42T@kiwi>
In-Reply-To: <201609232234.43689.luke@dashjr.org>
References: <201609230957.03138.luke@dashjr.org> <2403444.9CSRyRIcH2@garp>
	<201609232234.43689.luke@dashjr.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
Precedence: list

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@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev