Ava Chow 867f6af803 Merge bitcoin/bitcoin#29873: policy: restrict all TRUC (v3) transactions to 10kvB ... 154b2b2296 [fuzz] V3_MAX_VSIZE and effective ancestor/descendant size limits (glozow) a29f1df289 [policy] restrict all v3 transactions to 10kvB (glozow) d578e2e354 [policy] explicitly require non-v3 for CPFP carve out (glozow) Pull request description: Opening for discussion / conceptual review. We like the idea of a smaller maximum transaction size because: - It lowers potential replacement cost (i.e. harder to do Rule 3 pinning via gigantic transaction) - They are easier to bin-pack in block template production - They equate to a tighter memory limit in data structures that are bounded by a number of transactions (e.g. orphanage and vExtraTxnForCompact). For example, the current memory bounds for orphanage is 100KvB * 100 = 40MB, and guaranteeing 1 tx per peer would require reserving a pretty large space. History for `MAX_STANDARD_TX_WEIGHT=100KvB` (copied from https://github.com/bitcoin/bitcoin/pull/29873#issuecomment-2115459510): - 2010-09-13 In 3df62878c3 satoshi added a 100kB (MAX_BLOCK_SIZE_GEN/5 with MBS_GEN = MAX_BLOCK_SIZE/2) limit on new transactions in CreateTransaction() - 2013-02-04 https://github.com/bitcoin/bitcoin/pull/2273 In gavin gave that constant a name, and made it apply to transaction relay as well Lowering `MAX_STANDARD_TX_WEIGHT` for all txns is not being proposed, as there are existing apps/protocols that rely on large transactions. However, it's been brought up that we should consider this for TRUCs (which is especially designed to avoid Rule 3 pinning). This reduction should be ok because using nVersion=3 isn't standard yet, so this wouldn't break somebody's existing use case. If we find that this is too small, we can always increase it later. Decreasing would be much more difficult. ~[Expected size of a commitment transaction](https://github.com/lightning/bolts/blob/master/03-transactions.md#expected-weight-of-the-commitment-transaction) is within (900 + 172 * 483 + 224) / 4 = 21050vB~ EDIT: this is incorrect, but perhaps not something that should affect how we choose this number. ACKs for top commit: sdaftuar: ACK 154b2b2296 achow101: ACK 154b2b2296 instagibbs: ACK 154b2b2296 t-bast: ACK 154b2b2296 murchandamus: crACK 154b2b2296 Tree-SHA512: 89392a460908a8ea9f547d90e00f5181de0eaa9d2c4f2766140a91294ade3229b3d181833cad9afc93a0d0e8c4b96ee2f5aeda7c50ad7e6f3a8320b9e0c5ae97		2024-05-23 11:54:18 -04:00
..
feerate.cpp	scripted-diff: Bump copyright headers	2022-12-24 23:49:50 +00:00
feerate.h	Add multiplication operator to CFeeRate	2023-12-09 09:33:45 -05:00
fees.cpp	Don't use scientific notation in log messages	2024-01-31 21:20:05 +02:00
fees.h	tx fees, policy: CBlockPolicyEstimator update from CValidationInterface notifications	2023-11-22 11:48:21 +01:00
fees_args.cpp	move-only: Extract common/args and common/config.cpp from util/system	2023-04-19 10:48:30 +02:00
fees_args.h	refactor: Move fs.* to util/fs.*	2023-03-23 12:55:18 +01:00
packages.cpp	[txpackages] use std::lexicographical_compare instead of sorting hex strings	2024-05-01 13:34:37 +01:00
packages.h	[txpackages] add canonical way to get hash of package	2024-04-26 10:28:27 +01:00
policy.cpp	Replace remaining "520" magic numbers with MAX_SCRIPT_ELEMENT_SIZE	2024-05-02 13:16:40 -06:00
policy.h	doc: fix typos	2023-11-07 10:21:51 +09:00
rbf.cpp	Avoid explicitly computing diagram; compare based on chunks	2024-04-22 09:36:36 -04:00
rbf.h	Implement ImprovesFeerateDiagram	2024-03-18 10:32:00 -04:00
settings.cpp	scripted-diff: Bump copyright headers	2022-12-24 23:49:50 +00:00
settings.h	scripted-diff: Bump copyright headers	2022-12-24 23:49:50 +00:00
v3_policy.cpp	[policy] restrict all v3 transactions to 10kvB	2024-05-21 15:06:55 +01:00
v3_policy.h	[policy] restrict all v3 transactions to 10kvB	2024-05-21 15:06:55 +01:00