Commit graph

8 commits

Author SHA1 Message Date
glozow
539404fe0f [policy] make v3 transactions standard
Note that, as CURRENT_VERSION = 2, the wallet will not make transactions
with nVersion=3 yet.
2024-06-02 08:54:50 +02:00
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
glozow
a29f1df289 [policy] restrict all v3 transactions to 10kvB 2024-05-21 15:06:55 +01:00
Suhas Daftuar
f8a141c2da test: Don't rely on incentive incompatible replacement in mempool_accept_v3.py 2024-04-29 12:15:30 -04:00
glozow
1342a31f3a [functional test] sibling eviction 2024-03-01 15:24:13 +00:00
glozow
170306728a [policy] sibling eviction for v3 transactions 2024-03-01 15:23:03 +00:00
glozow
6b161cb82a [test] second child of a v3 tx can be replaced individually
Co-authored-by: ismaelsadeeq <ask4ismailsadiq@gmail.com>
2024-02-12 14:57:19 +00:00
glozow
1fd16b5c62 [functional test] v3 transaction submission
Co-authored-by: Suhas Daftuar <sdaftuar@gmail.com>
Co-authored-by: Gregory Sanders <gsanders87@gmail.com>
2024-02-08 21:50:55 +00:00