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 2B41F6C for ; Mon, 13 Nov 2017 10:03:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 863ADE5 for ; Mon, 13 Nov 2017 10:03:09 +0000 (UTC) Received: by mail-wr0-f175.google.com with SMTP id q66so13865723wrb.13 for ; Mon, 13 Nov 2017 02:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockchain.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y7TDixF2uiFcJ8r2VPRsIvO99Z7L+gEkGFsej0EiJxo=; b=jH2gLdJasS4ZBHsNPkWo1DVjPktE5kjVzjIdZ9iswlxhbeO0H2RJUa9AaEvav/xHg7 qbjTZ9qYIMjNmBqKfJIsvszpX296B1j2QnoIjYKeWdSb7RLWTy+LiIMT46h3+rP0LP1i qz5wPPSaSc+oQ3crdbjcJIrv+VQEBxQCgV+rc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=y7TDixF2uiFcJ8r2VPRsIvO99Z7L+gEkGFsej0EiJxo=; b=Rv+cTZ3VAlfFDWiCahxE2ha6/MWXyWGXDHqgKkpRWNljUHChCd3D4KnSAlHLF1pxMO GX7gBYE1BizhqEMvHhT2b+etpFCX/QKPoPud1muDOVV/N/5Y903tjNE/8H3dW0sMRrgI GqKq17IfmKUl6+0oI4VshQCCUTwmaT3Z7/Faw9wvIsSTfhdEVHsrwPu+ps9h2wEGZiCq P4qM5X+2tuh910p+2SK/nw3WIi6tTh4zRxAv3UQ2LXpEOY9owFcEvq8YFm3j/Vc2sja6 Zz5Zi5cKv/9ZxQtAOWN2lPsrPER2B3EmFZrrwz5aokEITRmxxGIfnvkU2GqZrw35enE6 55Xg== X-Gm-Message-State: AJaThX78Et+epGgYxe35nrDtpz3DWc9/tymnndtA5h+RWQoix25w9rwq MriypVOzRQmFOHNa0hkB9o7bBA== X-Google-Smtp-Source: AGs4zMYxRCviXs5D+KPPQy3oDbh8SrIT5X5LQdO7+PV68XTjyQcDqcY0W4sgmmXrPZGk6VYnRUYjGA== X-Received: by 10.223.129.41 with SMTP id 38mr7243743wrm.57.1510567388134; Mon, 13 Nov 2017 02:03:08 -0800 (PST) Received: from [192.168.2.105] (p5089FF1E.dip0.t-ipconnect.de. [80.137.255.30]) by smtp.gmail.com with ESMTPSA id f6sm4400381wre.66.2017.11.13.02.03.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 02:03:06 -0800 (PST) From: Mats Jerratsch Message-Id: <24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 13 Nov 2017 10:03:04 +0000 In-Reply-To: To: Jacob Eliosoff References: <7601C2CD-8544-4501-80CE-CAEB402A72D2@blockchain.com> <45C2D68B-BA8E-47DE-BFA5-643922395B2A@sprovoost.nl> <95ECB451-56AE-45E5-AAE6-10058C4B7FD7@sprovoost.nl> <55467A01-A8B2-4E73-8331-38C0A7CD90EF@sprovoost.nl> <46E317DF-C97C-4797-B989-594298BC6030@sprovoost.nl> <3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 13 Nov 2017 13:54:53 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks 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: Mon, 13 Nov 2017 10:03:10 -0000 --Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230 Content-Type: multipart/alternative; boundary="Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56" --Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > OK, so nForkId 0 is exactly the "valid on all chains" specifier I was = asking about, cool. And your LN example (and nLockTime txs in general) = illustrate why it's preferable to implement a generic replay protection = scheme like yours in advance, rather than before each fork: all ad hoc = RP schemes I know of break old txs on one of the chains, even when = that's not desirable - ie, they offer no wildcard like nForkId 0. Exactly! > One comment on your LN example: users would have to take note that = nForkId 0 txs would be valid not only on future forks, but on past forks = too. Eg, if BCH had been deployed with nForkId 2, then a user setting = up BTC LN txs now with nForkId 0 would have to be aware that those txs = would be valid for BCH too. Of course the user could avoid this by = funding from a BTC-only address, but it is a potential minor pitfall of = nForkId 0. (Which I don't see any clean way around.) This is actually incorrect. There are two transactions involved in LN. = The funding transaction, which opens a payment channel, and a commitment = transaction, which closes the channel when broadcasted to the network = (the cooperative closing transaction can be considered a commitment = transaction in a loose sense). Now you want to protect the funding transaction, as otherwise you would = be subject to a replay-attack on all *past* forks. So you will set = `nForkId>=3D1` for the funding transaction, making this payment channel = non-existent on any *past* forks. However, if during the lifetime of the = payment channel another fork happens, the payment channel exists for = both tokens. So for the commitment transaction, you will have = `nForkId=3D0`, making it valid on both of these chains. While this = `nForkId` is valid on all chains, the parent transaction it tries to = spend (the funding transaction) does only exist on two chains, the = original one you created the channel for and the one that forked away. --Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

OK, so nForkId 0 is exactly the = "valid on all chains" specifier I was asking about, cool.  And your = LN example (and nLockTime txs in general) illustrate why it's preferable = to implement a generic replay protection scheme like yours in advance, rather than before each fork: all ad hoc RP = schemes I know of break old txs on one of the chains, even when that's = not desirable - ie, they offer no wildcard like nForkId = 0.

Exactly!

One comment on your LN example: users would have to take note = that nForkId 0 txs would be valid not only on future forks, but on past forks too.  Eg, if BCH had been deployed with = nForkId 2, then a user setting up BTC LN txs now with nForkId 0 would = have to be aware that those txs would be valid for BCH too.  Of = course the user could avoid this by funding from a BTC-only address, but = it is a potential minor pitfall of nForkId 0.  (Which I don't see = any clean way around.)

This is actually = incorrect. There are two transactions involved in LN. The funding = transaction, which opens a payment channel, and a commitment = transaction, which closes the channel when broadcasted to the network = (the cooperative closing transaction can be considered a commitment = transaction in a loose sense). 

Now you want to protect the funding = transaction, as otherwise you would be subject to a replay-attack on all = *past* forks. So you will set `nForkId>=3D1` for the funding = transaction, making this payment channel non-existent on any *past* = forks. However, if during the lifetime of the payment channel another = fork happens, the payment channel exists for both tokens. So for the = commitment transaction, you will have `nForkId=3D0`, making it valid on = both of these chains. While this `nForkId` is valid on all chains, the = parent transaction it tries to spend (the funding transaction) does only = exist on two chains, the original one you created the channel for and = the one that forked away. 
= --Apple-Mail=_6FFDF190-74D2-4956-87E6-F1C1C5352C56-- --Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJaCW3ZAAoJEAYZmwZ/PsbKmQ4P/RwgMvqhJKjID7qt+q1TELZZ bqvoym9dzIdo37lT0DUmS8TNRxAU3liBkgCdBLUQXd9ktVIHGUsGr/rPZnQfD9pk yHK9AdhBO14QPH2wHqzDb5W3YTUAsMWb4K/YCsMqZX2miAvdRCw8fLnITrnHxe2c nWj2t4SAAPplDRTuhMljJ843KzR0CCdOQo7YPE5KM9VWihil56+wrGHGFNvVl789 cgJhPvgpt3WeMlIF95tYJhew0af3xtHmo1Z8KJYF/8zJb4BpnrAh6aKxyKxws4ut E0bRNUtUB1hj17w1Rv82vM6KW5hKj0JmtSdcOJqe0gasAnqS81hCiEQQC4B8vMab jtaF/fKS6wAEPc0RRRTEzvkwv6BQIJ6lNuohR7YEiwBUGcrtZVQ5ZVtdINrNSei1 r4B5/PGaQDYKqyoVoSLb/6NbzEiPdfJt/1tnMEI77HQSbFoibl25rDhBRHKlKjSl 8wdun06teL0wniOPNkoStrNqywTLGspw7PZZeWWsgocD9mAPPNsAeA1QPyKxphs5 AaDLPzC43+/IBpCwGCMrLbWRwdxb2FizAX/peKzXbCLmrFw24Yxo95+KR10vMBu3 YIWodo1nFd9XrWbHTmvl6Kfrlg76UN3MeclyclaTUXBAIkN7GjKDC+wv8a8z46AZ YzfAUC9jJ8pf/yvoitdv =84BJ -----END PGP SIGNATURE----- --Apple-Mail=_2457BA2C-F57A-434A-A52D-A5B22CBDE230--