Re: [bitcoin-dev] Covenants and feebumping
Hi ZmnSCPxj, Thanks for the feedback. The DLC idea is interesting but you are centralizing the liveness requirements, effectively creating a SPOF: in order to bypass the revocation clause no need to make sure to down each and every watchtower anymore, just down the oracle and you are sure no revocation transaction can be pushed. > Okay, let me see if I understand your concern correctly. > When using a signature challenge, the concern is that you need to presign > multiple versions of a transaction with varying feerates. I was thinking of having a hot key (in this case probably shared amongst the monitors) where they would sign the right fee level at broadcast time. Pre-signing makes it quickly too many signatures (and kills the purpose of having covenants in the first place). > And you have a set of network monitors / watchtowers that are supposed to > watch the chain on your behalf in case your ISP suddenly hates you for no > reason. > The more monitors there are, the more likely that one of them will be > corrupted by a miner and jump to the highest-feerate version, overpaying fees > and making miners very happy. > Such is third-party trust. > Is my understanding correct? Your understanding of the tradeoff is correct. --- Original Message --- Le jeudi 17 mars 2022 à 12:29 AM, ZmnSCPxj a écrit : > Good morning Antoine, > > > For "hot contracts" a signature challenge is used to achieve the same. I > > know the latter is imperfect, since > > > > the lower the uptime risk (increase the number of network monitors) the > > higher the DOS risk (as you duplicate > > > > the key).. That's why i asked if anybody had some thoughts about this and > > if there was a cleverer way of doing > > > > it. > > Okay, let me see if I understand your concern correctly. > > When using a signature challenge, the concern is that you need to presign > multiple versions of a transaction with varying feerates. > > And you have a set of network monitors / watchtowers that are supposed to > watch the chain on your behalf in case your ISP suddenly hates you for no > reason. > > The more monitors there are, the more likely that one of them will be > corrupted by a miner and jump to the highest-feerate version, overpaying fees > and making miners very happy. > > Such is third-party trust. > > Is my understanding correct? > > A cleverer way, which requires consolidating (but is unable to eliminate) > third-party trust, would be to use a DLC oracle. > > The DLC oracle provides a set of points corresponding to a set of feerate > ranges, and commits to publishing the scalar of one of those points at some > particular future block height. > > Ostensibly, the scalar it publishes is the one of the point that corresponds > to the feerate range found at that future block height. > > You then create adaptor signatures for each feerate version, corresponding to > the feerate ranges the DLC oracle could eventually publish. > > The adaptor signatures can only be completed if the DLC oracle publishes the > corresponding scalar for that feerate range. > > You can then send the adaptor signatures to multiple watchtowers, who can > only publish one of the feerate versions, unless the DLC oracle is hacked and > publishes multiple scalars (at which point the DLC oracle protocol reveals a > privkey of the DLC oracle, which should be usable for slashing some bond of > the DLC oracle). > > This prevents any of them from publishing the highest-feerate version, as the > adaptor signature cannot be completed unless that is what the oracle > published. > > There are still drawbacks: > > * Third-party trust risk: the oracle can still lie. > > * DLC oracles are prevented from publishing multiple scalars; they cannot be > prevented from publishing a single wrong scalar. > > * DLCs must be time bound. > > * DLC oracles commit to publishing a particular point at a particular fixed > time. > > * For "hot" dynamic protocols, you need the ability to invoke the oracle at > any time, not a particular fixed time. > > The latter probably makes this unusable for hot protocols anyway, so maybe > not so clever. > > Regards, > > ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Covenants and feebumping
Good morning Antoine, > For "hot contracts" a signature challenge is used to achieve the same. I know > the latter is imperfect, since > the lower the uptime risk (increase the number of network monitors) the > higher the DOS risk (as you duplicate > the key).. That's why i asked if anybody had some thoughts about this and if > there was a cleverer way of doing > it. Okay, let me see if I understand your concern correctly. When using a signature challenge, the concern is that you need to presign multiple versions of a transaction with varying feerates. And you have a set of network monitors / watchtowers that are supposed to watch the chain on your behalf in case your ISP suddenly hates you for no reason. The more monitors there are, the more likely that one of them will be corrupted by a miner and jump to the highest-feerate version, overpaying fees and making miners very happy. Such is third-party trust. Is my understanding correct? A cleverer way, which requires consolidating (but is unable to eliminate) third-party trust, would be to use a DLC oracle. The DLC oracle provides a set of points corresponding to a set of feerate ranges, and commits to publishing the scalar of one of those points at some particular future block height. Ostensibly, the scalar it publishes is the one of the point that corresponds to the feerate range found at that future block height. You then create adaptor signatures for each feerate version, corresponding to the feerate ranges the DLC oracle could eventually publish. The adaptor signatures can only be completed if the DLC oracle publishes the corresponding scalar for that feerate range. You can then send the adaptor signatures to multiple watchtowers, who can only publish one of the feerate versions, unless the DLC oracle is hacked and publishes multiple scalars (at which point the DLC oracle protocol reveals a privkey of the DLC oracle, which should be usable for slashing some bond of the DLC oracle). This prevents any of them from publishing the highest-feerate version, as the adaptor signature cannot be completed unless that is what the oracle published. There are still drawbacks: * Third-party trust risk: the oracle can still lie. * DLC oracles are prevented from publishing multiple scalars; they cannot be prevented from publishing a single wrong scalar. * DLCs must be time bound. * DLC oracles commit to publishing a particular point at a particular fixed time. * For "hot" dynamic protocols, you need the ability to invoke the oracle at any time, not a particular fixed time. The latter probably makes this unusable for hot protocols anyway, so maybe not so clever. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Covenants and feebumping
Hi Jeremy,
Thanks for the feedback. I indeed only compared it to existing fee-bumping
methods. But sponsors are pretty
similar to CPFP in usage anyways, they 'just' get rid of the complexity of
managing transaction chains in the
mempool. That's great, don't get me wrong, just it's much less ideal than a
solution not requiring additional
UTxOs to be reserved, managed, and additional onchain transactions.
Regarding chain efficiency. First, you wrote:
> As you've noted, an approach like precomitted different fee levels might
> work, but has substantial costs.
Well, i noted that it *does* work (at least for vaults). And it does incur a
cost, but it's inferior to the
other solutions. Then, sure sponsors' -like CPFP's- cost can be amortized. The
chain usage would still likely
be superior (depends on a case by case basis i'd say), but even then the
"direct" chain usage cost isn't what
matters most. As mentioned, the cost of using funds not internal to the
contract really is.
Regarding capital efficiency, again as noted in the post, it's the entire point
to use funds internal to the
contract ("pre-committed"). Sure external funding (by the means of sponsors or
any other technique) allows you
to allocate funds later on, or never. But we want contracts that are actually
enforceable, i guess?
On the other hand, pre-committing to all the possible fee-bumped levels
prevents you to dynamically add more
fees eventually. That's why you need to pre-commit to levels up to your assumed
"max feerate before i close
the contract". For "cold contracts" (vaults), timelocks prevent the DOS of
immediately using a large feerate.
For "hot contracts" a signature challenge is used to achieve the same. I know
the latter is imperfect, since
the lower the uptime risk (increase the number of network monitors) the higher
the DOS risk (as you duplicate
the key).. That's why i asked if anybody had some thoughts about this and if
there was a cleverer way of doing
it.
> This is also true for vaults where you know you only want to open 1 per month
> let's say, and not
> your vaults> per month, which pre-committing requires.
Huh? Pre-committing here is to pre-commit to levels of the revocation
("Cancel") transaction. It has nothing
to do with "activating" (using Revault's terminology) a vault, done by sharing
a signature for the Unvault
transaction.
You might have another vault design in mind whereby any deposited fund is
unvault-able. In this case, and as
with any other active contract, i think you need to have funds ready to pay for
the fees for the contract to
be enforceable. Whether these funds come from the contract's funds or from
externally-reserved UTxOs.
> you don't need a salt, you just need a unique payout addr (e.g. hardened
> derivation) per revocation txn and
> you cannot guess the branch.
Yeah, i preferred to go with 8 more vbytes. First because relying on never
reusing a derivation index is
brittle and also because it would make rescan much harder. Imagine having 256
fee levels, making 5 payments a
day for 200 days in a year. You'd have 256000 derivation indexes per year to
scan for if restoring frombackup.
--- Original Message ---
Le dimanche 13 mars 2022 à 3:33 AM, Jeremy Rubin a
écrit :
> Hi Antoine,
>
> I have a few high level thoughts on your post comparing these types of
> primitive to an explicit soft fork approach:
>
> 1) Transaction sponsors *is* a type of covenant. Precisely, it is very
> similar to an "Impossible Input" covenant in conjunction with a "IUTXO" I
> defined in my 2017
> workshophttps://rubin.io/public/pdfs/multi-txn-contracts.pdf(I know, I
> know... self citation, not cool, but helps with context).
>
> However, for Sponsors itself we optimize the properties of how it works & is
> represented, as well as "tighten the hatches" on binding to specific TX vs
> merely spend of the outputs (which wouldn't work as well with APO).
>
> Perhaps thinking of something like sponsors as a form of covenant, rather
> than a special purpose thing, is helpful?
>
> There's a lot you could do with a general "observe other txns in {this block,
> the chain}" primitive. The catch is that for sponsors we don't *care* to
> enable people to use this as a "smart contracting primitive", we want to use
> it for fee bumping. So we don't care about programmability, we care about
> being able to use the covenant to bump fees.
>
> 2) On Chain Efficiency.
>
> A) Precommitted Levels
> As you've noted, an approach like precomitted different fee levels might
> work, but has substantial costs.
>
> However, with sponsors, the minimum viable version of this (not quite what is
> spec'd in my prior email, but it could be done this way if we care to
> optimize for bytes) would require 1 in and 1 out with only 32 bytes extra. So
> that's around 40 bytes outpoint + 64 bytes signature + 40 bytes output + 32
> bytes metadata = 174 bytes per bump. Bumps in this way can also amortize, so
>
Re: [bitcoin-dev] Covenants and feebumping
Hi Antoine,
I have a few high level thoughts on your post comparing these types of
primitive to an explicit soft fork approach:
1) Transaction sponsors *is* a type of covenant. Precisely, it is very
similar to an "Impossible Input" covenant in conjunction with a "IUTXO" I
defined in my 2017 workshop
https://rubin.io/public/pdfs/multi-txn-contracts.pdf (I know, I know...
self citation, not cool, but helps with context).
However, for Sponsors itself we optimize the properties of how it works &
is represented, as well as "tighten the hatches" on binding to specific TX
vs merely spend of the outputs (which wouldn't work as well with APO).
Perhaps thinking of something like sponsors as a form of covenant, rather
than a special purpose thing, is helpful?
There's a lot you could do with a general "observe other txns in {this
block, the chain}" primitive. The catch is that for sponsors we don't
*care* to enable people to use this as a "smart contracting primitive", we
want to use it for fee bumping. So we don't care about programmability, we
care about being able to use the covenant to bump fees.
2) On Chain Efficiency.
A) Precommitted Levels
As you've noted, an approach like precomitted different fee levels might
work, but has substantial costs.
However, with sponsors, the minimum viable version of this (not quite what
is spec'd in my prior email, but it could be done this way if we care to
optimize for bytes) would require 1 in and 1 out with only 32 bytes extra.
So that's around 40 bytes outpoint + 64 bytes signature + 40 bytes output +
32 bytes metadata = 174 bytes per bump. Bumps in this way can also
amortize, so bumping >1 txn at the same time would hit the limit of 32
bytes + 144/n bytes to bump more than one thing. You can imagine cases
where this might be popular, like "close >1 of my LN channels" or "start
withdrawals for 5 of my JamesOB vaulted coins"
B) Fancy(er) Covenants
We might also have something with OP_CAT and CSFS where bumps are done as
some sort of covenant-y thing that lets you arbitrarily rewrite
transactions.
Not too much to say other than that it is difficult to get these down in
size as the scripts become more complex, not to mention the (hotly
discussed of late) ramifications of those covenants more generally.
Absent a concrete fancy covenant with fee bumping, I can't comment.
3) On Capital Efficiency
Something like a precommitted or covenant fee bump requires the fee capital
to be pre-committed inside the UTXO, whereas for something like Sponsors
you can use capital you get sometime later. In certain models -- e.g.,
channels -- where you might expect only log(N) of your channels to fail in
a given epoch, you don't need to allocate as much capital as if you were to
have to do it in-band. This is also true for vaults where you know you only
want to open 1 per month let's say, and not per month,
which pre-committing requires.
4) On Protocol Design
It's nice that you can abstract away your protocol design concerns as a
"second tier composition check" v.s. having to modify your protocol to work
with a fee bumping thing.
There are a myriad of ways dynamic txns (e.g. for Eltoo) can lead to RBF
pinning and similar, Sponsor type things allow you to design such protocols
to not have any native way of paying for fees inside the actual
"Transaction Intents" and use an external system to create the intended
effect. It seems (to me) more robust that we can prove that a Sponsors
mechanism allows any transaction -- regardless of covenant stuff, bugs,
pinning, etc -- to move forward.
Still... careful protocol design may permit the use of optimized
constructions! For example, in a vault rather than assigning *no fee* maybe
you can have a single branch with a reasonable estimated fee. If you are
correct or overshot (let's say 50% chance?) then you don't need to add a
sponsor. If you undershot, not to worry, just add a sponsor. Adopted
broadly, this would cut the expected value of using sponsors by . This basically enables all
protocols to try to be more efficient, but backstop that with a guaranteed
to work safe mechanism.
There was something else I was going to say but I forgot about it... if it
comes to me I'll send a follow up email.
Cheers,
Jeremy
p.s.
>
> *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.*
you don't need a salt, you just need a unique payout addr (e.g. hardened
derivation) per revocation txn and you cannot guess the branch.
--
@JeremyRubin
On Sat, Mar 12, 2022 at 10:34 AM darosior via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The idea
[bitcoin-dev] Covenants and feebumping
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 frustration 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 (conceptually, not talking about any specific proposal) seem to open lots of new use cases and to be desired 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 not 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 Unvaulting transaction, whose output triggers a timelock before the expiration of which a revocation transaction may be confirmed. The revocation transaction being signed in advance (typically before sharing the signature for the Unvault transaction) you need fee bumping in order for the contract to actually be enforceable. Now, with a covenant you could commit to the revocation tx instead of presigning it. And using a Taproot tree you could commit to different versions of it with increasing feerate. Any network monitor (the brooadcaster, a watchtower, ..) would be able to RBF the revocation 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 contracts (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 each 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 wallet opened up the blackmail from the previous section, but the benefits of paying from internal funds shouldn't be understated. No need to decide on an amount to be refilled. No need to bother the user to refill the fee-bumping wallet (before they can participate in more contracts, or worse before a deadline at which all contracts are closed). No need for a potentially large amount of funds to just sit on a hot wallet "just in case". No need to duplicate this amount as you replicate the number of network monitors (which is critical to the security of such contracts). In addition, note how modifying the feerate of the revocation transaction in 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 rules (just use fee thresholds adapted to the current RBF thresholds, potentially with some leeway to account for policy changes). Paying from shared funds (in addition to paying from internal funds) also prevents pervert incentives for contracts with more than 2 parties. In case one of the parties 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 for 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 wallet software for a setup with 5 participants. The revocation delay is 144 blocks. You assume revocation to be infrequent (if one happens it's probably a misconfigured watchtower that needs be fixed before the next unvaulting), so you can afford infrequent overpayments and larger fee thresholds. 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 (open to whomever the vault pays after the 144 blocks). Then the leaf `i` for
