Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9019F989 for ; Fri, 10 Nov 2017 11:28:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 996988A for ; Fri, 10 Nov 2017 11:28:11 +0000 (UTC) Received: by mail-wr0-f170.google.com with SMTP id o88so8302425wrb.6 for ; Fri, 10 Nov 2017 03:28:11 -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=iTsKMG06N9stZ8xn+MRaSyP8Mj+UDutLjCqj1aixa2Q=; b=BjCIxp4IQf62XS9WrA7GPt16ShNFLKc9f4X3syMLOhypo22t7PhmQSlAq3yJs7HS8B i/oSxaNLDGWo4gk+ScCm9a2Mrm0dcBdvkjDpuW+nLdRo3SCOw2qBOXTr0KEC1Dm4MqJE tm9T93CgDtp4zlDsScx30ReV+mL2gGBOCA9Ks= 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=iTsKMG06N9stZ8xn+MRaSyP8Mj+UDutLjCqj1aixa2Q=; b=kORUHW57m9p91LIM8+2ioU+Uw28PoqjfNtDRjo3Lq0V8YS9kLL3Uwldv/06AvkgD0B ZfObp/V0za4rJrllBVZw10OInDRFAlk2q9poUEBuKQhBvhitHUhzG3N3bVN+oC8Ml7q/ Y1U3j3K8JWRBt1z/nHFWc5x/M1B+wBSXHPjZ36llav54fsaSMvlt0xTZoSJdYaCUAm9x 7pygPxZWqgrrjcgqaJgA0sk/sSwP9qZft47K+CK5TPw1P4ogVhh2wW1zmMDOBJK1O9eV yQP8dr0OPNcRrYnv9FpN3290zWHcGpwzCP3vluKHJwzhR/aA1ukA2QiXWjatSIFsLmsD OFvQ== X-Gm-Message-State: AJaThX4qN/IboksB+973RYmZAcAJEeDHW4IJeWZrAsXBfsHC1jHtWr6j Cs/VMYnhSjNhicxnkcRiQN2jBQ== X-Google-Smtp-Source: ABhQp+TglJDieVoott1dRZu+nPWTnCzkmCadP32TWGBnSKHkBMfn+9T8fQZYtttSxgYm9fEt5fVK0Q== X-Received: by 10.223.165.67 with SMTP id j3mr2927945wrb.271.1510313290103; Fri, 10 Nov 2017 03:28:10 -0800 (PST) Received: from [10.2.1.168] ([212.161.45.230]) by smtp.gmail.com with ESMTPSA id o8sm24795483wrc.10.2017.11.10.03.28.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 03:28:08 -0800 (PST) From: Mats Jerratsch Message-Id: <3FBEE883-A15E-425C-8BF1-F7792FA63961@blockchain.com> Content-Type: multipart/signed; boundary="Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 10 Nov 2017 11:28:06 +0000 In-Reply-To: To: Jacob Eliosoff , Bitcoin Dev 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> 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: Fri, 10 Nov 2017 23:42:47 +0000 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: Fri, 10 Nov 2017 11:28:12 -0000 --Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66 Content-Type: multipart/alternative; boundary="Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543" --Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I guess I wasn't clear on the wildcard, `nForkId=3D0` This proposal puts Bitcoin at `nForkId=3D1`, with the purpose of having = `nForkId=3D0` valid on *all* future forks. This means you can create a = `nLockTime` transaction, delete the private key and still be assured to = not lose potential future tokens. In theory `nForkId=3D0` could be used for an address too, the sending = wallet should display a warning message about unknown side effects = though. This address would be future-safe, and you can put it into a = safe-deposit box (even though I see little reason to back up an = _address_. You would always back up a _private key_, which translates = into funds on any fork.) Furthermore, `nForkId=3D0` can be used for L2 applications. Let's say = Alice and Bob open a payment channel. One week later, project X decides = to fork the network into a new token, implementing a custom way of = providing strong two-way replay protection. The protocol Alice and Bob = use for the payment channel has not implemented this new form of replay = protection. Alice and Bob now have to make a choice: (1) Ignore this new token. This comes with an evaluation of how much = this new token could be worth in the future. They will continue normal = channel operation, knowing that their funds on the other branch will be = locked up until eternity. When they close their payment channel, the = closing transaction will get rejected from the other network, because = it's not following the format for replay protected transactions. (2) Close the payment channel before the fork. The transaction, which = closes the payment channel has to be mined before the fork, potentially = paying a higher-than-normal fee. With this proposal implemented, there are two additional choices (3) Create the commitment transactions with `nForkId=3D0`. This ensures = that when the channel gets closed, funds on other chains are released = accordingly. This also means that after the fork, payments on the = channel move both, the original token and the new token. Potentially, = Alice and Bob want to wait before further transacting on the channel, to = see if the token has substantial value. If it has, they can *then* close = the channel and open a new channel again. (Note: The funding transaction = can use a specific `nForkId`, preventing you from locking up multiple = coins when funding the channel, but you can choose to settle with = `nForkId=3D0` to not lock up future coins) (4) Make the protocol aware of different `nForkId`. After the fork, the = participants can chose to *only* close the payment channel on the new = token, making the payment channel Bitcoin-only again. This is the = preferred option, as it means no disruption to the original network. > I like the idea of specifying the fork in bech32 [0]. On the other = hand, the standard already has a human readable part. Perhaps the human = readable part can be used as the fork id? I was considering this too. On the other hand, it's only _human = readable_ because thy bytes used currently encode 'bc'. For future = forks, this would just be two random letters than, but potentially = acceptable. --Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I guess I wasn't = clear on the wildcard, `nForkId=3D0`

This proposal puts Bitcoin at `nForkId=3D1`, with the purpose = of having `nForkId=3D0` valid on *all* future forks. This means you can = create a `nLockTime` transaction, delete the private key and still be = assured to not lose potential future tokens.

In theory `nForkId=3D0` could be used for an address too, the = sending wallet should display a warning message about unknown side = effects though. This address would be future-safe, and you can put it = into a safe-deposit box (even though I see little reason to back up an = _address_. You would always back up a _private key_, which translates = into funds on any fork.)

Furthermore, `nForkId=3D0` can be used for L2 applications. = Let's say Alice and Bob open a payment channel. One week later, project = X decides to fork the network into a new token, implementing a custom = way of providing strong two-way replay protection. The protocol Alice = and Bob use for the payment channel has not implemented this new form of = replay protection. Alice and Bob now have to make a choice:

(1) Ignore this new token. This = comes with an evaluation of how much this new token could be worth in = the future. They will continue normal channel operation, knowing that = their funds on the other branch will be locked up until eternity. When = they close their payment channel, the closing transaction will get = rejected from the other network, because it's not following the format = for replay protected transactions.

(2) Close the payment channel before the fork. The = transaction, which closes the payment channel has to be mined before the = fork, potentially paying a higher-than-normal fee.

With this proposal implemented, = there are two additional choices

(3) Create the commitment transactions with `nForkId=3D0`. = This ensures that when the channel gets closed, funds on other chains = are released accordingly. This also means that after the fork, payments = on the channel move both, the original token and the new token. = Potentially, Alice and Bob want to wait before further transacting on = the channel, to see if the token has substantial value. If it has, they = can *then* close the channel and open a new channel again. (Note: The = funding transaction can use a specific `nForkId`, preventing you from = locking up multiple coins when funding the channel, but you can choose = to settle with `nForkId=3D0` to not lock up future coins)

(4) Make the protocol aware of = different `nForkId`. After the fork, the participants can chose to = *only* close the payment channel on the new token, making the payment = channel Bitcoin-only again. This is the preferred option, as it means no = disruption to the original network.

> I like the idea of specifying the fork in bech32 [0]. On = the other hand, the standard already has a human readable part. Perhaps = the human readable part can be used as the fork id?

I was considering this too. On the = other hand, it's only _human readable_ because thy bytes used currently = encode 'bc'. For future forks, this would just be two random letters = than, but potentially acceptable. 

= --Apple-Mail=_E20B3D60-FE82-454C-ACB8-FAB724075543-- --Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66 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 iQIcBAEBCgAGBQJaBY1HAAoJEAYZmwZ/PsbKcFsQAM1O0c2lrlCqaTrUug05ZKZr KeLla73/NMBPbMgVnIriwKGijQBJ/UW76/TAWVGLOYx6C4TxtUnf75r/LsRUCEcF lX4GtMVurzHWQNOjUNjYXh1vzAGedlN+G34wUI6VbBmdr8eco//KBJqWNCNV/F29 GHFiPtoI5x43LvJa8AeFO7htaiQAhyu3PfTNFZk9BO3xNUUK8nDN5cPvd/1cWEYl asumhh8FZOKyAmbduuoMlReAWxfdtRHVIHT49wkooUN5kjqohtjry9lePYm/UHfk yEYQ4YAyY1key0Q5u8DnLUR/8l1hHLWttEoOayg/+m+HPsJsOG36cORzDfdsihDP XjMfyS1ze5xfDOusrxI5EOSQ51ikNqud2Mp52vFaO8zWL+q/y6S7UjA+fXT72WAS 9TPSYzrD4cct03pW7zEKTwVr9EtjJk4B9kl39a2EapXzQm9Onqybyw9ulm1oNWoz TaEsfmRfs4RPfFCEcuPpgtlH8azYGbomQ+0ZBfd3Wa1iMhqMYABNX7JJ1ZaWz9zY uGk5gEDiyNO1xJrJVuPVEpEInwUJqslq1dsIiib4MqZTdhFJ3biX32dre47Yrtpk ltuIoA1ai5qdY6vuYsVpTnsGjmE3QSOzDAVWWN4vEf4iqUB882XpaiFUymccD+fQ Wy+G9+SFc12Ndy6K5ATG =pIiO -----END PGP SIGNATURE----- --Apple-Mail=_09F87902-A8BC-478C-9D30-E6FC273B2C66--