📅 Original date posted:2021-11-29
📝 Original message:Hi Darosior,
Nice work, few thoughts binding further your model for Lightning.
> For any delegated vault, ensure the confirmation of a Cancel transaction
in a configured number of
> blocks at any point. In so doing, minimize the overpayments and the UTxO
set footprint. Overpayments
> increase the burden on the watchtower operator by increasing the required
frequency of refills of the
> fee-bumping wallet, which is already the worst user experience. You are
likely to manage a number of
> UTxOs with your number of vaults, which comes at a cost for you as well
as everyone running a full
> node.
For any opened channel, ensure the confirmation of a Commitment transaction
and the children HTLC-Success/HTLC-Timeout transactions. Note, in the
Lightning security game you have to consider (at least) 4 types of players
moves and incentives : your node, your channel counterparties, the miners,
the crowd of bitcoin users. The number of the last type of players is
unknown from your node, however it should not be forgotten you're in
competition for block space, therefore their block demands bids should be
anticipated and reacted to in consequence. With that remark in mind,
implications for your LN fee-bumping strategy will be raised afterwards.
For a LN service provider, on-chain overpayments are bearing on your
operational costs, thus downgrading your economic competitiveness. For the
average LN user, overpayment might price out outside a LN non-custodial
deployment, as you don't have the minimal security budget to be on your own.
> This opens up a pinning vector, or at least a significant nuisance: any
other party can largely
> increase the absolute fee without increasing the feerate, leveraging the
RBF rules to prevent you
> from replacing it without paying an insane fee. And you might not see it
in your own mempool and
> could only suppose it's happening by receiving non-full blocks or with
transactions paying a lower
> feerate.
Same issue with Lightning, we can be pinned today on the basis of
replace-by-fee rule 3. We can be also blinded by network mempool
partitions, a pinning counterparty can segregate all the full-nodes in as
many subsets by broadcasting a revoked Commitment transaction different for
each. For Revault, I think you can also do unlimited partitions by mutating
the ANYONECANPAY-input of the Cancel.
That said, if you have a distributed towers deployment, spread across the
p2p network topology, and they can't be clustered together through
cross-layers or intra-layer heuristics, you should be able to reliably
observe such partitions. I think such distributed monitors are deployed by
few L1 merchants accepting 0-conf to detect naive double-spend.
> Unfortunately i know of no other primitive that can be used by
multi-party (i mean, >2) presigned
> transactions protocols for fee-bumping that aren't (more) vulnerable to
pinning.
Have we already discussed a fee-bumping "shared cache", a CPFP variation ?
Strawman idea: Alice and Bob commit collateral inputs to a separate UTXO
from the main "offchain contract" one. This UTXO is locked by a multi-sig.
For any Commitment transaction pre-signed, also counter-sign a CPFP with
top mempool feerate included, spending a Commitment anchor output and the
shared-cache UTXO. If the fees spike, you can re-sign a high-feerate CPFP,
assuming interactivity. As the CPFP is counter-signed by everyone, the
outputs can be CSV-1 encumbered to prevent pinnings. If the share-cache is
feeded at parity, there shouldn't be an incentive to waste or maliciously
inflate the feerate. I think this solution can be easily generalized to
more than 2 counterparties by using a multi-signature scheme. Big issue, if
the feerate is short due to fee spikes and you need to re-sign a
higher-feerate CPFP, you're trusting your counterparty to interact, though
arguably not worse than the current update fee mechanism.
> For Lightning, it'd mean keeping an equivalent amount of funds as the sum
of all your
channels balances sitting there unallocated "just in case". This is not
reasonable.
Agree, game-theory wise, you would like to keep a full fee-bumping reserve,
ready to burn as much in fees as the contested HTLC value, as it's the
maximum gain of your counterparty. Though perfect equilibrium is hard to
achieve because your malicious counterparty might have an edge pushing you
to broadcast your Commitment first by witholding HTLC resolution.
Fractional fee-bumping reserves are much more realistic to expect in the LN
network. Lower fee-bumping reserve, higher liquidity deployed, in theory
higher routing fees. By observing historical feerates, average offchain
balances at risk and routing fees expected gains, you should be able to
discover an equilibrium where higher levels of reserve aren't worth the
opportunity cost. I guess this equilibrium could be your LN fee-bumping
reserve max feerate.
Note, I think the LN approach is a bit different from what suits a custody
protocol like Revault, as you compute a direct return of the frozen
fee-bumping liquidity. With Revault, if you have numerous bitcoins
protected, it's might be more interesting to adopt a "buy the mempool,
stupid" strategy than risking fund safety for few percentages of interest
returns.
> This is easier to reason about with a per-contract reserve.
For Lightning, this per-channel approach is safer too, as one Commitment
transaction pinned or jammed could affect the confirmation odds of your
remaining LN Commitment transactions.
> For your Lightning channel you would probably take the maximum size of
your commitment transaction
> according to your HTLC exposure settings + the size of as many
`htlc_success` transactions?
Yes, I guess it's your holder's `max_accepted_htcls` * `HTLC-Success
weight` + counterparty's `max_accepted_htlcs` * `HTLC-Timeout weight`
Better to adopt this worst-case as the base transaction weight to fee-bump,
as currently we can't dynamically update channel policies.
> For some other applications with large transactions and lower-value UTxOs
on average it's
> likely that only part of the offchain contracts might be enforceable at a
reasonable feerate. Is it
> reasonable?
This is where the "anticipate the crowd of bitcoin users move" point can be
laid out. As the crowd of bitcoin users' fee-bumping reserves are
ultimately unknown from your node knowledge, you should be ready to be a
bit more conservative than the vanilla fee-bumping strategies shipped by
default. In case of massive mempool congestion, your additional
conservatism might get your time-sensitive transactions and game on the
crowd of bitcoin users. First Problem: if all offchain bitcoin software
adopt that strategy we might inflate the worst-case feerate rate at the
benefit of the miners, without holistically improving block throughput.
Second problem : your class of offchain bitcoin softwares might have
ridiculous fee-bumping reserve compared
to other classes of offchain bitcoin softwares (Revault > Lightning) and
just be priced out bydesign in case of mempool congestion. Third problem :
as the number of offchain bitcoin applications should go up with time, your
fee-bumping reserve levels based from historical data might be always late
by one "bank-run" scenario.
For Lightning, if you're short in fee-bumping reserves you might still do
preemptive channel closures, either cooperatively or unilaterally and get
back the off-chain liquidity to protect the more economically interesting
channels. Though again, that kind of automatic behavior might be compelling
at the individual node-level, but make the mempol congestion worse
holistically.
> First of all, when to fee-bump? At fixed time intervals? At each block
connection?
In case of massive mempool congestion, you might try to front-run the crowd
of bitcoin users relying on block connections for fee-bumping, and thus
start your fee-bumping as soon as you observe feerate groups fluctuations
in your local mempool(s).
Also you might proceed your fee-bumping ticks on a local clock instead of
block connections in case of time-dilation or deeper eclipse attacks of
your local node. Your view of the chain might be compromised but not your
ability to broadcast transactions thanks to emergency channels (in the
non-LN sense...though in fact quid of txn wrapped in onions ?) of
communication.
> You might skew miners incentives in doing
> so: if you increase the fees by a factor of N, any miner with a fraction
larger than 1/N of the
> network hashrate now has an incentive to censor your transaction at first
to get you to panic.
Yes I think miner-harvesting attacks should be weighed carefully in the
design of offchain contracts fee-bumping strategies, at least in the future
when the mining reward exhausts further. I wonder if a more refined formula
should encompass the miner loss for empty blocks and ensure this loss stays
more substantial than the fees increased. So something like computing "for
X censored blocks, the Y average loss should be superior to the Z
fee-bumping increase".
> Of course, given it's all hacks and workarounds and there is no good
answer to "what is a reasonable
> feerate up to which we need to make contracts enforceable onchain?",
there is definitely room for an
> insurance market.
Yes, stay open the question on how you enforce this block insurance market.
Reputation, which might be to avoid due to the latent centralization
effect, might be hard to stack and audit reliably for an emergency
mechanism running, hopefully, once in a halvening period. Maybe maybe some
cryptographic or economically based mechanism on slashing or swaps could be
found...
Antoine
Le lun. 29 nov. 2021 à 09:34, darosior via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> Hi everyone,
>
> Fee-bumping is paramount to the security of many protocols building on
> Bitcoin, as they require the
> confirmation of a transaction (which might be presigned) before the
> expiration of a timelock at any
> point after the establishment of the contract.
>
> The part of Revault using presigned transactions (the delegation from a
> large to a smaller multisig)
> is no exception. We have been working on how to approach this for a while
> now and i'd like to share
> what we have in order to open a discussion on this problem so central to
> what seem to be The Right
> Way [0] to build on Bitcoin but which has yet to be discussed in details
> (at least publicly).
>
> I'll discuss what we came up with for Revault (at least for what will be
> its first iteration) but my
> intent with posting to the mailing list is more to frame the questions to
> this problem we are all
> going to face rather than present the results of our study tailored to the
> Revault usecase.
> The discussion is still pretty Revault-centric (as it's the case study)
> but hopefully this can help
> future protocol designers and/or start a discussion around what everyone's
> doing for existing ones.
>
>
> ## 1. Reminder about Revault
>
> The part of Revault we are interested in for this study is the delegation
> process, and more
> specifically the application of spending policies by network monitors
> (watchtowers).
> Coins are received on a large multisig. Participants of this large
> multisig create 2 [1]
> transactions. The Unvault, spending a deposit UTxO, creates an output
> paying either to the small
> multisig after a timelock or to the large multisig immediately. The
> Cancel, spending the Unvault
> output through the non-timelocked path, creates a new deposit UTxO.
> Participants regularly exchange the Cancel transaction signatures for each
> deposit, sharing the
> signatures with the watchtowers they operate. They then optionally [2]
> sign the Unvault transaction
> and share the signatures with the small multisig participants who can in
> turn use them to proceed
> with a spending. Watchtowers can enforce spending policies (say, can't
> Unvault outside of business
> hours) by having the Cancel transaction be confirmed before the expiration
> of the timelock.
>
>
> ## 2. Problem statement
>
> For any delegated vault, ensure the confirmation of a Cancel transaction
> in a configured number of
> blocks at any point. In so doing, minimize the overpayments and the UTxO
> set footprint. Overpayments
> increase the burden on the watchtower operator by increasing the required
> frequency of refills of the
> fee-bumping wallet, which is already the worst user experience. You are
> likely to manage a number of
> UTxOs with your number of vaults, which comes at a cost for you as well as
> everyone running a full
> node.
>
> Note that this assumes miners are economically rationale, are incentivized
> by *public* fees and that
> you have a way to propagate your fee-bumped transaction to them. We also
> don't consider the block
> space bounds.
>
> In the previous paragraph and the following text, "vault" can generally be
> replaced with "offchain
> contract".
>
>
> ## 3. With presigned transactions
>
> As you all know, the first difficulty is to get to be able to unilaterally
> enforce your contract
> onchain. That is, any participant must be able to unilaterally bump the
> fees of a transaction even
> if it was co-signed by other participants.
>
> For Revault we can afford to introduce malleability in the Cancel
> transaction since there is no
> second-stage transaction depending on its txid. Therefore it is pre-signed
> with ANYONECANPAY. We
> can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3].
> Note how we can't leverage
> the carve out rule, and neither can any other more-than-two-parties
> contract.
> This has a significant implication for the rest, as we are entirely
> burning fee-bumping UTxOs.
>
> This opens up a pinning vector, or at least a significant nuisance: any
> other party can largely
> increase the absolute fee without increasing the feerate, leveraging the
> RBF rules to prevent you
> from replacing it without paying an insane fee. And you might not see it
> in your own mempool and
> could only suppose it's happening by receiving non-full blocks or with
> transactions paying a lower
> feerate.
> Unfortunately i know of no other primitive that can be used by multi-party
> (i mean, >2) presigned
> transactions protocols for fee-bumping that aren't (more) vulnerable to
> pinning.
>
>
> ## 4. We are still betting on future feerate
>
> The problem is still missing one more constraint. "Ensuring confirmation
> at any time" involves ensuring
> confirmation at *any* feerate, which you *cannot* do. So what's the limit?
> In theory you should be ready
> to burn as much in fees as the value of the funds you want to get out of
> the contract. So... For us
> it'd mean keeping for each vault an equivalent amount of funds sitting
> there on the watchtower's hot
> wallet. For Lightning, it'd mean keeping an equivalent amount of funds as
> the sum of all your
> channels balances sitting there unallocated "just in case". This is not
> reasonable.
>
> So you need to keep a maximum feerate, above which you won't be able to
> ensure the enforcement of
> all your contracts onchain at the same time. We call that the "reserve
> feerate" and you can have
> different strategies for choosing it, for instance:
> - The 85th percentile over the last year of transactions feerates
> - The maximum historical feerate
> - The maximum historical feerate adjusted in dollars (makes more sense but
> introduces a (set of?)
> trusted oracle(s) in a security-critical component)
> - Picking a random high feerate (why not? It's an arbitrary assumption
> anyways)
>
> Therefore, even if we don't have to bet on the broadcast-time feerate
> market at signing time anymore
> (since we can unilaterally bump), we still need some kind of prediction in
> preparation of making
> funds available to bump the fees at broadcast time.
> Apart from judging that 500sat/vb is probably more reasonable than
> 10sat/vbyte, this unfortunately
> sounds pretty much crystal-ball-driven.
>
> We currently use the maximum of the 95th percentiles over 90-days windows
> over historical block chain
> feerates. [4]
>
>
> ## 5. How much funds does my watchtower need?
>
> That's what we call the "reserve". Depending on your reserve feerate
> strategy it might vary over
> time. This is easier to reason about with a per-contract reserve. For
> Revault it's pretty
> straightforward since the Cancel transaction size is static:
> `reserve_feerate * cancel_size`. For
> other protocols with dynamic transaction sizes (or even packages of
> transactions) it's less so. For
> your Lightning channel you would probably take the maximum size of your
> commitment transaction
> according to your HTLC exposure settings + the size of as many
> `htlc_success` transaction?
>
> Then you either have your software or your user guesstimate how many
> offchain contracts the
> watchtower will have to watch, time that by the per-contract reserve and
> refill this amount (plus
> some slack in practice). Once again, a UX tradeoff (not even mentioning
> the guesstimation UX):
> overestimating leads to too many unallocated funds sitting on a hot
> wallet, underestimating means
> (at best) inability to participate in new contracts or being "at risk"
> (not being able to enforce
> all your contracts onchain at your reserve feerate) before a new refill.
>
> For vaults you likely have large-value UTxOs and small transactions (the
> Cancel is one-in one-out in
> Revault). For some other applications with large transactions and
> lower-value UTxOs on average it's
> likely that only part of the offchain contracts might be enforceable at a
> reasonable feerate. Is it
> reasonable?
>
>
> ## 6. UTxO pool layout
>
> Now that you somehow managed to settle on a refill amount, how are you
> going to use these funds?
> Also, you'll need to manage your pool across time (consolidating small
> coins, and probably fanning
> out large ones).
>
> You could keep a single large UTxO and peel it as you need to sponsor
> transactions. But this means
> that you need to create a coin of a specific value according to your need
> at the current feerate
> estimation, hope to have it confirmed in a few blocks (at least for now!
> [5]), and hope that the
> value won't be obsolete by the time it confirmed. Also, you'd have to do
> that for any number of
> Cancel, chaining feebump coin creation transactions off the change of the
> previous ones or replacing
> them with more outputs. Both seem to become really un-manageable (and
> expensive) in many edge-cases,
> shortening the time you have to confirm the actual Cancel transaction and
> creating uncertainty about
> the reserve (how much is my just-in-time fanout going to cost me in fees
> that i need to refill in
> advance on my watchtower wallet?).
> This is less of a concern for protocols using CPFP to sponsor
> transactions, but they rely on a
> policy rule specific to 2-parties contracts.
>
> Therefore for Revault we fan-out the coins per-vault in advance. We do so
> at refill time so the
> refiller can give an excess to pay for the fees of the fanout transaction
> (which is reasonable since
> it will occur just after the refilling transaction confirms). When the
> watchtower is asked to watch
> for a new delegated vault it will allocate coins from the pool of
> fanned-out UTxOs to it (failing
> that, it would refuse the delegation).
> What is a good distribution of UTxOs amounts per vault? We want to
> minimize the number of coins,
> still have coins small enough to not overpay (remember, we can't have
> change) and be able to bump a
> Cancel up to the reserve feerate using these coins. The two latter
> constraints are directly in
> contradiction as the minimal value of a coin usable at the reserve feerate
> (paying for its own input
> fee + bumping the feerate by, say, 5sat/vb) is already pretty high.
> Therefore we decided to go with
> two distributions per vault. The "reserve distribution" alone ensures that
> we can bump up to the
> reserve feerate and is usable for high feerates. The "bonus distribution"
> is not, but contains
> smaller coins useful to prevent overpayments during low and medium fee
> periods (which is most of the
> time).
> Both distributions are based on a basic geometric suite [6]. Each value is
> half the previous one.
> This exponentially decreases the value, limiting the number of coins. But
> this also allows for
> pretty small coins to exist and each coin's value is equal to the sum of
> the smaller coins,
> or smaller by at most the value of the smallest coin. Therefore bounding
> the maximum overpayment to
> the smallest coin's value [7].
>
> For the management of the UTxO pool across time we merged the
> consolidation with the fanout. When
> fanning out a refilled UTxO, we scan the pool for coins that need to be
> consolidated according to a
> heuristic. An instance of a heuristic is "the coin isn't allocated and
> would not have been able to
> increase the fee at the median feerate over the past 90 days of blocks".
> We had this assumption that feerate would tend to go up with time and
> therefore discarded having to
> split some UTxOs from the pool. We however overlooked that a large
> increase in the exchange price of
> BTC as we've seen during the past year could invalidate this assumption
> and that should arguably be
> reconsidered.
>
>
> ## 7. Bumping and re-bumping
>
> First of all, when to fee-bump? At fixed time intervals? At each block
> connection? It sounds like,
> given a large enough timelock, you could try to greed by "trying your
> luck" at a lower feerate and
> only re-bumping every N blocks. You would then start aggressively bumping
> at every block after M
> blocks have passed. But that's actually a bet (in disguised?) that the
> next block feerate in M blocks
> will be lower than the current one. In the absence of any predictive model
> it is more reasonable to
> just start being aggressive immediately.
> You probably want to base your estimates on `estimatesmartfee` and as a
> consequence you would re-bump
> (if needed )after each block connection, when your estimates get updated
> and you notice your
> transaction was not included in the block.
>
> In the event that you notice a consequent portion of the block is filled
> with transactions paying
> less than your own, you might want to start panicking and bump your
> transaction fees by a certain
> percentage with no consideration for your fee estimator. You might skew
> miners incentives in doing
> so: if you increase the fees by a factor of N, any miner with a fraction
> larger than 1/N of the
> network hashrate now has an incentive to censor your transaction at first
> to get you to panic. Also
> note this can happen if you want to pay the absolute fees for the
> 'pinning' attack mentioned in
> section #2, and that might actually incentivize miners to perform it
> themselves..
>
> The gist is that the most effective way to bump and rebump (RBF the Cancel
> tx) seems to just be to
> consider the `estimatesmartfee 2 CONSERVATIVE` feerate at every block your
> tx isn't included in, and
> to RBF it if the feerate is higher.
> In addition, we fallback to a block chain based estimation when estimates
> aren't available (eg if
> the user stopped their WT for say a hour and we come back up): we use the
> 85th percentile over the
> feerates in the last 6 blocks. Sure, miners can try to have an influence
> on that by stuffing their
> blocks with large fee self-paying transactions, but they would need to:
> 1. Be sure to catch a significant portion of the 6 blocks (at least 2,
> actually)
> 2. Give up on 25% of the highest fee-paying transactions (assuming they
> got the 6 blocks, it's
> proportionally larger and incertain as they get less of them)
> 3. Hope that our estimator will fail and we need to fall back to the
> chain-based estimation
>
>
> ## 8. Our study
>
> We essentially replayed the historical data with different deployment
> configurations (number of
> participants and timelock) and probability of an event occurring (event
> being say an Unvault, an
> invalid Unvault, a new delegation, ..). We then observed different metrics
> such as the time at risk
> (when we can't enforce all our contracts at the reserve feerate at the
> same time), or the
> operational cost.
> We got the historical fee estimates data from Statoshi [9], Txstats [10]
> and the historical chain
> data from Riccardo Casatta's `blocks_iterator` [11]. Thanks!
>
> The (research-quality..) code can be found at
> https://github.com/revault/research under the section
> "Fee bumping". Again it's very Revault specific, but at least the data can
> probably be reused for
> studying other protocols.
>
>
> ## 9. Insurances
>
> Of course, given it's all hacks and workarounds and there is no good
> answer to "what is a reasonable
> feerate up to which we need to make contracts enforceable onchain?", there
> is definitely room for an
> insurance market. But this enters the realm of opinions. Although i do
> have some (having discussed
> this topic for the past years with different people), i would like to keep
> this post focused on the
> technical aspects of this problem.
>
>
>
> [0] As far as i can tell, having offchain contracts be enforceable onchain
> by confirming a
> transaction before the expiration of a timelock is a widely agreed-upon
> approach. And i don't think
> we can opt for any other fundamentally different one, as you want to know
> you can claim back your
> coins from a contract after a deadline before taking part in it.
>
> [1] The Real Revault (tm) involves more transactions, but for the sake of
> conciseness i only
> detailed a minimum instance of the problem.
>
> [2] Only presigning part of the Unvault transactions allows to only
> delegate part of the coins,
> which can be abstracted as "delegate x% of your stash" in the user
> interface.
>
> [3]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html
>
> [4]
> https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L323-L329
>
> [5] https://github.com/bitcoin/bitcoin/pull/23121
>
> [6]
> https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L494-L507
>
> [7] Of course this assumes a combinatorial coin selection, but i believe
> it's ok given we limit the
> number of coins beforehand.
>
> [8] Although there is the argument to outbid a censorship, anyone
> censoring you isn't necessarily a
> miner.
>
> [9] https://www.statoshi.info/
>
> [10] https://www.statoshi.info/
>
> [11] https://github.com/RCasatta/blocks_iterator
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211129/883846a6/attachment-0001.html>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-06-07 23:00:45
in reply to nevent1q…nmfg
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-06-07 23:00:45Event JSON
{
"id": "637f2cd18818ebad8ef78863341e34497be7b6e44346879cba9e34f724a37583",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1686178845,
"kind": 1,
"tags": [
[
"e",
"5b559297a09db8e6812284374563396d212bcaca04454c3e7f19eea0babba7f5",
"",
"root"
],
[
"e",
"ac4543c9f09fa94be51885a4660e2c2740af2362684ac538c40a1e448b32d1dc",
"",
"reply"
],
[
"p",
"0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2"
]
],
"content": "📅 Original date posted:2021-11-29\n📝 Original message:Hi Darosior,\n\nNice work, few thoughts binding further your model for Lightning.\n\n\u003e For any delegated vault, ensure the confirmation of a Cancel transaction\nin a configured number of\n\u003e blocks at any point. In so doing, minimize the overpayments and the UTxO\nset footprint. Overpayments\n\u003e increase the burden on the watchtower operator by increasing the required\nfrequency of refills of the\n\u003e fee-bumping wallet, which is already the worst user experience. You are\nlikely to manage a number of\n\u003e UTxOs with your number of vaults, which comes at a cost for you as well\nas everyone running a full\n\u003e node.\n\nFor any opened channel, ensure the confirmation of a Commitment transaction\nand the children HTLC-Success/HTLC-Timeout transactions. Note, in the\nLightning security game you have to consider (at least) 4 types of players\nmoves and incentives : your node, your channel counterparties, the miners,\nthe crowd of bitcoin users. The number of the last type of players is\nunknown from your node, however it should not be forgotten you're in\ncompetition for block space, therefore their block demands bids should be\nanticipated and reacted to in consequence. With that remark in mind,\nimplications for your LN fee-bumping strategy will be raised afterwards.\n\nFor a LN service provider, on-chain overpayments are bearing on your\noperational costs, thus downgrading your economic competitiveness. For the\naverage LN user, overpayment might price out outside a LN non-custodial\ndeployment, as you don't have the minimal security budget to be on your own.\n\n\u003e This opens up a pinning vector, or at least a significant nuisance: any\nother party can largely\n\u003e increase the absolute fee without increasing the feerate, leveraging the\nRBF rules to prevent you\n\u003e from replacing it without paying an insane fee. And you might not see it\nin your own mempool and\n\u003e could only suppose it's happening by receiving non-full blocks or with\ntransactions paying a lower\n\u003e feerate.\n\nSame issue with Lightning, we can be pinned today on the basis of\nreplace-by-fee rule 3. We can be also blinded by network mempool\npartitions, a pinning counterparty can segregate all the full-nodes in as\nmany subsets by broadcasting a revoked Commitment transaction different for\neach. For Revault, I think you can also do unlimited partitions by mutating\nthe ANYONECANPAY-input of the Cancel.\n\nThat said, if you have a distributed towers deployment, spread across the\np2p network topology, and they can't be clustered together through\ncross-layers or intra-layer heuristics, you should be able to reliably\nobserve such partitions. I think such distributed monitors are deployed by\nfew L1 merchants accepting 0-conf to detect naive double-spend.\n\n\u003e Unfortunately i know of no other primitive that can be used by\nmulti-party (i mean, \u003e2) presigned\n\u003e transactions protocols for fee-bumping that aren't (more) vulnerable to\npinning.\n\nHave we already discussed a fee-bumping \"shared cache\", a CPFP variation ?\nStrawman idea: Alice and Bob commit collateral inputs to a separate UTXO\nfrom the main \"offchain contract\" one. This UTXO is locked by a multi-sig.\nFor any Commitment transaction pre-signed, also counter-sign a CPFP with\ntop mempool feerate included, spending a Commitment anchor output and the\nshared-cache UTXO. If the fees spike, you can re-sign a high-feerate CPFP,\nassuming interactivity. As the CPFP is counter-signed by everyone, the\noutputs can be CSV-1 encumbered to prevent pinnings. If the share-cache is\nfeeded at parity, there shouldn't be an incentive to waste or maliciously\ninflate the feerate. I think this solution can be easily generalized to\nmore than 2 counterparties by using a multi-signature scheme. Big issue, if\nthe feerate is short due to fee spikes and you need to re-sign a\nhigher-feerate CPFP, you're trusting your counterparty to interact, though\narguably not worse than the current update fee mechanism.\n\n\u003e For Lightning, it'd mean keeping an equivalent amount of funds as the sum\nof all your\nchannels balances sitting there unallocated \"just in case\". This is not\nreasonable.\n\nAgree, game-theory wise, you would like to keep a full fee-bumping reserve,\nready to burn as much in fees as the contested HTLC value, as it's the\nmaximum gain of your counterparty. Though perfect equilibrium is hard to\nachieve because your malicious counterparty might have an edge pushing you\nto broadcast your Commitment first by witholding HTLC resolution.\n\nFractional fee-bumping reserves are much more realistic to expect in the LN\nnetwork. Lower fee-bumping reserve, higher liquidity deployed, in theory\nhigher routing fees. By observing historical feerates, average offchain\nbalances at risk and routing fees expected gains, you should be able to\ndiscover an equilibrium where higher levels of reserve aren't worth the\nopportunity cost. I guess this equilibrium could be your LN fee-bumping\nreserve max feerate.\n\nNote, I think the LN approach is a bit different from what suits a custody\nprotocol like Revault, as you compute a direct return of the frozen\nfee-bumping liquidity. With Revault, if you have numerous bitcoins\nprotected, it's might be more interesting to adopt a \"buy the mempool,\nstupid\" strategy than risking fund safety for few percentages of interest\nreturns.\n\n\u003e This is easier to reason about with a per-contract reserve.\n\nFor Lightning, this per-channel approach is safer too, as one Commitment\ntransaction pinned or jammed could affect the confirmation odds of your\nremaining LN Commitment transactions.\n\n\u003e For your Lightning channel you would probably take the maximum size of\nyour commitment transaction\n\u003e according to your HTLC exposure settings + the size of as many\n`htlc_success` transactions?\n\nYes, I guess it's your holder's `max_accepted_htcls` * `HTLC-Success\nweight` + counterparty's `max_accepted_htlcs` * `HTLC-Timeout weight`\nBetter to adopt this worst-case as the base transaction weight to fee-bump,\nas currently we can't dynamically update channel policies.\n\n\u003e For some other applications with large transactions and lower-value UTxOs\non average it's\n\u003e likely that only part of the offchain contracts might be enforceable at a\nreasonable feerate. Is it\n\u003e reasonable?\n\nThis is where the \"anticipate the crowd of bitcoin users move\" point can be\nlaid out. As the crowd of bitcoin users' fee-bumping reserves are\nultimately unknown from your node knowledge, you should be ready to be a\nbit more conservative than the vanilla fee-bumping strategies shipped by\ndefault. In case of massive mempool congestion, your additional\nconservatism might get your time-sensitive transactions and game on the\ncrowd of bitcoin users. First Problem: if all offchain bitcoin software\nadopt that strategy we might inflate the worst-case feerate rate at the\nbenefit of the miners, without holistically improving block throughput.\nSecond problem : your class of offchain bitcoin softwares might have\nridiculous fee-bumping reserve compared\nto other classes of offchain bitcoin softwares (Revault \u003e Lightning) and\njust be priced out bydesign in case of mempool congestion. Third problem :\nas the number of offchain bitcoin applications should go up with time, your\nfee-bumping reserve levels based from historical data might be always late\nby one \"bank-run\" scenario.\n\nFor Lightning, if you're short in fee-bumping reserves you might still do\npreemptive channel closures, either cooperatively or unilaterally and get\nback the off-chain liquidity to protect the more economically interesting\nchannels. Though again, that kind of automatic behavior might be compelling\nat the individual node-level, but make the mempol congestion worse\nholistically.\n\n\u003e First of all, when to fee-bump? At fixed time intervals? At each block\nconnection?\n\nIn case of massive mempool congestion, you might try to front-run the crowd\nof bitcoin users relying on block connections for fee-bumping, and thus\nstart your fee-bumping as soon as you observe feerate groups fluctuations\nin your local mempool(s).\n\nAlso you might proceed your fee-bumping ticks on a local clock instead of\nblock connections in case of time-dilation or deeper eclipse attacks of\nyour local node. Your view of the chain might be compromised but not your\nability to broadcast transactions thanks to emergency channels (in the\nnon-LN sense...though in fact quid of txn wrapped in onions ?) of\ncommunication.\n\n\u003e You might skew miners incentives in doing\n\u003e so: if you increase the fees by a factor of N, any miner with a fraction\nlarger than 1/N of the\n\u003e network hashrate now has an incentive to censor your transaction at first\nto get you to panic.\n\nYes I think miner-harvesting attacks should be weighed carefully in the\ndesign of offchain contracts fee-bumping strategies, at least in the future\nwhen the mining reward exhausts further. I wonder if a more refined formula\nshould encompass the miner loss for empty blocks and ensure this loss stays\nmore substantial than the fees increased. So something like computing \"for\nX censored blocks, the Y average loss should be superior to the Z\nfee-bumping increase\".\n\n\u003e Of course, given it's all hacks and workarounds and there is no good\nanswer to \"what is a reasonable\n\u003e feerate up to which we need to make contracts enforceable onchain?\",\nthere is definitely room for an\n\u003e insurance market.\n\nYes, stay open the question on how you enforce this block insurance market.\nReputation, which might be to avoid due to the latent centralization\neffect, might be hard to stack and audit reliably for an emergency\nmechanism running, hopefully, once in a halvening period. Maybe maybe some\ncryptographic or economically based mechanism on slashing or swaps could be\nfound...\n\nAntoine\n\nLe lun. 29 nov. 2021 à 09:34, darosior via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e Hi everyone,\n\u003e\n\u003e Fee-bumping is paramount to the security of many protocols building on\n\u003e Bitcoin, as they require the\n\u003e confirmation of a transaction (which might be presigned) before the\n\u003e expiration of a timelock at any\n\u003e point after the establishment of the contract.\n\u003e\n\u003e The part of Revault using presigned transactions (the delegation from a\n\u003e large to a smaller multisig)\n\u003e is no exception. We have been working on how to approach this for a while\n\u003e now and i'd like to share\n\u003e what we have in order to open a discussion on this problem so central to\n\u003e what seem to be The Right\n\u003e Way [0] to build on Bitcoin but which has yet to be discussed in details\n\u003e (at least publicly).\n\u003e\n\u003e I'll discuss what we came up with for Revault (at least for what will be\n\u003e its first iteration) but my\n\u003e intent with posting to the mailing list is more to frame the questions to\n\u003e this problem we are all\n\u003e going to face rather than present the results of our study tailored to the\n\u003e Revault usecase.\n\u003e The discussion is still pretty Revault-centric (as it's the case study)\n\u003e but hopefully this can help\n\u003e future protocol designers and/or start a discussion around what everyone's\n\u003e doing for existing ones.\n\u003e\n\u003e\n\u003e ## 1. Reminder about Revault\n\u003e\n\u003e The part of Revault we are interested in for this study is the delegation\n\u003e process, and more\n\u003e specifically the application of spending policies by network monitors\n\u003e (watchtowers).\n\u003e Coins are received on a large multisig. Participants of this large\n\u003e multisig create 2 [1]\n\u003e transactions. The Unvault, spending a deposit UTxO, creates an output\n\u003e paying either to the small\n\u003e multisig after a timelock or to the large multisig immediately. The\n\u003e Cancel, spending the Unvault\n\u003e output through the non-timelocked path, creates a new deposit UTxO.\n\u003e Participants regularly exchange the Cancel transaction signatures for each\n\u003e deposit, sharing the\n\u003e signatures with the watchtowers they operate. They then optionally [2]\n\u003e sign the Unvault transaction\n\u003e and share the signatures with the small multisig participants who can in\n\u003e turn use them to proceed\n\u003e with a spending. Watchtowers can enforce spending policies (say, can't\n\u003e Unvault outside of business\n\u003e hours) by having the Cancel transaction be confirmed before the expiration\n\u003e of the timelock.\n\u003e\n\u003e\n\u003e ## 2. Problem statement\n\u003e\n\u003e For any delegated vault, ensure the confirmation of a Cancel transaction\n\u003e in a configured number of\n\u003e blocks at any point. In so doing, minimize the overpayments and the UTxO\n\u003e set footprint. Overpayments\n\u003e increase the burden on the watchtower operator by increasing the required\n\u003e frequency of refills of the\n\u003e fee-bumping wallet, which is already the worst user experience. You are\n\u003e likely to manage a number of\n\u003e UTxOs with your number of vaults, which comes at a cost for you as well as\n\u003e everyone running a full\n\u003e node.\n\u003e\n\u003e Note that this assumes miners are economically rationale, are incentivized\n\u003e by *public* fees and that\n\u003e you have a way to propagate your fee-bumped transaction to them. We also\n\u003e don't consider the block\n\u003e space bounds.\n\u003e\n\u003e In the previous paragraph and the following text, \"vault\" can generally be\n\u003e replaced with \"offchain\n\u003e contract\".\n\u003e\n\u003e\n\u003e ## 3. With presigned transactions\n\u003e\n\u003e As you all know, the first difficulty is to get to be able to unilaterally\n\u003e enforce your contract\n\u003e onchain. That is, any participant must be able to unilaterally bump the\n\u003e fees of a transaction even\n\u003e if it was co-signed by other participants.\n\u003e\n\u003e For Revault we can afford to introduce malleability in the Cancel\n\u003e transaction since there is no\n\u003e second-stage transaction depending on its txid. Therefore it is pre-signed\n\u003e with ANYONECANPAY. We\n\u003e can't use ANYONECANPAY|SINGLE since it would open a pinning vector [3].\n\u003e Note how we can't leverage\n\u003e the carve out rule, and neither can any other more-than-two-parties\n\u003e contract.\n\u003e This has a significant implication for the rest, as we are entirely\n\u003e burning fee-bumping UTxOs.\n\u003e\n\u003e This opens up a pinning vector, or at least a significant nuisance: any\n\u003e other party can largely\n\u003e increase the absolute fee without increasing the feerate, leveraging the\n\u003e RBF rules to prevent you\n\u003e from replacing it without paying an insane fee. And you might not see it\n\u003e in your own mempool and\n\u003e could only suppose it's happening by receiving non-full blocks or with\n\u003e transactions paying a lower\n\u003e feerate.\n\u003e Unfortunately i know of no other primitive that can be used by multi-party\n\u003e (i mean, \u003e2) presigned\n\u003e transactions protocols for fee-bumping that aren't (more) vulnerable to\n\u003e pinning.\n\u003e\n\u003e\n\u003e ## 4. We are still betting on future feerate\n\u003e\n\u003e The problem is still missing one more constraint. \"Ensuring confirmation\n\u003e at any time\" involves ensuring\n\u003e confirmation at *any* feerate, which you *cannot* do. So what's the limit?\n\u003e In theory you should be ready\n\u003e to burn as much in fees as the value of the funds you want to get out of\n\u003e the contract. So... For us\n\u003e it'd mean keeping for each vault an equivalent amount of funds sitting\n\u003e there on the watchtower's hot\n\u003e wallet. For Lightning, it'd mean keeping an equivalent amount of funds as\n\u003e the sum of all your\n\u003e channels balances sitting there unallocated \"just in case\". This is not\n\u003e reasonable.\n\u003e\n\u003e So you need to keep a maximum feerate, above which you won't be able to\n\u003e ensure the enforcement of\n\u003e all your contracts onchain at the same time. We call that the \"reserve\n\u003e feerate\" and you can have\n\u003e different strategies for choosing it, for instance:\n\u003e - The 85th percentile over the last year of transactions feerates\n\u003e - The maximum historical feerate\n\u003e - The maximum historical feerate adjusted in dollars (makes more sense but\n\u003e introduces a (set of?)\n\u003e trusted oracle(s) in a security-critical component)\n\u003e - Picking a random high feerate (why not? It's an arbitrary assumption\n\u003e anyways)\n\u003e\n\u003e Therefore, even if we don't have to bet on the broadcast-time feerate\n\u003e market at signing time anymore\n\u003e (since we can unilaterally bump), we still need some kind of prediction in\n\u003e preparation of making\n\u003e funds available to bump the fees at broadcast time.\n\u003e Apart from judging that 500sat/vb is probably more reasonable than\n\u003e 10sat/vbyte, this unfortunately\n\u003e sounds pretty much crystal-ball-driven.\n\u003e\n\u003e We currently use the maximum of the 95th percentiles over 90-days windows\n\u003e over historical block chain\n\u003e feerates. [4]\n\u003e\n\u003e\n\u003e ## 5. How much funds does my watchtower need?\n\u003e\n\u003e That's what we call the \"reserve\". Depending on your reserve feerate\n\u003e strategy it might vary over\n\u003e time. This is easier to reason about with a per-contract reserve. For\n\u003e Revault it's pretty\n\u003e straightforward since the Cancel transaction size is static:\n\u003e `reserve_feerate * cancel_size`. For\n\u003e other protocols with dynamic transaction sizes (or even packages of\n\u003e transactions) it's less so. For\n\u003e your Lightning channel you would probably take the maximum size of your\n\u003e commitment transaction\n\u003e according to your HTLC exposure settings + the size of as many\n\u003e `htlc_success` transaction?\n\u003e\n\u003e Then you either have your software or your user guesstimate how many\n\u003e offchain contracts the\n\u003e watchtower will have to watch, time that by the per-contract reserve and\n\u003e refill this amount (plus\n\u003e some slack in practice). Once again, a UX tradeoff (not even mentioning\n\u003e the guesstimation UX):\n\u003e overestimating leads to too many unallocated funds sitting on a hot\n\u003e wallet, underestimating means\n\u003e (at best) inability to participate in new contracts or being \"at risk\"\n\u003e (not being able to enforce\n\u003e all your contracts onchain at your reserve feerate) before a new refill.\n\u003e\n\u003e For vaults you likely have large-value UTxOs and small transactions (the\n\u003e Cancel is one-in one-out in\n\u003e Revault). For some other applications with large transactions and\n\u003e lower-value UTxOs on average it's\n\u003e likely that only part of the offchain contracts might be enforceable at a\n\u003e reasonable feerate. Is it\n\u003e reasonable?\n\u003e\n\u003e\n\u003e ## 6. UTxO pool layout\n\u003e\n\u003e Now that you somehow managed to settle on a refill amount, how are you\n\u003e going to use these funds?\n\u003e Also, you'll need to manage your pool across time (consolidating small\n\u003e coins, and probably fanning\n\u003e out large ones).\n\u003e\n\u003e You could keep a single large UTxO and peel it as you need to sponsor\n\u003e transactions. But this means\n\u003e that you need to create a coin of a specific value according to your need\n\u003e at the current feerate\n\u003e estimation, hope to have it confirmed in a few blocks (at least for now!\n\u003e [5]), and hope that the\n\u003e value won't be obsolete by the time it confirmed. Also, you'd have to do\n\u003e that for any number of\n\u003e Cancel, chaining feebump coin creation transactions off the change of the\n\u003e previous ones or replacing\n\u003e them with more outputs. Both seem to become really un-manageable (and\n\u003e expensive) in many edge-cases,\n\u003e shortening the time you have to confirm the actual Cancel transaction and\n\u003e creating uncertainty about\n\u003e the reserve (how much is my just-in-time fanout going to cost me in fees\n\u003e that i need to refill in\n\u003e advance on my watchtower wallet?).\n\u003e This is less of a concern for protocols using CPFP to sponsor\n\u003e transactions, but they rely on a\n\u003e policy rule specific to 2-parties contracts.\n\u003e\n\u003e Therefore for Revault we fan-out the coins per-vault in advance. We do so\n\u003e at refill time so the\n\u003e refiller can give an excess to pay for the fees of the fanout transaction\n\u003e (which is reasonable since\n\u003e it will occur just after the refilling transaction confirms). When the\n\u003e watchtower is asked to watch\n\u003e for a new delegated vault it will allocate coins from the pool of\n\u003e fanned-out UTxOs to it (failing\n\u003e that, it would refuse the delegation).\n\u003e What is a good distribution of UTxOs amounts per vault? We want to\n\u003e minimize the number of coins,\n\u003e still have coins small enough to not overpay (remember, we can't have\n\u003e change) and be able to bump a\n\u003e Cancel up to the reserve feerate using these coins. The two latter\n\u003e constraints are directly in\n\u003e contradiction as the minimal value of a coin usable at the reserve feerate\n\u003e (paying for its own input\n\u003e fee + bumping the feerate by, say, 5sat/vb) is already pretty high.\n\u003e Therefore we decided to go with\n\u003e two distributions per vault. The \"reserve distribution\" alone ensures that\n\u003e we can bump up to the\n\u003e reserve feerate and is usable for high feerates. The \"bonus distribution\"\n\u003e is not, but contains\n\u003e smaller coins useful to prevent overpayments during low and medium fee\n\u003e periods (which is most of the\n\u003e time).\n\u003e Both distributions are based on a basic geometric suite [6]. Each value is\n\u003e half the previous one.\n\u003e This exponentially decreases the value, limiting the number of coins. But\n\u003e this also allows for\n\u003e pretty small coins to exist and each coin's value is equal to the sum of\n\u003e the smaller coins,\n\u003e or smaller by at most the value of the smallest coin. Therefore bounding\n\u003e the maximum overpayment to\n\u003e the smallest coin's value [7].\n\u003e\n\u003e For the management of the UTxO pool across time we merged the\n\u003e consolidation with the fanout. When\n\u003e fanning out a refilled UTxO, we scan the pool for coins that need to be\n\u003e consolidated according to a\n\u003e heuristic. An instance of a heuristic is \"the coin isn't allocated and\n\u003e would not have been able to\n\u003e increase the fee at the median feerate over the past 90 days of blocks\".\n\u003e We had this assumption that feerate would tend to go up with time and\n\u003e therefore discarded having to\n\u003e split some UTxOs from the pool. We however overlooked that a large\n\u003e increase in the exchange price of\n\u003e BTC as we've seen during the past year could invalidate this assumption\n\u003e and that should arguably be\n\u003e reconsidered.\n\u003e\n\u003e\n\u003e ## 7. Bumping and re-bumping\n\u003e\n\u003e First of all, when to fee-bump? At fixed time intervals? At each block\n\u003e connection? It sounds like,\n\u003e given a large enough timelock, you could try to greed by \"trying your\n\u003e luck\" at a lower feerate and\n\u003e only re-bumping every N blocks. You would then start aggressively bumping\n\u003e at every block after M\n\u003e blocks have passed. But that's actually a bet (in disguised?) that the\n\u003e next block feerate in M blocks\n\u003e will be lower than the current one. In the absence of any predictive model\n\u003e it is more reasonable to\n\u003e just start being aggressive immediately.\n\u003e You probably want to base your estimates on `estimatesmartfee` and as a\n\u003e consequence you would re-bump\n\u003e (if needed )after each block connection, when your estimates get updated\n\u003e and you notice your\n\u003e transaction was not included in the block.\n\u003e\n\u003e In the event that you notice a consequent portion of the block is filled\n\u003e with transactions paying\n\u003e less than your own, you might want to start panicking and bump your\n\u003e transaction fees by a certain\n\u003e percentage with no consideration for your fee estimator. You might skew\n\u003e miners incentives in doing\n\u003e so: if you increase the fees by a factor of N, any miner with a fraction\n\u003e larger than 1/N of the\n\u003e network hashrate now has an incentive to censor your transaction at first\n\u003e to get you to panic. Also\n\u003e note this can happen if you want to pay the absolute fees for the\n\u003e 'pinning' attack mentioned in\n\u003e section #2, and that might actually incentivize miners to perform it\n\u003e themselves..\n\u003e\n\u003e The gist is that the most effective way to bump and rebump (RBF the Cancel\n\u003e tx) seems to just be to\n\u003e consider the `estimatesmartfee 2 CONSERVATIVE` feerate at every block your\n\u003e tx isn't included in, and\n\u003e to RBF it if the feerate is higher.\n\u003e In addition, we fallback to a block chain based estimation when estimates\n\u003e aren't available (eg if\n\u003e the user stopped their WT for say a hour and we come back up): we use the\n\u003e 85th percentile over the\n\u003e feerates in the last 6 blocks. Sure, miners can try to have an influence\n\u003e on that by stuffing their\n\u003e blocks with large fee self-paying transactions, but they would need to:\n\u003e 1. Be sure to catch a significant portion of the 6 blocks (at least 2,\n\u003e actually)\n\u003e 2. Give up on 25% of the highest fee-paying transactions (assuming they\n\u003e got the 6 blocks, it's\n\u003e proportionally larger and incertain as they get less of them)\n\u003e 3. Hope that our estimator will fail and we need to fall back to the\n\u003e chain-based estimation\n\u003e\n\u003e\n\u003e ## 8. Our study\n\u003e\n\u003e We essentially replayed the historical data with different deployment\n\u003e configurations (number of\n\u003e participants and timelock) and probability of an event occurring (event\n\u003e being say an Unvault, an\n\u003e invalid Unvault, a new delegation, ..). We then observed different metrics\n\u003e such as the time at risk\n\u003e (when we can't enforce all our contracts at the reserve feerate at the\n\u003e same time), or the\n\u003e operational cost.\n\u003e We got the historical fee estimates data from Statoshi [9], Txstats [10]\n\u003e and the historical chain\n\u003e data from Riccardo Casatta's `blocks_iterator` [11]. Thanks!\n\u003e\n\u003e The (research-quality..) code can be found at\n\u003e https://github.com/revault/research under the section\n\u003e \"Fee bumping\". Again it's very Revault specific, but at least the data can\n\u003e probably be reused for\n\u003e studying other protocols.\n\u003e\n\u003e\n\u003e ## 9. Insurances\n\u003e\n\u003e Of course, given it's all hacks and workarounds and there is no good\n\u003e answer to \"what is a reasonable\n\u003e feerate up to which we need to make contracts enforceable onchain?\", there\n\u003e is definitely room for an\n\u003e insurance market. But this enters the realm of opinions. Although i do\n\u003e have some (having discussed\n\u003e this topic for the past years with different people), i would like to keep\n\u003e this post focused on the\n\u003e technical aspects of this problem.\n\u003e\n\u003e\n\u003e\n\u003e [0] As far as i can tell, having offchain contracts be enforceable onchain\n\u003e by confirming a\n\u003e transaction before the expiration of a timelock is a widely agreed-upon\n\u003e approach. And i don't think\n\u003e we can opt for any other fundamentally different one, as you want to know\n\u003e you can claim back your\n\u003e coins from a contract after a deadline before taking part in it.\n\u003e\n\u003e [1] The Real Revault (tm) involves more transactions, but for the sake of\n\u003e conciseness i only\n\u003e detailed a minimum instance of the problem.\n\u003e\n\u003e [2] Only presigning part of the Unvault transactions allows to only\n\u003e delegate part of the coins,\n\u003e which can be abstracted as \"delegate x% of your stash\" in the user\n\u003e interface.\n\u003e\n\u003e [3]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html\n\u003e\n\u003e [4]\n\u003e https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L323-L329\n\u003e\n\u003e [5] https://github.com/bitcoin/bitcoin/pull/23121\n\u003e\n\u003e [6]\n\u003e https://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L494-L507\n\u003e\n\u003e [7] Of course this assumes a combinatorial coin selection, but i believe\n\u003e it's ok given we limit the\n\u003e number of coins beforehand.\n\u003e\n\u003e [8] Although there is the argument to outbid a censorship, anyone\n\u003e censoring you isn't necessarily a\n\u003e miner.\n\u003e\n\u003e [9] https://www.statoshi.info/\n\u003e\n\u003e [10] https://www.statoshi.info/\n\u003e\n\u003e [11] https://github.com/RCasatta/blocks_iterator\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211129/883846a6/attachment-0001.html\u003e",
"sig": "0d17af81dcd01374063ac1607163b8c340ea65f037d652762e7c4eb248de1923910004d2c26b51ca518af4670fd4c0059257ca510d494f5dab37eb33bef6c45f"
}