public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
To: Mats Jerratsch <mats@blockchain.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:31:55 -0500	[thread overview]
Message-ID: <CAAUaCygjVDuqmVPS-1thnEbKgKYM9LW-7CsuAAnn7vqntMnWxA@mail.gmail.com> (raw)
In-Reply-To: <24A6C651-272B-4452-8A81-31651D9A2694@blockchain.com>

[-- Attachment #1: Type: text/plain, Size: 3756 bytes --]

>
> 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.
>

Thanks for the clarification.  How would a tx specify a constraint like
"nForkId>=1"?  I was thinking of it just as a number set on the tx.

Also note that since forks form a partial order, but IDs (numbers) form a
total order, ">=" will miss some cases.  Eg, suppose BCH had forked with
nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and
then Segwit2x forked (from BTC!) with nForkId 3.  The BCH funding tx would
be valid on Segwit2x.  This is more of a fundamental problem than a bug -
to avoid it you'd have to get into stuff like making each fork reference
its parent-fork's first block or something, someone has written about
this...


On Mon, Nov 13, 2017 at 5:03 AM, Mats Jerratsch <mats@blockchain.com> wrote:

>
> 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 #2: Type: text/html, Size: 4678 bytes --]

  reply	other threads:[~2017-11-13 15:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-05 23:48 [bitcoin-dev] Generalised Replay Protection for Future Hard Forks 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
2017-11-13 15:31                               ` Jacob Eliosoff [this message]
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=CAAUaCygjVDuqmVPS-1thnEbKgKYM9LW-7CsuAAnn7vqntMnWxA@mail.gmail.com \
    --to=jacob.eliosoff@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mats@blockchain.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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