diff options
| author | Dave Scotese <dscotese@litmocracy.com> | 2016-09-23 17:08:24 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-09-24 00:08:27 +0000 |
| commit | 7d074e9ce6b84bbceec4b5547d25be95ee284c13 (patch) | |
| tree | c4e9c768c0a60fb6d6308b9012d623f1a30e6e0e | |
| parent | 0349c88fb21bb2a7e2682eb44ab4849f4289d05d (diff) | |
| download | pi-bitcoindev-7d074e9ce6b84bbceec4b5547d25be95ee284c13.tar.gz pi-bitcoindev-7d074e9ce6b84bbceec4b5547d25be95ee284c13.zip | |
Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
| -rw-r--r-- | 94/aa3ec60235a5ebec4237a8bc735bb6df7ea651 | 280 |
1 files changed, 280 insertions, 0 deletions
diff --git a/94/aa3ec60235a5ebec4237a8bc735bb6df7ea651 b/94/aa3ec60235a5ebec4237a8bc735bb6df7ea651 new file mode 100644 index 000000000..020cf511c --- /dev/null +++ b/94/aa3ec60235a5ebec4237a8bc735bb6df7ea651 @@ -0,0 +1,280 @@ +Return-Path: <dscotese@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 505A6BFA + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 24 Sep 2016 00:08:26 +0000 (UTC) +Received: by mail-vk0-f44.google.com with SMTP id z126so4283688vkd.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <dscotese@litmocracy.com> +Date: Fri, 23 Sep 2016 17:08:24 -0700 +X-Google-Sender-Auth: Vy-5RntO6ei0AfSuX1rVNWxj0eA +Message-ID: <CAGLBAhc3cSuKS6mszE-ygETChdoS5MXO4YePkHx4-AC2wGgQ_A@mail.gmail.com> +To: Luke Dashjr <luke@dashjr.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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 + +--001a1142d3c491b81c053d35b167 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div><div><div>If Alice knows enough to see that she needs= + <span class=3D"gmail-im">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.<br><br></span></div><span clas= +s=3D"gmail-im">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.= +<br><br></span></div><span class=3D"gmail-im">With the opcode, Alice can so= +lve the problem by herself.=C2=A0 Without it, Bob can solve it for Alice.<b= +r><br></span></div><span class=3D"gmail-im">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).<br><br></sp= +an><span class=3D"gmail-im">Am I understanding this correctly?=C2=A0 </span= +></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Se= +p 23, 2016 at 3:34 PM, Luke Dashjr via bitcoin-dev <span dir=3D"ltr"><<a= + href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi= +tcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote cl= +ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= +adding-left:1ex">Joe sends Alice 5 BTC (UTXO 0).<br> +Fred sends Alice 4 BTC (UTXO 1).<br> +Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2).<br> +Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's trans= +fer to<br> +Bob.<br> +Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so, it= + is<br> +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.<b= +r> +Even if Alice waits until Fred's UTXO 1-B confirms 10 blocks deep, it i= +s not<br> +impossible for a reorganization to reverse those 10 blocks and confirm UTXO= + 1<br> +again.<br> +Using OP_CHECKBLOCKATHEIGHT, however, Alice can create UTXO 3 such that it = +is<br> +valid only in the blockchain where Fred's UTXO 1-B has confirmed. This = +way, if<br> +that block is reorganized out, UTXO 3 is invalid, and either Bob receives o= +nly<br> +the original UTXO 2, or Alice can create a UTXO 3-B which is valid in the<b= +r> +reorganized blockchain if it again confirms the UTXO 1-B double-spend.<br> +<br> +Luke<br> +<br> +On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote:<br> +<span class=3D"">> On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoi= +n-dev wrote:<br> +> > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the B= +itcoin<br> +> > scripting system to address reissuing bitcoin transactions when t= +he coins<br> +> > they spend have been conflicted/double-spent.<br> +> ><br> +> > <a href=3D"https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah= +.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luke-jr= +/<wbr>bips/blob/bip-cbah/bip-cbah.<wbr>mediawiki</a><br> +><br> +</span>> Can you walk us through a real live usecase which this solves?= +=C2=A0 I read it<br> +> and I think I understand it, but I can't see the attack every givi= +ng the<br> +> attacker any benefit (or the attacked losing anything).<br> +<div class=3D"HOEnZb"><div class=3D"h5">> ______________________________= +<wbr>_________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= +ists.<wbr>linuxfoundation.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= +dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb= +r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> +______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class= +=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">I = +like to provide some work at no charge to prove my value. Do you need a tec= +hie?=C2=A0 <br>I own <a href=3D"http://www.litmocracy.com" target=3D"_blank= +">Litmocracy</a> and <a href=3D"http://www.memeracing.net" target=3D"_blank= +">Meme Racing</a> (in alpha). <br>I'm the webmaster for <a href=3D"http= +://www.voluntaryist.com" target=3D"_blank">The Voluntaryist</a> which now a= +ccepts Bitcoin.<br>I also code for <a href=3D"http://dollarvigilante.com/" = +target=3D"_blank">The Dollar Vigilante</a>.<br>"He ought to find it mo= +re profitable to play by the rules" - Satoshi Nakamoto</div></div> +</div> + +--001a1142d3c491b81c053d35b167-- + |