This issue opens a brainstorm about introducing transaction issuer-selected policy limits.
Currently, all the policy limits are either static (e.g DUST_RELAY_TX_FEE or MIN_STANDARD_TX_NONWITNESS_SIZE)
or it can be set dynamically on the command-line by the node operator (e.g ancestors / descendants / incremental
tx-relay fee). New policy mechanism like v3 are introducing specific limit such as the 1000 vb limit on the single
child.
This approach is limited for some use-cases, as there is an interdependency between the policy limits and efficiency or loss of funds risks. E.g for LN, higher the v3 child limit, higher is the pinning risk exposure, i.e the amount of satoshis one can steal by slipping a pinning package under the child limit. Applying limit on child only can additionally miss to protect package propagation, as in LN context at least parent can be inflated according channel parameters.
I did a small proof-of-concept with #29448. After writing it, I realize this might be too much policy flexibility for now,
especially if transaction issuers-selected policy limits can introduce economic-induced performance asymmetries in the
low performance host, i.e what if tx-relay traffic starts to be materially segregated and this breaks BIP152 compact blocks
propagation (it might be fixed by being more aggrressive on prefilledtxn, however this assume “predictive” discrepancies
algorithms).
In terms of transaction or protocol fields where such opt-in transaction-issuer policy limits could be inserted among others:
- nSequence field - bip68 semantics to deal with
- nVersion field lower bits
- taproot annex
- p2p extensions e.g
ancpkginfoor a newissuer_wtxid, committing to a policy profile
I think it can be an interesting to experiment with a transaction-issuer selected limit for at least the 1000 vb limit.
Making it a dynamic limit in the limit of MAX_STANDARD_TX_WEIGHT applied on the whole v3 package. This would at least
address my strong concern that current v3 approach is realistically weak to address substantially pinning risks for LN.
Such transaction issuer-selected policy limits could be useful for a wide array of other use-cases. E.g iterative batching where you would like to have child of reasonable size to fanout payouts and fee-bump at the same-time.
Looking forward to thoughts.
