fast lane

gistfile1.txt

Given the general resistance of people to concept ACK a specific
transaction topology like V3, I was thinking it would be useful
to think ahead and see what policy relaxations or restrictions
we could enact in the future to make things more flexible,
incentive compatible, and overall more useful.

TL;DR: V3 is useful and likely upgradeable to something
we can be more proud of.

Here are some ideas on what path we could take. Here's a set
of possible paths we could take, with explanations later:
```mermaid height=728,auto
flowchart TD
    V3([V3]) -->|cpfp carveout maybe dead| C
    C([Cluster mempool]):::required
    C -.->|V3, but child top\nblock| V3.0.5([V3.0.5])
    V3.0.5 -->|any topo,\nnon-single tx\ntop block| V3.1([V3.1])
    C -->|small cluster,\ntop block\nonly| V4a([V4a])
    V4a:::genvict -->|any vsize cluster| V4b([V4b]):::genvict
    V3.1:::genvict -.->|topblockify  single tx| V4b
    V4b -->|<= X vbytes\nnon-top block| V4c([V4c]):::genvict

    Tx([Requires General Sibling Eviction?]):::genvict

    classDef required fill:#aaaaaa
    classDef genvict fill:#FF7F50
```

Cluster mempool is a blocker for everything below it.
Black dots have minminal sibling eviction, orange
would require a more general solution if we wanted
to offer it. Dotted lines represent tightening of
policy from a prior step.

Not everything here has to be deployed, as any step,
aside from cluster mempool, can be skipped. It's 
possible we could end up with two separate opt-in
policies as well(denoted 3 and 4) depending on use-cases
and demand.

"top block" refers to whatever level we want.
Could be "chunk would enter the first or second block even
if we estimate 10 minutes of additional inflow", or whatever
statistical massaging we want to reduce pins.

"goldfinger++" is the concept where an adversary either
knows or induces a transaction load in the mempool,
such that all the V3-like transactions become
buried on each other, and may be unable to reorder
due to pinning induced by the attacker. The "++" is 
to indicate the pin vector which allows the attacker
to possibly choose the order in which the defender's
transactions are mined, vs the base case where defenders
would be able to effectively RBF their own transactions,
even though mempool contention would skyrocket.

# V3

One parent, up to one <=1kvB child.

Pros:
Trivially "correct" sibling eviction
It's coded. Relatively simple. Doesn't require cluster mempool.
Reduces max pinning ~100x, and package limit pinning for this topology.
Requires more minimal relay changes to fully use, like 1p1c relay
Ephemeral anchors naturally fits under V3 topology rules.

Cons:
Not clearly incentive compatible: If we're asking wallets to make structural
 changes beyond flipping a bit, is that too much?
1kvB is a guess on what size is required for a CPFP, so it leaves pinning potential
  along with the potential that it's not even big enough for larger value bumps.
Does not support batched CPFP.
Does not fix ANYONCANPAY usage and some useful single tx RBF fee cases.
Does not support chains of larger than two, such as 0-conf channel funding chains,
  or chains from presigned/CTV trees, two CPFPs of an anchor, etc.

As we can see, V3 leaves a lot to be desired, but can be done today
with known pinning bounds.
  
# V3.0.5

Deploy V3.
Deploy Cluster Mempool.
Require "top block" for V3 *child* (parent can still just hit minfee)
Relax child size(?)

Pros:
Small leap from V3
Allows wallets to not always shoot for top block, unless they need a CPFP
Less/no more guesswork on CPFP size
Maintains trivial sibling eviction

Cons:
Same topologically based cons as V3.
"goldfinger attack++" could introduce pin up to whatever
child size we allow.

This is both a tightening and relaxation of policy, which is arguably
more incentive compatible, and blunts a lot of pinning attacks. Single
transactions are allowed to relay at any feerate about minfee.

# V3.1

Deploy V3.
Deploy Cluster Mempool.
Require "top block" for any cluster size of 2 or more

Pros:
Relaxed topology allows anything normally representable, allowing
  for easier migration for wallet systems, provided they can be
  aggressive about fees when making size 2+ clusters.
Multi-tx pin-resistant constructs possible.
Still allows for less-fee-aggressive size 1 clusters that can be later
 bumped or batched in more fee-aggressive way in less adversarial settings.
If the parent is 0-fee(and SIGHASH_ALL), it's relatively pin
  resistant since getting CPFP into mempool
  requires top-block. Smart contracts can do less introspection of
  other people's scripts.

Cons:
Trivial sibling eviction is gone once cluster breaches size 2, requires work to replace with something more
  general.
  Ephemeral anchors is not a replacement for sibling eviction in general.
Both endogenous and exogenous fee single transaction RBF transactions are not pin
  resistant in general. Parent contract can be inflated with 0-fee
  junk then put into the mempool just above minfee. 
"goldfinger attack++" or fee spikes could introduce pin


V4, take 2, (a)
===
To enter mempool the tx must be entering "top block".
Cluster can only be <= X kvB

Pros:
No topo restrictions. It's a switch you flip.
ANYONECANPAY support. Endogenous and exogenous single tx RBF are pin resistant.
Less pinning potential from golfinger++ and fee spikes
Limit could be expanded later with more research/reasoning

Cons:
Makes it cheaper to hit cluster size limits under ~11kvB (99*111vbyte txns to max cluster count)
  without "trivial" sibling eviction to mitigate. Might want to think more about this.
Size restriction may stop usage like LN commitment tx, ln-symmetry settlement tx, unless
  HTLC number restricted (though it looks like 10kvB would support almost 230 HTLCs...)


V4, take 2, (b)
===
To enter mempool the tx must be entering "top block".

Pros:
Same as (a)
Not much to bikeshed about.
More obviously incentive compatible
Easy to reason about under same cluster limits as usual.

Cons:
"goldfinger attack++" or fee spikes could introduce large pin
"normal" transactions won't propagate unless they're top block.
It might not be useful enough to get widespread usage from non-time
sensitive usecases? 

V4, take 2, (c)
===
V4(b), with a relaxation:
i) if single tx and <= X vbytes, allow non-top block
XOR
ii) if chunk being added is <= X vbytes out of top block, allow

Pros:
V4(b), but allows more natural non-top block usage
Allows more backlog to build.
One opt-in policy to rule them all?
i) A bit more pinning robust
ii) A bit more general, allows small tx chains

Cons:
Reintroduces the bikeshed, and easier-to-pin amount.

If 90% of non-conslidation transactions are single clusters of size 300 vbyte
or less, could this allow for more broad usage, and only a single opt-in
policy for anti-pin?

edit