Date: Sat, 12 Mar 2022 18:08:39 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <Udzkz8ZPM4na6yNcGnINLCskodTve66hhpoXevwYuVVgfWfbJnLH70Btmp_dmvk8X8sNXqywBVviG3OzFzeoXQanPb8KkWNGjKG2mxxDsAo=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Covenants and feebumping
Precedence: list

The idea of a soft fork to fix dynamic fee bumping was recently put back on=
 the table. It might
sound radical, as what prevents today reasonable fee bumping for contracts =
with presigned
transactions (pinning) has to do with nodes' relay policy. But the frustrat=
ion is understandable
given the complexity of designing fee bumping with today's primitives. [0]
Recently too, there was a lot of discussions around covenants. Covenants (c=
onceptually, not talking
about any specific proposal) seem to open lots of new use cases and to be d=
esired by (some?) Bitcoin
application developers and users.
I think that fee bumping using covenants has attractive properties, and it =
requires a soft fork that
is already desirable beyond (trying) to fix fee bumping. However i could no=
t come up with a solution
as neat for other protocols than vaults. I'd like to hear from others about=
 1) taking this route for
fee bumping 2) better ideas on applying this to other protocols.


In a vault construction you have a UTxO which can only be spent by an Unvau=
lting transaction, whose
output triggers a timelock before the expiration of which a revocation tran=
saction may be confirmed.
The revocation transaction being signed in advance (typically before sharin=
g the signature for the
Unvault transaction) you need fee bumping in order for the contract to actu=
ally be enforceable.

Now, with a covenant you could commit to the revocation tx instead of presi=
gning it. And using a
Taproot tree you could commit to different versions of it with increasing f=
eerate. Any network
monitor (the brooadcaster, a watchtower, ..) would be able to RBF the revoc=
ation transaction if it
doesn't confirm by spending using a leaf with a higher-feerate transaction =
being committed to.

Of course this makes for a perfect DoS: it would be trivial for a miner to =
infer that you are using
a specific vault standard and guess other leaves and replace the witness to=
 use the highest-feerate
spending path. You could require a signature from any of the participants. =
Or, at the cost of an
additional depth, in the tree you could "salt" each leaf by pairing it with=
 -say- an OP_RETURN leaf.
But this leaves you with a possible internal blackmail for multi-party cont=
racts (although it's less
of an issue for vaults, and not one for single-party vaults).
What you could do instead is attaching an increasing relative timelock to e=
ach leaf (as the committed
revocation feerate increases, so does the timelock). You need to be careful=
 to note wreck miner
incentives here (see [0], [1], [2] on "miner harvesting"), but this enables=
 the nice property of a
feerate which "adapts" to the block space market. Another nice property of =
this approach is the
integrated anti fee sniping protection if the revocation transaction pays a=
 non-trivial amount of
fees.

Paying fees from "shared" funds instead of a per-watchtower fee-bumping wal=
let opened up the
blackmail from the previous section, but the benefits of paying from intern=
al funds shouldn't be
understated.
No need to decide on an amount to be refilled. No need to bother the user t=
o refill the fee-bumping
wallet (before they can participate in more contracts, or worse before a de=
adline at which all
contracts are closed). No need for a potentially large amount of funds to j=
ust sit on a hot wallet
"just in case". No need to duplicate this amount as you replicate the numbe=
r of network monitors
(which is critical to the security of such contracts).
In addition, note how modifying the feerate of the revocation transaction i=
n place is less expensive
than adding a (pair of) new input (and output), let alone adding an entire =
new transaction to CPFP.
Aside, and less importantly, it can be made to work with today's relay rule=
s (just use fee thresholds
adapted to the current RBF thresholds, potentially with some leeway to acco=
unt for policy changes).
Paying from shared funds (in addition to paying from internal funds) also p=
revents pervert
incentives for contracts with more than 2 parties. In case one of the parti=
es breaches it, all
remaining parties have an incentive to enforce the contract.. But only one =
would otherwise pay for
it! It would open up the door to some potential sneaky techniques to wait f=
or another party to pay
for the fees, which is at odd with the reactive security model.

Let's examine how it could be concretely designed. Say you have a vault wal=
let software for a setup
with 5 participants. The revocation delay is 144 blocks. You assume revocat=
ion to be infrequent (if
one happens it's probably a misconfigured watchtower that needs be fixed be=
fore the next
unvaulting), so you can afford infrequent overpayments and larger fee thres=
holds. Participants
assume the vault will be spent within a year and assume a maximum possible =
feerate for this year of
10ksat/vb.
They create a Taproot tree of depth 7. First leaf is the spending path (ope=
n to whomever the vault
pays after the 144 blocks). Then the leaf `i` for `i` in `[1, 127]` is a co=
venant to the revocation
transaction with a feerate `i * 79` sats/vb and a relative timelock of `i -=
 1` blocks.
Assuming the covenant to the revocation transaction is 33 bytes [3], that's=
 a witness of:
    1 + 33     + 1 + 33 + 7 * 32 =3D 292 WU (73 vb)
    ^^^^^^       ^^^^^^^^^^^^^^
    witscript     control block
for any of the revocation paths. The revocation transaction is 1-input 1-ou=
tput, so in total it's
    10.5 +   41 + 73      + 43    =3D 167.5 vb
    ^^^^    ^^^^^^^^^^^    ^^^^
    header  input|witness  output
The transaction size is not what you'd necessarily want to optimize for fir=
st, still, it is smaller
in this case than using other feebumping primitives and has a smaller footp=
rint on the UTxO set. For
instance for adding a feebumping input and change output assuming all Tapro=
ot inputs and outputs
(CPFP is necessarily even larger):
    5 * 64 +  1 + 5 * (32 + 1) + 1 + 33 =3D 520 WU (105 vb)
    ^^^^^^    ^^^^^^^^^^^^^^^    ^^^^^^
    witness      witscript       control
    10.5  +  41 + 105      + 41 + 16.5         + 2 * 43  =3D 300 vb
    ^^^^     ^^^^^^^^        ^^^^^^^^^           ^^^^^^
    header   input|witness   fb input|witness    outputs
From there, you can afford more depths at the tiny cost of 8 more vbytes ea=
ch. You might want them
for:
- more granularity (if you can afford large enough timelocks)
- optimizing for the spending path rather than the revocation one
- adding a hashlock to prevent nuisance (with the above script a third part=
y could malleate a
  spending path into a revocation one). You can use the OP_RETURN trick fro=
m above to prevent that.

Unfortunately, the timelocked-covenant approach to feebumping only applies =
to bumping the first
transaction of a chain (you can't pay for the parent with a timelock) so fo=
r instance it's not
usable for HTLC transactions in Lightning to bump the parent commitment tx.=
 The same goes for
bumping the update tx in Coinpool.
It could be worked around by having a different covenant per participant (p=
aying the fee from either
of the participants' output) behind a signature check. Of course it require=
s funds to already be in
the contract (HTLC, Coinpool leaf) to pay for your own unilateral close, bu=
t if you don't have any
fund in the contract it doesn't make sense to try to feebump it in the firs=
t place. The same goes
for small amounts: you'd only allocate up to the value of the contract (min=
us a dust preference) in
fees in order to enforce it.
This is less nice for external monitors as it requires a private key (or an=
other secret) to be
committed to in advance) to be able to bump [4] and does not get rid of the=
 "who's gonna pay for the
enforcement" issue in >2-parties contracts. Still, it's more optimal and us=
able than CPFP or adding
a pair of input/output for all the reasons mentioned above.


Thoughts?
Antoine


[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/0=
19614.html
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/0=
19615.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/0=
19627.html
[3] That's obviously close to the CTV construction. But using another more =
flexible (and therefore
    less optimized) construction would not be a big deal. It might in fact =
be necessary for more
    elaborated (realistic?) usecases than the simple one detailed here.
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/0=
19879.html