From: Mats Jerratsch <mats@blockchain•com>
To: Spartacus Rex <spartacusrex99@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks
Date: Tue, 14 Nov 2017 13:49:56 +0000 [thread overview]
Message-ID: <71A64D11-DE57-4AA2-A635-F2AA4DC04909@blockchain.com> (raw)
In-Reply-To: <CA+Cf5AZT6KtRXmt3X6UiF0tP_hCtbUiUsS3XMXDdoaa0T1tepQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2937 bytes --]
> But I like the 'old' idea of putting the hash of a block that MUST be on the chain that this txn can eventually be added to. If the hash is not a valid block on the chain, the txn can't be added.
>
> It means you can choose exactly which forks you want to allow your txn on, pre-fork for both, post-fork for only one, and gets round the issue of who gets to decide the nForkid value.. since you don't need one. Also, all the old outputs work fine, and LN not an issue.
>
> I'm missing why this scheme would be better ?
I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the sense that they are very difficult to circumvent. However, a fork could also follow the original chain in SPV mode and allow transactions protected with these mechanism. Since it's fundamentally impossible to disallow transactions in future projects, the goal shouldn't be to make this overly complicated.
Furthermore, this schema is not just adding replay protection. It makes transacting safer overall (due to a dedicated address format per fork) and allows light clients to differentiate between multiple forks. In the past three months, at least $600k has been lost by users sending BCH to a BTC address [1].
> 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.
Whether the transaction is replay protected or not is specified by setting a bit in the `SigHashId`. If this bit is set, then the signature *preimage* MUST have `nForkId` appended. `nForkId` is not part of the final transaction, someone who wants to verify the transaction must know which `nForkId` it was created with.
If the bit isn't set, it means `nForkId=0`, which allows other forks to validate the signature.
> 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...
Sorry, I was careless with the use of `>=` there. You are correct, forks form a tree. For this proposal, every leaf must be assigned a unique `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which number is bigger), as long as they are unique. Transactions are only valid IFF `nForkId` matches exactly the `nForkId` of the software validating it. As described above, the transaction doesn't even contain `nForkId`, and the node surely is not starting to guess which one it could be.
[1]
https://twitter.com/khannib/status/930223617744437253 <https://twitter.com/khannib/status/930223617744437253>
[-- Attachment #1.2: Type: text/html, Size: 4309 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
next prev parent reply other threads:[~2017-11-14 13:50 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
2017-11-13 15:31 ` Jacob Eliosoff
2017-11-13 17:02 ` Spartacus Rex
2017-11-14 13:49 ` Mats Jerratsch [this message]
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=71A64D11-DE57-4AA2-A635-F2AA4DC04909@blockchain.com \
--to=mats@blockchain$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=spartacusrex99@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