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 0467DA7A for ; Thu, 9 Nov 2017 21:01:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3236816A for ; Thu, 9 Nov 2017 21:01:15 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E533A20B4C; Thu, 9 Nov 2017 16:01:13 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 09 Nov 2017 16:01:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=S4hXgGSSRIXl2TBGf0XL/+sBoBB+itLGspyBtlmaQSQ=; b=AGcGUZ6W Os0DyHOQCWa1svPORymz3Rs8jwoo2cJ9OnCpj9fBXxeMXv8WBGmL68dmHlos/WCZ kndKmrERkAqysCAvrlgxhQ1iAbvOipEUwiKlgpBnDDcKKridajx/+da26vvZRqhK 7LgdOmHlUp3Xp6zTKy2xKdUbEm1YfeITdg3VpGobprOmvzyPWjc+Jq8aYDfXJ9Xs gx84HrTteZREgI3Zlc0qd+DjLHHfu0/6X0cVBgp6c3Hs7bFwQG9zuOxbVCNoQnPV YQcekzRHK39JU2/oR3AWH/as0UaXzntaBNZAOY3DBxXm3CsXseF0tFne4hQ/FroC vk/jfkSYSjFgWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=S4hXgGSSRIXl2TBGf0XL/+sBoBB+i tLGspyBtlmaQSQ=; b=DYIj5o9gGuccMS4FqLT2Lpo1N0PgT623k7r/WYeizHAB1 bUKUaDbd9/aWOc+2fxm/MYDbRIr/QmMDxsMiKxT48tRZ2uHptUYZ1+8ZrRD6IXVY TW+nhpSbaC0AN9dPXm4X5uH918mLYi9eiQGt4v9p3+CJW+qLUrz+X+tGNoLUXvEs GCuVEuRd7kN1Esn/EzX0u8DtnBL7GB3AVZm98+mgDwM4go0JUc2JmkpgDw8tYSUf 0z7R8WFI4mCKR8Zo4Hhhghq6OVlhjoPpwcSVJ9ovG2VXpBFPCiisrInDAYjvxIfU ipLMsRgXeWJHECrH33FMrzf4CuoXDBurwRcxnUgrA== X-ME-Sender: Received: from [192.168.178.108] (54693d0f.cm-12-2a.dynamic.ziggo.nl [84.105.61.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 0BE0C2469F; Thu, 9 Nov 2017 16:01:12 -0500 (EST) From: Sjors Provoost Content-Type: multipart/signed; boundary="Apple-Mail=_85419A66-6093-4A9D-AC8D-E4880707AB85"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Thu, 9 Nov 2017 22:01:10 +0100 References: <7601C2CD-8544-4501-80CE-CAEB402A72D2@blockchain.com> To: Bitcoin Protocol Discussion , Jacob Eliosoff , Mats Jerratsch In-Reply-To: Message-Id: <45C2D68B-BA8E-47DE-BFA5-643922395B2A@sprovoost.nl> X-Mailer: Apple Mail (2.3445.4.7) X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,RCVD_IN_DNSWL_LOW 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: Thu, 09 Nov 2017 21:03:34 +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: Thu, 09 Nov 2017 21:01:16 -0000 --Apple-Mail=_85419A66-6093-4A9D-AC8D-E4880707AB85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Op 9 nov. 2017, om 21:45 heeft Jacob Eliosoff via bitcoin-dev = het volgende geschreven: >=20 > As I understand you, a private key in cold storage would (of course) = remain valid across HFs, but an address would be valid only for the = nForkId it was generated for. There may be cold-storage-type cases = where it's important for an address to be valid across all chains, ie, = to intentionally allow replay? But I guess this could just be a special = nForkId value, say -1? If I understand the proposal correctly, you can always spend coins; it's = the next transaction that is replay protected. 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? Note that in your currently proposal nForkId is only in the transaction = signature pre-image. It's not in the serialized transaction, so a node = would just have to try to see if the signature is valid. I don't know if = that's a problem. Can you clarify what you mean with: > Allowing signatures with `nForkId=3D1` can be achieved with a soft = fork by incrementing the script version of SegWit, making this a fully = backwards compatible change. What's the purpose of nForkId 1? > potentially a way to opt-out of replay protection of any fork, where = deemed necessary (can be beneficial for some L2 applications). Can you give an example of where this opt-out would be useful? Why = wouldn't it be enough to just sign one transaction for each fork? In Spoonnet, the version number is added to the SIGHASH_TYPE in the = pre-image. Your solution of just adding another field seems easier, but = maybe there's a downside? Sjors [0] = https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32 --Apple-Mail=_85419A66-6093-4A9D-AC8D-E4880707AB85 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----- iQIzBAEBCgAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAloEwhYACgkQV/+b28ww EAl23BAAwO4AVIi6bHwtbxfM9MHSGWr/YL1hH+N29cuaCBz4vIRhTgvb86bQTnJy MiuiKGV8GjYZ2iIrLUTfhUBTdPzLgG8QVtzXvfMMUYeU/t1oOGBfh3Ui3vatNLyn Wzf8GeklD+K5NMmsC8ZiYrBubFOh/wqYPAKZY9J5qoA3VH1DN/OukfO+KYBUaONe 2WS6sPzNxUmvF00v1/FYrLFuY8cfB2gU7vyL5JFpTnPH22PMQylIUowzstfvMvTC tkB0rB521u7wdJbXl+Drs/ST3jHwQSl3QzZp7rnHGXWcbANmuT+iQVDXhdt0vl3b I+1gBep5XTzAmwwkFU3riqu7UcMm0V2BP8FYyLKOxAx0+l6ZI/+SHUuZzws3CuPA CEFCpUGQz6a+XNRz/j+lDapJ7pliB20TbX5lrmla12buLe5xWXVW+mKla3hhG2eX kAN/h43EeOucQ7D7xIjX9iK0Ws7/Nu2e1brJFcHfnn1z44Nn4+O+oYO3K4o4PXOT YnIhErphmLyl9BTF8gyZ+4sXftnSHZRbxO2+EpikfmxQDKSSXNr2UjrT/1BTq7kP NdOJf3eOJAkVujTfsj9jIssemWHj2voCmt7+YouQh4N8jLN3r1Jr0dfpSb+IuPui Tsr27JTGUR4a0ggzXcUCzPmB6dvyVBMWhL9P0flHG9wuESunMOI= =pJ6W -----END PGP SIGNATURE----- --Apple-Mail=_85419A66-6093-4A9D-AC8D-E4880707AB85--