Return-Path: <jl2012@xbt.hk> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ECF77BAE for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 25 Jan 2017 07:42:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender163-mail.zoho.com (sender163-mail.zoho.com [74.201.84.163]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 447B18C for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 25 Jan 2017 07:42:21 +0000 (UTC) Received: from [192.168.1.111] (137.189.135.19 [137.189.135.19]) by mx.zohomail.com with SMTPS id 1485330137416490.44324610576336; Tue, 24 Jan 2017 23:42:17 -0800 (PST) From: Johnson Lau <jl2012@xbt.hk> Message-Id: <79668AE7-B05D-41F8-A6DF-EADC05143523@xbt.hk> Content-Type: multipart/alternative; boundary="Apple-Mail=_786BB037-C098-4636-9F54-3DABCC3B60C9" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 25 Jan 2017 15:42:13 +0800 In-Reply-To: <CAAt2M1945e4jpy_eoZBJnyztVXjFVTJAjMc-u45gMf4ich8sEQ@mail.gmail.com> To: Natanael <natanael.l@gmail.com> References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk> <CAAt2M1_=8jDWuyO5_n8aXXDVYypvGQ2uL6zkJNn1ZnQOaXM6nQ@mail.gmail.com> <311FE02A-F3B5-4F88-B6C8-F0E78CC46903@xbt.hk> <CAAt2M1_cQTfaDyQkaixeFB5Ubi35fSOs9Ks74WZEehtFk__B3w@mail.gmail.com> <45F53199-C8AC-4DD3-B746-D56F9F01946B@xbt.hk> <CAAt2M1945e4jpy_eoZBJnyztVXjFVTJAjMc-u45gMf4ich8sEQ@mail.gmail.com> X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork 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: Wed, 25 Jan 2017 07:42:22 -0000 --Apple-Mail=_786BB037-C098-4636-9F54-3DABCC3B60C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25 Jan 2017, at 15:29, Natanael <natanael.l@gmail.com> wrote: >=20 >=20 > Den 25 jan. 2017 08:22 skrev "Johnson Lau" <jl2012@xbt.hk = <mailto:jl2012@xbt.hk>>: > Assuming Alice is paying Bob with an old style time-locked tx. Under = your proposal, after the hardfork, Bob is still able to confirm the = time-locked tx on both networks. To fulfil your new rules he just needs = to send the outputs to himself again (with different tx format). But as = Bob gets all the money on both forks, it is already a successful replay >=20 > Why would Alice be sitting on an old-style signed transaction with = UTXO:s none of which she controls (paying somebody else), with NO = ability to substitute the transaction for one where she DOES control an = output, leaving her unable to be the one spending the replay protecting = child transaction?=20 If Alice still has full control, she is already protected by my = proposal, which does not require any protecting child transaction. But in many cases she may not have full control. Make it clearer, = consider that=E2=80=99s actually a 2-of-2 multisig of Alice and Bob, and = the time locked tx is sending to Bob. If the time locked tx is = unprotected in the first place, Bob will get all the money from both = forks anyway, as there is no reason for him to renegotiate with Alice.= --Apple-Mail=_786BB037-C098-4636-9F54-3DABCC3B60C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 25 Jan 2017, at 15:29, Natanael <<a = href=3D"mailto:natanael.l@gmail.com" = class=3D"">natanael.l@gmail.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"auto" = class=3D""><div data-smartmail=3D"gmail_signature" dir=3D"auto" = class=3D""><br class=3D""></div><div class=3D"gmail_extra" = dir=3D"auto"><div class=3D"gmail_quote">Den 25 jan. 2017 08:22 skrev = "Johnson Lau" <<a href=3D"mailto:jl2012@xbt.hk" = class=3D"">jl2012@xbt.hk</a>>:<br type=3D"attribution" = class=3D""><blockquote class=3D"quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = style=3D"word-wrap:break-word" class=3D""><div class=3D"">Assuming Alice = is paying Bob with an old style time-locked tx. Under your proposal, = after the hardfork, Bob is still able to confirm the time-locked tx on = both networks. To fulfil your new rules he just needs to send the = outputs to himself again (with different tx format). But as Bob gets all = the money on both forks, it is already a successful = replay</div></div></blockquote></div></div><div dir=3D"auto" = class=3D""><br class=3D""></div><div dir=3D"auto" class=3D"">Why would = Alice be sitting on an old-style signed transaction with UTXO:s none of = which she controls (paying somebody else), with NO ability to substitute = the transaction for one where she DOES control an output, leaving her = unable to be the one spending the replay protecting child = transaction? </div><div class=3D"gmail_extra" = dir=3D"auto"></div></div> </div></blockquote></div><br class=3D""><div class=3D""><div class=3D"">If= Alice still has full control, she is already protected by my proposal, = which does not require any protecting child transaction.</div></div><div = class=3D""><br class=3D""></div><div class=3D"">But in many cases she = may not have full control. Make it clearer, consider that=E2=80=99s = actually a 2-of-2 multisig of Alice and Bob, and the time locked tx is = sending to Bob. If the time locked tx is unprotected in the first place, = Bob will get all the money from both forks anyway, as there is no reason = for him to renegotiate with Alice.</div></body></html>= --Apple-Mail=_786BB037-C098-4636-9F54-3DABCC3B60C9--