diff options
| author | Johnson Lau <jl2012@xbt.hk> | 2017-01-25 15:42:13 +0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-01-25 07:42:21 +0000 |
| commit | c98ae540e13b8f5959d674aa80c51a4f03c1495e (patch) | |
| tree | 88c1f77d6aba70d8423abee3e8b2fba3d08b807e | |
| parent | e09b12a5c3181f6727959783fb947d59c5c6de75 (diff) | |
| download | pi-bitcoindev-c98ae540e13b8f5959d674aa80c51a4f03c1495e.tar.gz pi-bitcoindev-c98ae540e13b8f5959d674aa80c51a4f03c1495e.zip | |
Re: [bitcoin-dev] Anti-transaction replay in a hardfork
| -rw-r--r-- | 8b/aa53c3b69da9e7bfcafb483a3268a4bf1f9f58 | 129 |
1 files changed, 129 insertions, 0 deletions
diff --git a/8b/aa53c3b69da9e7bfcafb483a3268a4bf1f9f58 b/8b/aa53c3b69da9e7bfcafb483a3268a4bf1f9f58 new file mode 100644 index 000000000..154f2bc4a --- /dev/null +++ b/8b/aa53c3b69da9e7bfcafb483a3268a4bf1f9f58 @@ -0,0 +1,129 @@ +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-- + + |