path: root/a5/cd3ea78cea938066f94f79fba18cdbfdaf3395

Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AA89DB80
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 26 Jan 2017 03:29:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 98A72177
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 26 Jan 2017 03:29:21 +0000 (UTC)
Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6])
	by mail.bluematt.me (Postfix) with ESMTPSA id 887B51366F4;
	Thu, 26 Jan 2017 03:29:18 +0000 (UTC)
To: Johnson Lau <jl2012@xbt.hk>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <93ac7433-470c-d59e-e085-29f0f1613676@mattcorallo.com>
Date: Thu, 26 Jan 2017 03:29:14 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <A182F080-F154-4F05-B2F1-21B90E469267@xbt.hk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Anti-transaction replay in a hardfork
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2017 03:29:22 -0000

"A. For users on both existing and new fork, anti-replay is an option,
not mandatory"

To maximize fork divergence, it might make sense to require this. Any
sensible proposal for a hard fork would include a change to the sighash
anyway, so might as well make it required, no?

Matt

On 01/24/17 14:33, Johnson Lau via bitcoin-dev wrote:
> This is a pre-BIP. Just need some formatting to make it a formal BIP
> 
> Motivation:
> 
> In general, hardforks are consensus rule changes that make currently
> invalid transactions / blocks valid. It requires a very high degree of
> consensus and all economic active users migrate to the new rules at the
> same time. If a significant amount of users refuse to follow, a
> permanent ledger split may happen, as demonstrated by Ethereum (“DAO
> hardfork"). In the design of DAO hardfork, a permanent split was not
> anticipated and no precaution has been taken to protect against
> transaction replay attack, which led to significant financial loss for
> some users.
> 
> A replay attack is an attempt to replay a transaction of one network on
> another network. It is normally impossible, for example between Bitcoin
> and Litecoin, as different networks have completely different ledgers.
> The txid as SHA256 hash guarantees that replay across network is
> impossible. In a blockchain split, however, since both forks share the
> same historical ledger, replay attack would be possible, unless some
> precautions are taken.
> 
> Unfortunately, fixing problems in bitcoin is like repairing a flying
> plane. Preventing replay attack is constrained by the requirement of
> backward compatibility. This proposal has the following objectives:
> 
> A. For users on both existing and new fork, anti-replay is an option,
> not mandatory.
> 
> B. For transactions created before this proposal is made, they are not
> protected from anti-replay. The new fork has to accept these
> transactions, as there is no guarantee that the existing fork would
> survive nor maintain any value. People made time-locked transactions in
> anticipation that they would be accepted later. In order to maximise the
> value of such transactions, the only way is to make them accepted by any
> potential hardforks.
> 
> C. It doesn’t require any consensus changes in the existing network to
> avoid unnecessary debate.
> 
> D. As a beneficial side effect, the O(n^2) signature checking bug could
> be fixed for non-segregated witness inputs, optionally.
> 
> Definitions:
> 
> “Network characteristic byte” is the most significant byte of the
> nVersion field of a transaction. It is interpreted as a bit vector, and
> denotes up to 8 networks sharing a common history.
> 
> “Masked version” is the transaction nVersion with the network
> characteristic byte masked.
> 
> “Existing network” is the Bitcoin network with existing rules, before a
> hardfork. “New network” is the Bitcoin network with hardfork rules. (In
> the case of DAO hardfork, Ethereum Classic is the existing network, and
> the now called Ethereum is the new network)
> 
> “Existing network characteristic bit” is the lowest bit of network
> characteristic byte
> 
> “New network characteristic bit” is the second lowest bit of network
> characteristic byte
> 
> Rules in new network:
> 
> 1. If the network characteristic byte is non-zero, and the new network
> characteristic bit is not set, this transaction is invalid in the new
> network. (softfork)
> 
> 2. If the network characteristic byte is zero, go to 4
> 
> 3. If the network characteristic byte is non-zero, and the new network
> characteristic bit is set, go to 4, regardless of the status of the
> other bits.
> 
> 4. If the masked version is 2 or below, the new network must verify the
> transaction with the existing script rules. (no change)
> 
> 5. If the masked version is 3 or above, the new network must verify the
> signatures with a new SignatureHash algorithm (hardfork). Segwit and
> non-segwit txs will use the same algorithm. It is same as BIP143, except
> that 0x2000000 is added to the nHashType before the hash is calculated.
> 
> Rules in the existing network:
> 
> 6. No consensus rule changes is made in the existing network.
> 
> 7. If the network characteristic byte is non-zero, and the existing
> network characteristic bit is not set, this transaction is not relayed
> nor mined by default (no change)
> 
> 8. If the network characteristic byte is zero, no change
> 
> 9. If the network characteristic byte is non-zero, and the existing
> network characteristic bit is set, the masked version is used to
> determine whether a transaction should be mined or relayed (policy change)
> 
> 10. Wallet may provide an option for setting the existing network
> characteristic bit.
> 
> 
> Rationales (by rule number):
> 
> 1. This makes sure transactions with only existing network
> characteristic bit set is invalid in the new network (opt-in anti-replay
> for existing network transactions on the new network, objective A)
> 
> 2+4. This makes sure time-locked transactions made before this proposals
> are valid in the new network (objective B)
> 
> 2+5. This makes sure transactions made specifically for the new network
> are invalid in the existing network (anti-replay for new network
> transactions on the old network); also fixing the O(n^2) bug (objectives
> A and D)
> 
> 3. This is to prepare for the next hardfork from the new network
> (objective A)
> 
> 6, 7, 8. These minimise the change to the existing network (objective C)
> 
> 9, 10. These are not strictly needed until a hardfork is really
> anticipated. Without a significant portion of the network and miners
> implement this policy, however, no one should create such transactions.
> (objective A)
> 
> 
> Limitations:
> 
> * It is not possible to protect transactions made before the proposal.
> To avoid a replay of such transactions, users should first spend at
> least a relevant UTXO on the new network so the replay transaction would
> be invalidated.
> 
> * It is up to the designer of a hardfork to decide whether this proposal
> is respected. As the DAO hardfork has shown how harmful replay attack
> could be, all hardfork proposals (except trivial and totally
> uncontroversial ones) should take this into account
> 
> * The size of network characteristic byte is limited to 8 bits. However,
> if we are sure that some of the networks are completely abandoned, the
> bits might be reused.
> 
> 
> Reference implementation:
> 
> A demo is available in my forcenet2
> branch: https://github.com/jl2012/bitcoin/commit/7c2593946c4f3e210683110782d82f55473c682a
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013472.html
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>