If Alice knows enough to see that she needs CHECKBLOCKATHEIGHT to avoid
paying Bob twice, then she also knows that Fred owes her 4BTC. If Bob
complains about getting paid faster, Alice can let him know that Fred
essentially stole his coins and that when she is certain he (and she) can't
get them back, she will send a different four coins to Bob. If she can
establish trust with Bob (She'd trust Bob to pay her back if he gets back
the coins Fred stole), then she can pay him again. Bob could also make a
transaction to send the first input from Alice back to her (since he
doesn't have those coins anyway), sign it, and send that to her. She can
then keep it instead of having to use the new opcode.
Or she can let her wallet use the new opcode so that the logic is built in,
if we add this opcode. Wallet makers who want to help solve this problem
can either implement the new opcode, or they can offer people like Bob the
ability to refund orphaned transactions so that they can be duplicated in
the valid chain without any risk to the original sender.
With the opcode, Alice can solve the problem by herself. Without it, Bob
can solve it for Alice.
While the opcode adds complexity, it enables victims of double-spends to
pay untrusted creditors (Bob) without the risk that orphaned chains create
of paying them twice. I'm not sure the added complexity is worth the
reward. The reward is to protect Bitcoiners (Alice) from people we'd call
"untrusted creditors" (Bob) and I think that might be a mistake. Getting a
refund transaction signed and sent back to Alice is similar to how the LN
will work (where wallets hold transactions that they don't broadcast).
Am I understanding this correctly?
On Fri, Sep 23, 2016 at 3:34 PM, Luke Dashjr via bitcoin-dev <
Post by Luke Dashjr via bitcoin-devJoe 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
Post by Tom via bitcoin-devPost by Luke Dashjr via bitcoin-devThis BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin
scripting system to address reissuing bitcoin transactions when the
coins
Post by Tom via bitcoin-devPost by Luke Dashjr via bitcoin-devthey 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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto