From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 505A6BFA for ; Sat, 24 Sep 2016 00:08:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E8DC7D for ; Sat, 24 Sep 2016 00:08:26 +0000 (UTC) Received: by mail-vk0-f44.google.com with SMTP id z126so4283688vkd.0 for ; Fri, 23 Sep 2016 17:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DGIdQa9YyEcc6MsgDA5mAzqsc1HpaJx3iRt+HfDu8QM=; b=roN+Ggd4Dg2EBGWipFtIUOb8bXjfmYX9iP3S1UteY9C6GxwWlqJiIBoU1lJ+Ly4p5T 9TD3jxu7FsVbiA0jeokGOiEfT+qQ9NUThYCD78PmH2K6kGlW+pumgQIYl7/guMAXdCtD XErJZ21Ml2kep+AH51N4/l1CnOWvIZeqGQlOv2ENRSLfffRd//uRwe4SMjcegEe44qx7 BZiO7nP/zpPQMfZAVoabhOkpa4LuvgzRI0avzfrQrnAhuu/V+pNh6FVoGMyvPk26GjlH Ha5J6mgsag+xgI4yWWsfGgkJCKtYZ3jGyYn9pxlTPWF75ZaTV+uq2BCMDM2TOSOzb+LQ BmCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DGIdQa9YyEcc6MsgDA5mAzqsc1HpaJx3iRt+HfDu8QM=; b=awS5fhYPNP/w6R0JP1Edyx2xIc2x5ASqijYo/kw2t1vw3np8OjzM42x9y0AMKawZaB 3JmcT7xYDXNBqqgh/1RczLY9Nn5cNkYgdrGDUwjFvpkGWWW1n3ZgCRjD5N4orIHWoF0C tDwKMKlPWM6zbNtILZltR+YDR5bGHV2psTHINzAPL+kcUoxi9rh6jkAdYNXJ/RDwAQ6W tFxCBB2Lm6UR5kDfsDLDduyilmLGxTO2o1UHiovLm28vy769PuQeSd33xvxeqmQWGjX7 un1kx+VOKg1sjSkZB398Z83UCLT29EhQvLlVz/P1+YjB+p2k1LsJ09mrSySqekDK6NJO iILw== X-Gm-Message-State: AA6/9RkVu/PtYEAEJigtI0XoIGb4M10rjVIYc7sO1EHyJqTh6mlhm0x4C9DCkzWRs/2xMekO5ylPmwgqlqcV/w== X-Received: by 10.31.163.134 with SMTP id m128mr731593vke.70.1474675705229; Fri, 23 Sep 2016 17:08:25 -0700 (PDT) MIME-Version: 1.0 Sender: dscotese@gmail.com Received: by 10.176.1.168 with HTTP; Fri, 23 Sep 2016 17:08:24 -0700 (PDT) In-Reply-To: <201609232234.43689.luke@dashjr.org> References: <201609230957.03138.luke@dashjr.org> <2403444.9CSRyRIcH2@garp> <201609232234.43689.luke@dashjr.org> From: Dave Scotese Date: Fri, 23 Sep 2016 17:08:24 -0700 X-Google-Sender-Auth: Vy-5RntO6ei0AfSuX1rVNWxj0eA Message-ID: To: Luke Dashjr , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a1142d3c491b81c053d35b167 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2016 00:08:27 -0000 --001a1142d3c491b81c053d35b167 Content-Type: text/plain; charset=UTF-8 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 < bitcoin-dev@lists.linuxfoundation.org> 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > 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 and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --001a1142d3c491b81c053d35b167 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If Alice knows enough to see that she needs= CHECKBLOCKATHEIGHT to avoid paying Bob twice, the= n she also knows that Fred owes her 4BTC.=C2=A0 If Bob complains about gett= ing paid faster, Alice can let him know that Fred essentially stole his coi= ns and that when she is certain he (and she) can't get them back, she w= ill send a different four coins to Bob.=C2=A0 If she can establish trust wi= th Bob (She'd trust Bob to pay her back if he gets back the coins Fred = stole), then she can pay him again.=C2=A0 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.=C2=A0 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 log= ic is built in, if we add this opcode.=C2=A0 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 ca= n be duplicated in the valid chain without any risk to the original sender.=

With the opcode, Alice can so= lve the problem by herself.=C2=A0 Without it, Bob can solve it for Alice.
While the opcode adds complexit= y, it enables victims of double-spends to pay untrusted creditors (Bob) wit= hout the risk that orphaned chains create of paying them twice.=C2=A0 I'= ;m not sure the added complexity is worth the reward. The reward is to prot= ect Bitcoiners (Alice) from people we'd call "untrusted creditors&= quot; (Bob) and I think that might be a mistake.=C2=A0 Getting a refund tra= nsaction 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?=C2=A0

On Fri, Se= p 23, 2016 at 3:34 PM, Luke Dashjr via bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> 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 trans= fer 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<= br> 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 i= s 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 o= nly
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 bitcoi= n-dev wrote:
> > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the B= itcoin
> > scripting system to address reissuing bitcoin transactions when t= he 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?= =C2=A0 I read it
> and I think I understand it, but I can't see the attack every givi= ng the
> attacker any benefit (or the attacked losing anything).
> ______________________________= _________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
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 tec= hie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I'm the webmaster for The Voluntaryist which now a= ccepts Bitcoin.
I also code for The Dollar Vigilante.
"He ought to find it mo= re profitable to play by the rules" - Satoshi Nakamoto
--001a1142d3c491b81c053d35b167--