From: Mats Jerratsch <mats@blockchain•com>
To: Jacob Eliosoff <jacob.eliosoff@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks
Date: Mon, 13 Nov 2017 10:03:04 +0000 [thread overview]
Message-ID: <24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com> (raw)
In-Reply-To: <CAAUaCyg70uUnUp1Q0a6kEoQ1Js68VFLgthyfwyMQaaEqO8R-UQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1920 bytes --]
> 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>=1` 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=0`, 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.
[-- Attachment #1.2: Type: text/html, Size: 2559 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
next prev parent reply other threads:[~2017-11-13 10:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-05 23:48 Mats Jerratsch
[not found] ` <CAAUaCyii2U5VBLS+Va+F3h4Hka0OWDnFFmjtsvyaaD4TKVzV3Q@mail.gmail.com>
2017-11-06 19:21 ` Jacob Eliosoff
2017-11-08 16:45 ` Mats Jerratsch
2017-11-09 20:45 ` Jacob Eliosoff
2017-11-09 21:01 ` Sjors Provoost
[not found] ` <CAAUaCygeOxAK=EpzfWndx6uVvVO9B+=YTs1m-jHa3BFp82jA4w@mail.gmail.com>
[not found] ` <95ECB451-56AE-45E5-AAE6-10058C4B7FD7@sprovoost.nl>
[not found] ` <CAAUaCyg_PGT0F=RHfX89T54j-vuyz5wcbXaYoikJv95WKgsNPg@mail.gmail.com>
[not found] ` <55467A01-A8B2-4E73-8331-38C0A7CD90EF@sprovoost.nl>
[not found] ` <CAAUaCyhncyCt_ao9i0=33LswDOkCf6o-+36zrGxKWD+WranmZw@mail.gmail.com>
[not found] ` <46E317DF-C97C-4797-B989-594298BC6030@sprovoost.nl>
[not found] ` <CAAUaCyibOEHqw1J5O8yEp8v=j8t9sovn2vn=S8bZPZCzCY-gRw@mail.gmail.com>
2017-11-10 11:28 ` Mats Jerratsch
2017-11-11 5:18 ` Jacob Eliosoff
2017-11-13 10:03 ` Mats Jerratsch [this message]
2017-11-13 15:31 ` Jacob Eliosoff
2017-11-13 17:02 ` Spartacus Rex
2017-11-14 13:49 ` Mats Jerratsch
2017-11-15 5:02 ` Jacob Eliosoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com \
--to=mats@blockchain$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jacob.eliosoff@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox