From 1ee5c4ccbda3c31c89c22139a23e2031dfcb2947 Mon Sep 17 00:00:00 2001 From: Calin Culianu Date: Sun, 14 Aug 2022 19:06:24 +0000 Subject: [PATCH] Update CHIP-2021-01-Allow Smaller Transactions.md --- CHIP-2021-01-Allow Smaller Transactions.md | 32 +++++++++++++--------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/CHIP-2021-01-Allow Smaller Transactions.md b/CHIP-2021-01-Allow Smaller Transactions.md index 780d576..2e8a1e0 100644 --- a/CHIP-2021-01-Allow Smaller Transactions.md +++ b/CHIP-2021-01-Allow Smaller Transactions.md @@ -2,14 +2,14 @@ ## Summary -This proposal updates the rule for minimum transation size to clean up technical debt which causes harm and while still protecting users on SPV nodes from being harmed by an attacker. +This proposal updates the rule for minimum transation sizes in order to simplify the burden on library software and on mining software, while still protecting users of SPV nodes from being harmed by an attacker. It reduces the current consensus minimum transaction size of 100 bytes down to a minimum size of 65 bytes. This more relaxed 65-byte minimum size, like the previous 100-byte minimum size, applies to both coinbase and non-coinbase transactions uniformly. > Title: Allow Transactions to be smaller in size > Date: 2021-01 > Type: Consensus > Status: Draft -> Version: 0.3 -> Last edit: 2021-03-14 +> Version: 0.4 +> Last edit: 2022-8-14 > Owner: Tom Zander > History: https://gitlab.com/bitcoin.cash/chips @@ -27,29 +27,34 @@ In the November 2018 Protocol upgrade Bitcoin Cash reacted to this by making the This solution, however, created several problems. -The first and most hit is that a default coinbase transaction is smaller than 100 bytes. This means that new mining software creating a coinbase will often hit this limit which is an expensive mistake to make. +The first and most often encountered problem is that a default coinbase transaction is smaller than 100 bytes (in many common cases it is 98 bytes or smaller). This means that new mining software creating a coinbase will often not satisfy the 100-byte minimum (which is an expensive mistake to make). -Alternative transaction types can be created which are similar smaller than 100 bytes, completely valid transactions. +Additionally, it is possible to create non-standard transactions which are smaller than 100 bytes, and which are completely valid transactions (although they are not accepted for relaying on main net). -These usecases all show that the entire ecosystem needs to take this limit into account, a limit unique to Bitcoin Cash. And a limit that is rather arbitrary. +These usecases all show that the entire ecosystem needs to take this rather large minimum into account, a minimum which is unique to Bitcoin Cash (Bitcoin Core does have an 82-byte minimum but it is for relaying-only and does not apply to mined transaction), and a minimum that has been rather arbitrarily chosen and, in hindsight, has proven to be too large. + +Because the minimum is rather large, developers of libraries and software will inadvertently violate this minimum in many cases as well in their libraries and testing software where the transactions created for testing may not be about real money, and thus the scripts will not reflect reality (such as trivial non-standard `OP_TRUE` locking scripts). There are many places where automated testing systems had to be adjusted to account for this 100-byte minimum. Reducing the minimum to 65 bytes is far less likely to trigger errors in such systems + +## An Alternative Approach + +An alternative approach would have been to not have a *minimum* size at all, per se, but rather instead to simply forbid transactions that are *precisely* 64-bytes in size. This would eliminate the leaf node merkle attack, while still offering testing libraries the option to create transactions sized 60, 61, 62 or 63 bytes (the smallest possible transaction one can ever create is 60 bytes). However, during discussion of this CHIP it was argued that since we already have a minimum size, it is easier on existing software to simply relax the 100-byte minimum (which is often implemented simply as a programming constant) down to 65 bytes (thus requiring a simple programming constant change, rather than the slightly increased programming complexity of requiring a minimum pre-activation of the upgrade, while forbidding exactly one specific value post-activation). + +Moreover, it was opined by some node engineers that it is more likely for software that creates transactions to trigger an error if consensus imposes a minimum size, in which case authors of libraries would be more likely to be made "aware" of Bitcoin Cash's own peculiar rules regarding transaction sizes. If we allowed sizes of 60, 61, 62, & 63, then it might be more likely that software authors that develop for BCH and that maintain software that can create very small transactions would never even notice that just the 64-byte size is forbidden, whereas if a range of sizes is disallowed (60-64), the likelihood would be increased for a developer to notice that BCH has peculiar rules for small transaction sizes. -Developers of libraries and software will hit this limit in many cases as well in their library testing software where the transactions created for testing are not about real money, and thus the scripts will not reflect reality. There are many places where automated testing systems had to be adjusted to account for this 100 bytes limit. ## Impact / Costs and Risks The impact on the ecosystem is split into full nodes and others. -* Full nodes need to change the current test for minimum size of a transaction to now check the transaction is any size other than 64 bytes. This is a widening of the allowed transactions and therefore should be scheduled for a future protocol upgrade. +* Full nodes must simply relax the consensus test from 100 bytes down to 65 bytes. This is a widening of the allowed transaction consensus rules and therefore should be scheduled for a future protocol upgrade. Nodes do need to ensure that the test uses the right minimum sizes both pre-activation and post-activation of the upgrade. -* All the players that are not full nodes do not have to change anything, as anything they generated before is still allowed. +* All the players that are not full nodes do not have to change anything, as anything they generated before that safisfied the old 100-byte minimum is still allowed under the more relaxed 65-byte minimum. -This CHIP is mostly aimed at cleaning up technical debt. The result is less rules for most software. Additionally should this get solved in future on the p2p layer, then we can simply drop even the new rule. +This CHIP is mostly aimed at cleaning up technical debt. The result is a more relaxed minimum for most software, making it less likely that normally operating sofware will violate the new more relaxed minimum. Additionally, should the 64-byte transaction size exploit get solved in the future on the p2p layer, then we can simply drop any rules enforcing a minimum transaction size altogether. ## Proposal Description -To solve the unintended side-effects of the 100-bytes minimum, we simply remove this limit. - -To avoid the weakness in merkle-blocks we introduce the rule that transactions shall not be 64 bytes in size. +To solve the unintended side-effects of the rather aggressive 100-byte minimum, we simply relax this minimum to 65 bytes. This minimum size applies to both coinbase and non-coinbase transactions uniformly. ## References: @@ -71,6 +76,7 @@ Discussion on [bitcoincashresearch](https://bitcoincashresearch.org/t/154) ## Copyright Notice Copyright (C) 2021 Tom Zander +Copyright (C) 2022 Calin Culianu Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3