path: root/f3/dd5a698509022ebe8690956a0c3fddf15f8de3

Return-Path: <antoine.riard@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AB0FBC0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 23:56:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 799C16068F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 23:56:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Xri1dl65CtN6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 23:56:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com
 [IPv6:2a00:1450:4864:20::331])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 65486605F5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Dec 2021 23:56:53 +0000 (UTC)
Received: by mail-wm1-x331.google.com with SMTP id
 g191-20020a1c9dc8000000b0032fbf912885so2912543wme.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 08 Dec 2021 15:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=J8wtcZRKE5WfOLE2cZfJesFTIvo9wuuVMLPHIu3fKkc=;
 b=RTFrwkbGLsebpgkM7VIG3bz9D70suiA1pi+WsZcbGVCC/uP4/e4RPpJz89JwEKXa0W
 tubDs1DoV4+efwlDpnphfyFJN/zpxG/lcBPJyFGiySI0mQ4E6Rpzj/WZMY0x6YOqZNgb
 OpLsQBK80NlapV5mcyHY5M+T40PX62mX3nLiUT4a4XFUEMuR9fqbSVsjYrhvTvIn1DNT
 GS0bCpdXTcwpKConS5seconA8UV73/zo+Z6JyeTcvPgfWKqUnoIrqoEWanvagG9kP2ku
 X2n7ZcLKD/XI87Xv7KiRR2Ylsfb/lop/KYn2aOxvGEJ/e/w5ITxqxWtcZiGsFX1MdKe9
 WMOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=J8wtcZRKE5WfOLE2cZfJesFTIvo9wuuVMLPHIu3fKkc=;
 b=ZiomZVooCrPjtF+IZToyZwtimF4k3uubnhtEy34KbKtYMWKo6amUtTIhBW1AaKR5mT
 CON4eFLiJ/fypZ0XzWK/XvnJy8T8nimafNLoOsIztIkWBdAqfBEFEf5bIsnA4WL/iwek
 /JUUFvsAZE1xJOXXxB2prmc2RgMQuwkwaB48J5X4XodxE5Dq/noOr0lycSnqQ21LwkIn
 adDSYi3Toji+/eqqP9cB2k+dG4KVWRp0zqyPlZ7mj83HzySNwoNjLImvfHm7900UEGRL
 YUKoEcAEam90zm43xfAL1+YNP9Qo6/I5To6DCxnWS/B5Xk60Ox8Pv6RDjujmPZnOu8/t
 KG0g==
X-Gm-Message-State: AOAM530k/XyIV2LJsscSaW6lbWWs5zaKUMHARocbncg6MeWU1LyCKnNZ
 GTXG6LNOZTNgXMekhpC5rwtq7Xw7DDjvJI9qzhcbmdCMpdM=
X-Google-Smtp-Source: ABdhPJzRta7LuRejoa5QnSrjI/seitSVzUPq1rVGhWYyZ8kwvVJe+xejiFRsu7mHRG8XhAJUUz3qFX9qRVo3phu244c=
X-Received: by 2002:a7b:c119:: with SMTP id w25mr2460064wmi.70.1639007811285; 
 Wed, 08 Dec 2021 15:56:51 -0800 (PST)
MIME-Version: 1.0
References: <hBx6OYA5Mv9C_anoMQ-s-9l_XNwNFPfDVmOND9pXBJEBi7qsULF3bgPGpagtqjOsKDTXu8iOTVzvOjflz-M6EfnfwVH81Cu-nnai0kakouo=@protonmail.com>
 <CALZpt+F6h8uLw48e4FRrkjPe2ci6Uqy-o9H=++hu5fx7+bxOZw@mail.gmail.com>
 <8wtAeG1p6qyiOWW0pIJP06_h-3ro7UTBsNO-0BMxLnSKUU6xFBMEvhyQGhjsh3gvQAjDpFajGEC0C6NSQ0Nfj8KtT1cGlaQMW_nnEkAuozM=@protonmail.com>
In-Reply-To: <8wtAeG1p6qyiOWW0pIJP06_h-3ro7UTBsNO-0BMxLnSKUU6xFBMEvhyQGhjsh3gvQAjDpFajGEC0C6NSQ0Nfj8KtT1cGlaQMW_nnEkAuozM=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 8 Dec 2021 18:56:39 -0500
Message-ID: <CALZpt+Eb_aoD4Df9jA6g6+0RqbBMqijJrqRv3asH5vXZ5_uMcg@mail.gmail.com>
To: darosior <darosior@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000006034d205d2ab3ee1"
X-Mailman-Approved-At: Thu, 09 Dec 2021 09:17:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A fee-bumping model
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Dec 2021 23:56:57 -0000

--0000000000006034d205d2ab3ee1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Antoine,

> It seems to me the only policy-level mitigation for RBF pinning around
the "don't decrease the abolute fees of a less-than-a-block mempool" would
be to drop the requirement on increasing absolute fees if the mempool is
"full enough" (and the feerate increases exponentially, of course).

Yes, it's hard to say the "less-than-a-block-mempool" scenario is long-term
realistic. In the future, you can expect liquidity operations to be
triggered as soon as the network mempools start to be empty.  At a given
block space price, there is always room to improve your routing topology.

That said, you would like the default block construction strategy to be
"all-weather" economically aligned. To build such a more robust strategy, I
think a miner would have interest to level the  "full enough" bar.

I still think a policy-level mitigation is possible, where you have a
replace-by-fee rate above X MB of blocks and replace-by-fee under X.
Responsibility is on the L2 fee-bumper to guarantee the  honest bid is in
the X MB of blocks or the malicious pinning attacker has to overbid.

At first sight, yes committing the maximum tx size in the annex covered by
your counterparty signature should still allow you to add high-feerate
input. Though niice if we can save a consensus rule to fix pinnings.

> In any case, for Lightning i think it's a bad idea to re-introduce trust
on this side post anchor outputs. For Revault it's clearly out of the
question to introduce trust in your counterparties (why would you bother
having a fee-bumping mechanism in the >first place then?). Probably the
same holds for all offchain contracts.

Yeah it was a strawman exercise on the question "not knowledge of other
primitive that can be used by multi-party" :) I wouldn't recommend that
kind of fee-bumping "shared cache" scheme for a  trust-minimized setup.
Maybe interesting for watchtowers/LSP topologies.

> Black swan event 2.0? Just rule n=C2=B03 is inherent to any kind of fee
estimation.

It's just the old good massive mempool congestion systemic risk known since
the LN whitepaper. AFAIK, anchor output fee-bumping schemes have not really
started the work to be robust against that. What I'm aiming to point out is
that it might be even harder to build a fault-tolerant fee-bumping strategy
because of the "limited rationality" of your local node towards the
behaviors of the other bitcoin users in face of this phenomena. Would be
nice to have more research on that front.

> I don't think any kind of mempool-based estimate generalizes well, since
at any point the expected time before the next block is 10 minutes (and a
lot can happen in 10min).

Sure, you might be off-bid because of block variance, though if you're
ready to pay multiple RBF penalties which are linear, you might adjust your
shots in function of "real-time" mempool congestion.

> I'm very concerned that large stakeholders of the "offchain contracts
ecosystem" would just go this (easier) way and further increase mining
centralisation pressure.

*back on the whiteboard sweating on a consensus-enforced timestop primitive=
*

Cheers,
Antoine

Le mar. 30 nov. 2021 =C3=A0 10:19, darosior <darosior@protonmail.com> a =C3=
=A9crit :

> Hi Antoine,
>
> Thanks for your comment. I believe for Lightning it's simpler with regard
> to the management of the UTxO pool, but harder with regard to choosing
> a threat model.
> Responses inline.
>
>
> 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, th=
e
> miners, the crowd of bitcoin users. The number of the last type of player=
s
> 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 th=
e
> 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 o=
wn.
>
>
> I think this problem statement can be easily generalised to any offchain
> contract. And your points stand for all of them.
> "For any opened contract, ensure at any point the confirmation of a (set
> of) transaction(s) in a given number of blocks"
>
>
> 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 a=
s
> many subsets by broadcasting a revoked Commitment transaction different f=
or
> each. For Revault, I think you can also do unlimited partitions by mutati=
ng
> the ANYONECANPAY-input of the Cancel.
>
>
> Well you can already do unlimited partitions by adding different inputs t=
o
> it. You could malleate the witness, but since we are using Miniscript i'm
> confident you would only be able in a marginal way.
>
>
> 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 b=
y
> few L1 merchants accepting 0-conf to detect naive double-spend.
>
>
> We should aim to more than 0-conf (in)security level..
> It seems to me the only policy-level mitigation for RBF pinning around th=
e
> "don't decrease the abolute fees of a less-than-a-block mempool" would be
> to drop the requirement on increasing absolute fees if the mempool is "fu=
ll
> enough" (and the feerate increases exponentially, of course).
> Another approach could be by introducing new consensus rules as proposed
> by Jeremy last year [0]. If we go in the realm of new consensus rules, th=
en
> i think that simply committing to a maximum tx size would fix pinning by
> RBF rule 3. Could be in the annex, or in the unused sequence bits (althou=
gh
> they currently are by Lightning, meh). You could also check in the output
> script that the input commits to this.
>
> [0]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/01=
8168.html
>
>
> 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 CPF=
P,
> assuming interactivity. As the CPFP is counter-signed by everyone, the
> outputs can be CSV-1 encumbered to prevent pinnings. If the share-cache i=
s
> 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, thoug=
h
> arguably not worse than the current update fee mechanism.
>
>
> It really looks just like `update_fee`. Except maybe with the property
> that you have the channel liquidity not depend on the onchain feerate.
> In any case, for Lightning i think it's a bad idea to re-introduce trust
> on this side post anchor outputs. For Revault it's clearly out of the
> question to introduce trust in your counterparties (why would you bother
> having a fee-bumping mechanism in the first place then?). Probably the sa=
me
> holds for all offchain contracts.
>
>
> > 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 theo=
ry
> 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 custod=
y
> 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.
>
>
> True for routing nodes. For wallets (if receiving funds), it's not about
> an investment: just users expectations to being able to transact without
> risking to lose their funds (ie being able to enforce their contract
> onchain). Although wallets they are much less at risk.
>
>
> 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, yo=
ur
> fee-bumping reserve levels based from historical data might be always lat=
e
> by one "bank-run" scenario.
>
>
> Black swan event 2.0? Just rule n=C2=B03 is inherent to any kind of fee
> estimation.
>
> 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 compelli=
ng
> at the individual node-level, but make the mempol congestion worse
> holistically.
>
>
> Yeah so we are back to the "fractional reserve" model: you can only
> enforce X% of the offchain contracts your participate in.. Actually it's
> even an added assumption: that you still have operating contracts, with
> honest counterparties.
>
>
> 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).
>
>
> I don't think any kind of mempool-based estimate generalizes well, since
> at any point the expected time before the next block is 10 minutes (and a
> lot can happen in 10min).
>
> 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.
>
>
> Oh, yeah, i didn't explicit "not getting eclipsed" (or more generally
> "data availability") as an assumption since it's generally one made by
> participants of any offchain contract. In this case you can't even have
> decent fee estimation, so you are screwed anyways.
>
>
> 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...
>
>
> Unfortunately, given current mining centralisation, pools are in a very
> good position to offer pretty decent SLAs around that. With a block space
> insurance, you of course don't need all these convoluted fee-bumping hack=
s.
> I'm very concerned that large stakeholders of the "offchain contracts
> ecosystem" would just go this (easier) way and further increase mining
> centralisation pressure.
>
> I agree that a cryptography-based scheme around this type of insurance
> services would be the best way out.
>
>
> Antoine
>
> Le lun. 29 nov. 2021 =C3=A0 09:34, darosior via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
>> 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 whil=
e
>> 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 t=
o
>> 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 delegatio=
n
>> 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 require=
d
>> 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 a=
s
>> 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 window=
s
>> 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 nee=
d
>> 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 th=
e
>> 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 an=
d
>> 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 s=
o
>> at refill time so the
>> refiller can give an excess to pay for the fees of the fanout transactio=
n
>> (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. Bu=
t
>> 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 bumpin=
g
>> 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 firs=
t
>> 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 estimate=
s
>> aren't available (eg if
>> the user stopped their WT for say a hour and we come back up): we use th=
e
>> 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 kno=
w
>> 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 o=
f
>> 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/1df953813708287c32a15e771ba7495=
7ec44f354/feebumping/model/statemachine.py#L323-L329
>>
>> [5] https://github.com/bitcoin/bitcoin/pull/23121
>>
>> [6]
>> https://github.com/revault/research/blob/1df953813708287c32a15e771ba7495=
7ec44f354/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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>

--0000000000006034d205d2ab3ee1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi Antoine,<br></div><div><br>&gt; It seems to m=
e the only policy-level mitigation for RBF pinning around the &quot;don&#39=
;t decrease the abolute fees of a less-than-a-block mempool&quot; would be =
to drop the requirement on increasing absolute fees if the mempool is &quot=
;full enough&quot; (and the feerate increases exponentially, of course).<br=
><br>Yes, it&#39;s hard to say the &quot;less-than-a-block-mempool&quot; sc=
enario is long-term realistic. In the future, you can expect liquidity oper=
ations to be triggered as soon as the network mempools start to be empty.=
=C2=A0 At a given block space price, there is always room to improve your r=
outing topology.<br><br>That said, you would like the default block constru=
ction strategy to be &quot;all-weather&quot; economically aligned. To build=
 such a more robust strategy, I think a miner would have interest to level =
the=C2=A0 &quot;full enough&quot; bar.<br><br>I still think a policy-level =
mitigation is possible, where you have a replace-by-fee rate above X MB of =
blocks and replace-by-fee under X. Responsibility is on the L2 fee-bumper t=
o guarantee the=C2=A0 honest bid is in the X MB of blocks or the malicious =
pinning attacker has to overbid.<br><br>At first sight, yes committing the =
maximum tx size in the annex covered by your counterparty signature should =
still allow you to add high-feerate input. Though niice if we can save a co=
nsensus rule to fix pinnings.<br><br>&gt; In any case, for Lightning i thin=
k it&#39;s a bad idea to re-introduce trust on this side post anchor output=
s. For Revault it&#39;s clearly out of the question to introduce trust in y=
our counterparties (why would you bother having a fee-bumping mechanism in =
the &gt;first place then?). Probably the same holds for all offchain contra=
cts.<br><br>Yeah it was a strawman exercise on the question &quot;not knowl=
edge of other primitive that can be used by multi-party&quot; :) I wouldn&#=
39;t recommend that kind of fee-bumping &quot;shared cache&quot; scheme for=
 a=C2=A0 trust-minimized setup. Maybe interesting for watchtowers/LSP topol=
ogies.<br><br>&gt; Black swan event 2.0? Just rule n=C2=B03 is inherent to =
any kind of fee estimation.<br><br>It&#39;s just the old good massive mempo=
ol congestion systemic risk known since the LN whitepaper. AFAIK, anchor ou=
tput fee-bumping schemes have not really started the work to be robust agai=
nst that. What I&#39;m aiming to point out is that it might be even harder =
to build a fault-tolerant fee-bumping strategy because of the &quot;limited=
 rationality&quot; of your local node towards the behaviors of the other bi=
tcoin users in face of this phenomena. Would be nice to have more research =
on that front.<br><br>&gt; I don&#39;t think any kind of mempool-based esti=
mate generalizes well, since at any point the expected time before the next=
 block is 10 minutes (and a lot can happen in 10min).<br><br>Sure, you migh=
t be off-bid because of block variance, though if you&#39;re ready to pay m=
ultiple RBF penalties which are linear, you might adjust your shots in func=
tion of &quot;real-time&quot; mempool congestion.<br><br>&gt; I&#39;m very =
concerned that large stakeholders of the &quot;offchain contracts ecosystem=
&quot; would just go this (easier) way and further increase mining centrali=
sation pressure.<br><br>*back on the whiteboard sweating on a consensus-enf=
orced timestop primitive*<br><br></div>Cheers,<br></div>Antoine<br></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0=
mar. 30 nov. 2021 =C3=A0=C2=A010:19, darosior &lt;<a href=3D"mailto:darosio=
r@protonmail.com">darosior@protonmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi Antoine,<br><=
/div><div><br></div><div><div>Thanks for your comment. I believe for Lightn=
ing it&#39;s simpler with regard to the management of the UTxO pool, but ha=
rder with regard to choosing<br></div><div>a threat model.<br></div></div><=
div>Responses inline.<br></div><div><br></div><div><div><br></div><blockquo=
te type=3D"cite"><div dir=3D"ltr"><div>For any opened channel, ensure the c=
onfirmation of a Commitment transaction and the children HTLC-Success/HTLC-=
Timeout transactions. Note, in the Lightning security game you have to cons=
ider (at least) 4 types of players moves and incentives : your node, your c=
hannel counterparties, the miners, the crowd of bitcoin users. The number o=
f the last type of players is unknown from your node, however it should not=
 be forgotten you&#39;re in competition for block space, therefore their bl=
ock 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.<br></div><div><br></div><div>For a LN service provider, =
on-chain overpayments are bearing on your operational costs, thus downgradi=
ng your economic competitiveness. For the average LN user, overpayment migh=
t price out outside a LN non-custodial deployment, as you don&#39;t have th=
e minimal security budget to be on your own.<br></div></div></blockquote></=
div><div><br></div><div>I think this problem statement can be easily genera=
lised to any offchain contract. And your points stand for all of them.<br><=
/div><div>&quot;For any opened contract, ensure at any point the confirmati=
on of a (set of) transaction(s) in a given number of blocks&quot;<br></div>=
<div><br></div><div><br></div><div><blockquote type=3D"cite"><div dir=3D"lt=
r"><div>Same issue with Lightning, we can be pinned today on the basis of r=
eplace-by-fee rule 3. We can be also blinded by network mempool partitions,=
 a pinning counterparty can segregate all the full-nodes=C2=A0 in as many s=
ubsets 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.<br></div></div></blockquote></div><div><b=
r></div><div>Well you can already do unlimited partitions by adding differe=
nt inputs to it. You could malleate the witness, but since we are using Min=
iscript i&#39;m confident you would only be able in a marginal way.<br></di=
v><div><br></div><div><br></div><div><blockquote type=3D"cite"><div dir=3D"=
ltr"><div>That said, if you have a distributed towers deployment, spread ac=
ross the p2p network topology, and they can&#39;t be clustered together thr=
ough 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.<br></div><=
/div></blockquote></div><div><br></div><div>We should aim to more than 0-co=
nf (in)security level..<br></div><div><div>It seems to me the only policy-l=
evel mitigation for RBF pinning around the &quot;don&#39;t decrease the abo=
lute fees of a less-than-a-block mempool&quot; would be to drop the require=
ment on increasing absolute fees if the mempool is &quot;full enough&quot; =
(and the feerate increases exponentially, of course).<br></div><div>Another=
 approach could be by introducing new consensus rules as proposed by Jeremy=
 last year [0]. If we go in the realm of new consensus rules, then i think =
that simply committing to a maximum tx size would fix pinning by RBF rule 3=
. Could be in the annex, or in the unused sequence bits (although they curr=
ently are by Lightning, meh). You could also check in the output script tha=
t the input commits to this.<br></div></div><div><br></div><div>[0] <a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/=
018168.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2020-September/018168.html</a><br></div><div><br></div><div><br=
></div><div><blockquote type=3D"cite"><div dir=3D"ltr"><div>Have we already=
 discussed a fee-bumping &quot;shared cache&quot;, a CPFP variation ? Straw=
man idea: Alice and Bob commit collateral inputs to a separate UTXO from th=
e main &quot;offchain contract&quot; one. This UTXO is locked by a multi-si=
g. 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,=C2=A0 you can re-sign a high-feerate =
CPFP, assuming interactivity. As the CPFP is counter-signed by everyone, th=
e outputs can be CSV-1 encumbered to prevent pinnings. If the share-cache i=
s feeded at parity, there shouldn&#39;t be an incentive to waste or malicio=
usly inflate the feerate. I think this solution can be easily generalized t=
o 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&#39;re trusting your counterparty to interact, though arg=
uably not worse than the current update fee mechanism.<br></div></div></blo=
ckquote></div><div><br></div><div>It really looks just like `update_fee`. E=
xcept maybe with the property that you have the channel liquidity not depen=
d on the onchain feerate.<br></div><div>In any case, for Lightning i think =
it&#39;s a bad idea to re-introduce trust on this side post anchor outputs.=
 For Revault it&#39;s clearly out of the question to introduce trust in you=
r counterparties (why would you bother having a fee-bumping mechanism in th=
e first place then?). Probably the same holds for all offchain contracts.<b=
r></div><div><br></div><div><br></div><div><blockquote type=3D"cite"><div d=
ir=3D"ltr"><div>&gt; For Lightning, it&#39;d mean keeping an equivalent amo=
unt of funds as the sum of all your<br></div><div>channels balances sitting=
 there unallocated &quot;just in case&quot;. This is not reasonable.<br></d=
iv><div><br></div><div>Agree, game-theory wise, you would like to keep a fu=
ll fee-bumping reserve, ready to burn as much in fees as the contested HTLC=
 value, as it&#39;s the maximum gain of your counterparty. Though perfect e=
quilibrium is hard to achieve because your malicious counterparty might hav=
e an edge pushing you to broadcast your Commitment first by witholding HTLC=
 resolution.<br></div><div><br></div><div>Fractional fee-bumping reserves a=
re much more realistic to expect in the LN network. Lower fee-bumping reser=
ve, higher liquidity deployed, in theory higher routing fees. By observing =
historical feerates, average offchain balances at risk and routing fees exp=
ected gains, you should be able to discover an equilibrium where higher lev=
els of reserve aren&#39;t worth the opportunity cost. I guess this=C2=A0 eq=
uilibrium could be your LN fee-bumping reserve max feerate.<br></div><div><=
br></div><div>Note, I think the LN approach is a bit different from what su=
its a custody protocol like Revault,=C2=A0 as you compute a direct return o=
f the frozen fee-bumping liquidity. With Revault, if you have numerous bitc=
oins protected, it&#39;s might be more interesting to adopt a &quot;buy the=
 mempool, stupid&quot; strategy than risking fund safety for few percentage=
s of interest returns.<br></div></div></blockquote></div><div><br></div><di=
v>True for routing nodes. For wallets (if receiving funds), it&#39;s not ab=
out
 an investment: just users expectations to being able to transact
without risking to lose their funds (ie being able to enforce their
contract onchain). Although wallets they are much less at risk.<br></div><d=
iv><br></div><div><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr"=
><div>This is where the &quot;anticipate the crowd of bitcoin users move&qu=
ot; point can be laid out. As the crowd of bitcoin users&#39; fee-bumping r=
eserves are ultimately unknown from your node knowledge, you should be read=
y to be a bit more conservative than the vanilla fee-bumping strategies shi=
pped by default. In case of massive mempool congestion, your additional con=
servatism might get your time-sensitive transactions and game on the crowd =
of bitcoin users. First Problem: if all offchain bitcoin software adopt tha=
t strategy we might inflate the worst-case feerate rate at the benefit of t=
he miners, without holistically improving block throughput. Second problem =
: your class of offchain bitcoin softwares might have ridiculous fee-bumpin=
g reserve compared<br></div><div>to other classes of offchain bitcoin softw=
ares (Revault &gt; Lightning) and just be priced out bydesign in case of me=
mpool congestion. Third problem : as the number of offchain bitcoin applica=
tions should go up with time, your fee-bumping reserve levels based from hi=
storical data might be always late by one &quot;bank-run&quot; scenario.<br=
></div></div></blockquote></div><div><br>Black swan event 2.0? Just rule n=
=C2=B03 is inherent to any kind of fee estimation.<br></div><div><br></div>=
<div><blockquote type=3D"cite"><div dir=3D"ltr"><div>For Lightning, if you&=
#39;re short in fee-bumping reserves you might still do preemptive channel =
closures, either cooperatively or unilaterally and get back the off-chain l=
iquidity to protect the more economically interesting channels. Though agai=
n, that kind of automatic behavior might be compelling at the individual no=
de-level, but make the mempol congestion worse holistically.<br></div></div=
></blockquote></div><div><br></div><div>Yeah so we are back to the &quot;fr=
actional reserve&quot; model: you can only enforce X% of the offchain contr=
acts your participate in.. Actually it&#39;s even an added assumption: that=
 you still have operating contracts, with honest counterparties.<br></div><=
div><br></div><div><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr=
"><div>In case of massive mempool congestion, you might try to front-run th=
e crowd of bitcoin users relying on block connections for fee-bumping, and =
thus start your fee-bumping as soon as you observe feerate groups fluctuati=
ons in your local mempool(s).<br></div></div></blockquote></div><div><br></=
div><div>I don&#39;t think any kind of mempool-based estimate generalizes w=
ell, since at any point the expected time before the next block is 10 minut=
es (and a lot can happen in 10min).<br></div><div><br></div><div><blockquot=
e type=3D"cite"><div dir=3D"ltr"><div>Also you might proceed your fee-bumpi=
ng ticks on a local clock instead of block connections in case of time-dila=
tion or deeper eclipse attacks of your local node. Your view of the chain m=
ight be compromised but not your ability to broadcast transactions thanks t=
o emergency channels (in the non-LN sense...though in fact quid of txn wrap=
ped in onions ?) of communication.<br></div></div></blockquote></div><div><=
br></div><div>Oh, yeah, i didn&#39;t explicit &quot;not getting eclipsed&qu=
ot; (or more generally &quot;data availability&quot;) as an assumption sinc=
e it&#39;s generally one made by participants of any offchain contract. In =
this case you can&#39;t even have decent fee estimation, so you are screwed=
 anyways.<br></div><div><br></div><div><br></div><div><blockquote type=3D"c=
ite"><div dir=3D"ltr"><div>Yes, stay open the question on how you enforce t=
his 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. May=
be maybe some cryptographic or economically based mechanism on slashing or =
swaps could be found...<br></div></div></blockquote></div><div><div><br></d=
iv><div>Unfortunately, given current mining centralisation, pools are in a =
very good position to offer pretty decent SLAs around that. With a block sp=
ace insurance, you=C2=A0of course don&#39;t need all these convoluted fee-b=
umping hacks.<br></div></div><div>I&#39;m very concerned that large stakeho=
lders of the &quot;offchain contracts ecosystem&quot; would just go this (e=
asier) way and further increase mining centralisation pressure.<br></div><d=
iv><br></div><div>I agree that a cryptography-based scheme around this type=
 of insurance services would be the best way out.<br></div><div><br></div><=
div><br></div><div><blockquote type=3D"cite"><div dir=3D"ltr"><div>Antoine<=
br></div></div><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr">L=
e=C2=A0lun. 29 nov. 2021 =C3=A0=C2=A009:34, darosior via bitcoin-dev &lt;<a=
 rel=3D"noopener noreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =
=C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div>Hi everyone,<br></div><div><br></div><div>Fee-bumping is paramount t=
o the security of many protocols building on Bitcoin, as they require the<b=
r></div><div>confirmation of a transaction (which might be presigned) befor=
e the expiration of a timelock at any<br></div><div>point after the establi=
shment of the contract.<br></div><div><br></div><div>The part of Revault us=
ing presigned transactions (the delegation from a large to a smaller multis=
ig)<br></div><div>is no exception. We have been working on how to approach =
this for a while now and i&#39;d like to share<br></div><div>what we have i=
n order to open a discussion on this problem so central to what seem to be =
The Right<br></div><div>Way [0] to build on Bitcoin but which has yet to be=
 discussed in details (at least publicly).<br></div><div><br></div><div>I&#=
39;ll discuss what we came up with for Revault (at least for what will be i=
ts first iteration) but my<br></div><div>intent with posting to the mailing=
 list is more to frame the questions to this problem we are all<br></div><d=
iv>going to face rather than present the results of our study tailored to t=
he Revault usecase.<br></div><div>The discussion is still pretty Revault-ce=
ntric (as it&#39;s the case study) but hopefully this can help<br></div><di=
v>future protocol designers and/or start a discussion around what everyone&=
#39;s doing for existing ones.<br></div><div><br></div><div><br></div><div>=
## 1. Reminder about Revault<br></div><div><br></div><div>The part of Revau=
lt we are interested in for this study is the delegation process, and more<=
br></div><div>specifically the application of spending policies by network =
monitors (watchtowers).<br></div><div>Coins are received on a large multisi=
g. Participants of this large multisig create 2 [1]<br></div><div>transacti=
ons. The Unvault, spending a deposit UTxO, creates an output paying either =
to the small<br></div><div>multisig after a timelock or to the large multis=
ig immediately. The Cancel, spending the Unvault<br></div><div>output throu=
gh the non-timelocked path, creates a new deposit UTxO.<br></div><div>Parti=
cipants regularly exchange the Cancel transaction signatures for each depos=
it, sharing the<br></div><div>signatures with the watchtowers they operate.=
 They then optionally [2] sign the Unvault transaction<br></div><div>and sh=
are the signatures with the small multisig participants who can in turn use=
 them to proceed<br></div><div>with a spending. Watchtowers can enforce spe=
nding policies (say, can&#39;t Unvault outside of business<br></div><div>ho=
urs) by having the Cancel transaction be confirmed before the expiration of=
 the timelock.<br></div><div><br></div><div><br></div><div>## 2. Problem st=
atement<br></div><div><br></div><div>For any delegated vault, ensure the co=
nfirmation of a Cancel transaction in a configured number of<br></div><div>=
blocks at any point. In so doing, minimize the overpayments and the UTxO se=
t footprint. Overpayments<br></div><div>increase the burden on the watchtow=
er operator by increasing the required frequency of refills of the<br></div=
><div>fee-bumping wallet, which is already the worst user experience. You a=
re likely to manage a number of<br></div><div>UTxOs with your number of vau=
lts, which comes at a cost for you as well as everyone running a full<br></=
div><div>node.<br></div><div><br></div><div>Note that this assumes miners a=
re economically rationale, are incentivized by *public* fees and that<br></=
div><div>you have a way to propagate your fee-bumped transaction to them. W=
e also don&#39;t consider the block<br></div><div>space bounds.<br></div><d=
iv><br></div><div>In the previous paragraph and the following text, &quot;v=
ault&quot; can generally be replaced with &quot;offchain<br></div><div>cont=
ract&quot;.<br></div><div><br></div><div><br></div><div>## 3. With presigne=
d transactions<br></div><div><br></div><div>As you all know, the first diff=
iculty is to get to be able to unilaterally enforce your contract<br></div>=
<div>onchain. That is, any participant must be able to unilaterally bump th=
e fees of a transaction even<br></div><div>if it was co-signed by other par=
ticipants.<br></div><div><br></div><div>For Revault we can afford to introd=
uce malleability in the Cancel transaction since there is no<br></div><div>=
second-stage transaction depending on its txid. Therefore it is pre-signed =
with ANYONECANPAY. We<br></div><div>can&#39;t use ANYONECANPAY|SINGLE since=
 it would open a pinning vector [3]. Note how we can&#39;t leverage<br></di=
v><div>the carve out rule, and neither can any other more-than-two-parties =
contract.<br></div><div>This has a significant implication for the rest, as=
 we are entirely burning fee-bumping UTxOs.<br></div><div><br></div><div>Th=
is opens up a pinning vector, or at least a significant nuisance: any other=
 party can largely<br></div><div>increase the absolute fee without increasi=
ng the feerate, leveraging the RBF rules to prevent you<br></div><div>from =
replacing it without paying an insane fee. And you might not see it in your=
 own mempool and<br></div><div>could only suppose it&#39;s happening by rec=
eiving non-full blocks or with transactions paying a lower<br></div><div>fe=
erate.<br></div><div>Unfortunately i know of no other primitive that can be=
 used by multi-party (i mean, &gt;2) presigned<br></div><div>transactions p=
rotocols for fee-bumping that aren&#39;t (more) vulnerable to pinning.<br><=
/div><div><br></div><div><br></div><div>## 4. We are still betting on futur=
e feerate<br></div><div><br></div><div>The problem is still missing one mor=
e constraint. &quot;Ensuring confirmation at any time&quot; involves ensuri=
ng<br></div><div>confirmation at *any* feerate, which you *cannot* do. So w=
hat&#39;s the limit? In theory you should be ready<br></div><div>to burn as=
 much in fees as the value of the funds you want to get out of the contract=
. So... For us<br></div><div>it&#39;d mean keeping for each vault an equiva=
lent amount of funds sitting there on the watchtower&#39;s hot<br></div><di=
v>wallet. For Lightning, it&#39;d mean keeping an equivalent amount of fund=
s as the sum of all your<br></div><div>channels balances sitting there unal=
located &quot;just in case&quot;. This is not reasonable.<br></div><div><br=
></div><div>So you need to keep a maximum feerate, above which you won&#39;=
t be able to ensure the enforcement of<br></div><div>all your contracts onc=
hain at the same time. We call that the &quot;reserve feerate&quot; and you=
 can have<br></div><div>different strategies for choosing it, for instance:=
<br></div><div>- The 85th percentile over the last year of transactions fee=
rates<br></div><div>- The maximum historical feerate<br></div><div>- The ma=
ximum historical feerate adjusted in dollars (makes more sense but introduc=
es a (set of?)<br></div><div>=C2=A0 trusted oracle(s) in a security-critica=
l component)<br></div><div>- Picking a random high feerate (why not? It&#39=
;s an arbitrary assumption anyways)<br></div><div><br></div><div>Therefore,=
 even if we don&#39;t have to bet on the broadcast-time feerate market at s=
igning time anymore<br></div><div>(since we can unilaterally bump), we stil=
l need some kind of prediction in preparation of making<br></div><div>funds=
 available to bump the fees at broadcast time.<br></div><div>Apart from jud=
ging that 500sat/vb is probably more reasonable than 10sat/vbyte, this unfo=
rtunately<br></div><div>sounds pretty much crystal-ball-driven.<br></div><d=
iv><br></div><div>We currently use the maximum of the 95th percentiles over=
 90-days windows over historical block chain<br></div><div>feerates. [4]<br=
></div><div><br></div><div><br></div><div>## 5. How much funds does my watc=
htower need?<br></div><div><br></div><div>That&#39;s what we call the &quot=
;reserve&quot;. Depending on your reserve feerate strategy it might vary ov=
er<br></div><div>time. This is easier to reason about with a per-contract r=
eserve. For Revault it&#39;s pretty<br></div><div>straightforward since the=
 Cancel transaction size is static: `reserve_feerate * cancel_size`. For<br=
></div><div>other protocols with dynamic transaction sizes (or even package=
s of transactions) it&#39;s less so. For<br></div><div>your Lightning chann=
el you would probably take the maximum size of your commitment transaction<=
br></div><div>according to your HTLC exposure settings + the size of as man=
y `htlc_success` transaction?<br></div><div><br></div><div>Then you either =
have your software or your user guesstimate how many offchain contracts the=
<br></div><div>watchtower will have to watch, time that by the per-contract=
 reserve and refill this amount (plus<br></div><div>some slack in practice)=
. Once again, a UX tradeoff (not even mentioning the guesstimation UX):<br>=
</div><div>overestimating leads to too many unallocated funds sitting on a =
hot wallet, underestimating means<br></div><div>(at best) inability to part=
icipate in new contracts or being &quot;at risk&quot; (not being able to en=
force<br></div><div>all your contracts onchain at your reserve feerate) bef=
ore a new refill.<br></div><div><br></div><div>For vaults you likely have l=
arge-value UTxOs and small transactions (the Cancel is one-in one-out in<br=
></div><div>Revault). For some other applications with large transactions a=
nd lower-value UTxOs on average it&#39;s<br></div><div>likely that only par=
t of the offchain contracts might be enforceable at a reasonable feerate. I=
s it<br></div><div>reasonable?<br></div><div><br></div><div><br></div><div>=
## 6. UTxO pool layout<br></div><div><br></div><div>Now that you somehow ma=
naged to settle on a refill amount, how are you going to use these funds?<b=
r></div><div>Also, you&#39;ll need to manage your pool across time (consoli=
dating small coins, and probably fanning<br></div><div>out large ones).<br>=
</div><div><br></div><div>You could keep a single large UTxO and peel it as=
 you need to sponsor transactions. But this means<br></div><div>that you ne=
ed to create a coin of a specific value according to your need at the curre=
nt feerate<br></div><div>estimation, hope to have it confirmed in a few blo=
cks (at least for now! [5]), and hope that the<br></div><div>value won&#39;=
t be obsolete by the time it confirmed. Also, you&#39;d have to do that for=
 any number of<br></div><div>Cancel, chaining feebump coin creation transac=
tions off the change of the previous ones or replacing<br></div><div>them w=
ith more outputs. Both seem to become really un-manageable (and expensive) =
in many edge-cases,<br></div><div>shortening the time you have to confirm t=
he actual Cancel transaction and creating uncertainty about<br></div><div>t=
he reserve (how much is my just-in-time fanout going to cost me in fees tha=
t i need to refill in<br></div><div>advance on my watchtower wallet?).<br><=
/div><div>This is less of a concern for protocols using CPFP to sponsor tra=
nsactions, but they rely on a<br></div><div>policy rule specific to 2-parti=
es contracts.<br></div><div><br></div><div>Therefore for Revault we fan-out=
 the coins per-vault in advance. We do so at refill time so the<br></div><d=
iv>refiller can give an excess to pay for the fees of the fanout transactio=
n (which is reasonable since<br></div><div>it will occur just after the ref=
illing transaction confirms). When the watchtower is asked to watch<br></di=
v><div>for a new delegated vault it will allocate coins from the pool of fa=
nned-out UTxOs to it (failing<br></div><div>that, it would refuse the deleg=
ation).<br></div><div>What is a good distribution of UTxOs amounts per vaul=
t? We want to minimize the number of coins,<br></div><div>still have coins =
small enough to not overpay (remember, we can&#39;t have change) and be abl=
e to bump a<br></div><div>Cancel up to the reserve feerate using these coin=
s. The two latter constraints are directly in<br></div><div>contradiction a=
s the minimal value of a coin usable at the reserve feerate (paying for its=
 own input<br></div><div>fee + bumping the feerate by, say, 5sat/vb) is alr=
eady pretty high. Therefore we decided to go with<br></div><div>two distrib=
utions per vault. The &quot;reserve distribution&quot; alone ensures that w=
e can bump up to the<br></div><div>reserve feerate and is usable for high f=
eerates. The &quot;bonus distribution&quot; is not, but contains<br></div><=
div>smaller coins useful to prevent overpayments during low and medium fee =
periods (which is most of the<br></div><div>time).<br></div><div>Both distr=
ibutions are based on a basic geometric suite [6]. Each value is half the p=
revious one.<br></div><div>This exponentially decreases the value, limiting=
 the number of coins. But this also allows for<br></div><div>pretty small c=
oins to exist and each coin&#39;s value is equal to the sum of the smaller =
coins,<br></div><div>or smaller by at most the value of the smallest coin. =
Therefore bounding the maximum overpayment to<br></div><div>the smallest co=
in&#39;s value [7].<br></div><div><br></div><div>For the management of the =
UTxO pool across time we merged the consolidation with the fanout. When<br>=
</div><div>fanning out a refilled UTxO, we scan the pool for coins that nee=
d to be consolidated according to a<br></div><div>heuristic. An instance of=
 a heuristic is &quot;the coin isn&#39;t allocated and would not have been =
able to<br></div><div>increase the fee at the median feerate over the past =
90 days of blocks&quot;.<br></div><div>We had this assumption that feerate =
would tend to go up with time and therefore discarded having to<br></div><d=
iv>split some UTxOs from the pool. We however overlooked that a large incre=
ase in the exchange price of<br></div><div>BTC as we&#39;ve seen during the=
 past year could invalidate this assumption and that should arguably be<br>=
</div><div>reconsidered.<br></div><div><br></div><div><br></div><div>## 7. =
Bumping and re-bumping<br></div><div><br></div><div>First of all, when to f=
ee-bump? At fixed time intervals? At each block connection? It sounds like,=
<br></div><div>given a large enough timelock, you could try to greed by &qu=
ot;trying your luck&quot; at a lower feerate and<br></div><div>only re-bump=
ing every N blocks. You would then start aggressively bumping at every bloc=
k after M<br></div><div>blocks have passed. But that&#39;s actually a bet (=
in disguised?) that the next block feerate in M blocks<br></div><div>will b=
e lower than the current one. In the absence of any predictive model it is =
more reasonable to<br></div><div>just start being aggressive immediately.<b=
r></div><div>You probably want to base your estimates on `estimatesmartfee`=
 and as a consequence you would re-bump<br></div><div>(if needed )after eac=
h block connection, when your estimates get updated and you notice your<br>=
</div><div>transaction was not included in the block.<br></div><div><br></d=
iv><div>In the event that you notice a consequent portion of the block is f=
illed with transactions paying<br></div><div>less than your own, you might =
want to start panicking and bump your transaction fees by a certain<br></di=
v><div>percentage with no consideration for your fee estimator. You might s=
kew miners incentives in doing<br></div><div>so: if you increase the fees b=
y a factor of N, any miner with a fraction larger than 1/N of the<br></div>=
<div>network hashrate now has an incentive to censor your transaction at fi=
rst to get you to panic. Also<br></div><div>note this can happen if you wan=
t to pay the absolute fees for the &#39;pinning&#39; attack mentioned in<br=
></div><div>section #2, and that might actually incentivize miners to perfo=
rm it themselves..<br></div><div><br></div><div>The gist is that the most e=
ffective way to bump and rebump (RBF the Cancel tx) seems to just be to<br>=
</div><div>consider the `estimatesmartfee 2 CONSERVATIVE` feerate at every =
block your tx isn&#39;t included in, and<br></div><div>to RBF it if the fee=
rate is higher.<br></div><div>In addition, we fallback to a block chain bas=
ed estimation when estimates aren&#39;t available (eg if<br></div><div>the =
user stopped their WT for say a hour and we come back up): we use the 85th =
percentile over the<br></div><div>feerates in the last 6 blocks. Sure, mine=
rs can try to have an influence on that by stuffing their<br></div><div>blo=
cks with large fee self-paying transactions, but they would need to:<br></d=
iv><div>1. Be sure to catch a significant portion of the 6 blocks (at least=
 2, actually)<br></div><div>2. Give up on 25% of the highest fee-paying tra=
nsactions (assuming they got the 6 blocks, it&#39;s<br></div><div>=C2=A0 =
=C2=A0proportionally larger and incertain as they get less of them)<br></di=
v><div>3. Hope that our estimator will fail and we need to fall back to the=
 chain-based estimation<br></div><div><br></div><div><br></div><div>## 8. O=
ur study<br></div><div><br></div><div>We essentially replayed the historica=
l data with different deployment configurations (number of<br></div><div>pa=
rticipants and timelock) and probability of an event occurring (event being=
 say an Unvault, an<br></div><div>invalid Unvault, a new delegation, ..). W=
e then observed different metrics such as the time at risk<br></div><div>(w=
hen we can&#39;t enforce all our contracts at the reserve feerate at the sa=
me time), or the<br></div><div>operational cost.<br></div><div>We got the h=
istorical fee estimates data from Statoshi [9], Txstats [10] and the histor=
ical chain<br></div><div>data from Riccardo Casatta&#39;s `blocks_iterator`=
 [11]. Thanks!<br></div><div><br></div><div>The (research-quality..) code c=
an be found at <a href=3D"https://github.com/revault/research" rel=3D"noope=
ner noreferrer" target=3D"_blank">https://github.com/revault/research</a> u=
nder the section<br></div><div>&quot;Fee bumping&quot;. Again it&#39;s very=
 Revault specific, but at least the data can probably be reused for<br></di=
v><div>studying other protocols.<br></div><div><br></div><div><br></div><di=
v>## 9. Insurances<br></div><div><br></div><div>Of course, given it&#39;s a=
ll hacks and workarounds and there is no good answer to &quot;what is a rea=
sonable<br></div><div>feerate up to which we need to make contracts enforce=
able onchain?&quot;, there is definitely room for an<br></div><div>insuranc=
e market. But this enters the realm of opinions. Although i do have some (h=
aving discussed<br></div><div>this topic for the past years with different =
people), i would like to keep this post focused on the<br></div><div>techni=
cal aspects of this problem.<br></div><div><br></div><div><br></div><div><b=
r></div><div>[0] As far as i can tell, having offchain contracts be enforce=
able onchain by confirming a<br></div><div>transaction before the expiratio=
n of a timelock is a widely agreed-upon approach. And i don&#39;t think<br>=
</div><div>we can opt for any other fundamentally different one, as you wan=
t to know you can claim back your<br></div><div>coins from a contract after=
 a deadline before taking part in it.<br></div><div><br></div><div>[1] The =
Real Revault (tm) involves more transactions, but for the sake of concisene=
ss i only<br></div><div>detailed a minimum instance of the problem.<br></di=
v><div><br></div><div>[2] Only presigning part of the Unvault transactions =
allows to only delegate part of the coins,<br></div><div>which can be abstr=
acted as &quot;delegate x% of your stash&quot; in the user interface.<br></=
div><div><br></div><div>[3] <a href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2020-May/017835.html" rel=3D"noopener noreferrer" targe=
t=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-M=
ay/017835.html</a><br></div><div><br></div><div>[4] <a href=3D"https://gith=
ub.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f354/feebu=
mping/model/statemachine.py#L323-L329" rel=3D"noopener noreferrer" target=
=3D"_blank">https://github.com/revault/research/blob/1df953813708287c32a15e=
771ba74957ec44f354/feebumping/model/statemachine.py#L323-L329</a><br></div>=
<div><br></div><div>[5] <a href=3D"https://github.com/bitcoin/bitcoin/pull/=
23121" rel=3D"noopener noreferrer" target=3D"_blank">https://github.com/bit=
coin/bitcoin/pull/23121</a><br></div><div><br></div><div>[6] <a href=3D"htt=
ps://github.com/revault/research/blob/1df953813708287c32a15e771ba74957ec44f=
354/feebumping/model/statemachine.py#L494-L507" rel=3D"noopener noreferrer"=
 target=3D"_blank">https://github.com/revault/research/blob/1df953813708287=
c32a15e771ba74957ec44f354/feebumping/model/statemachine.py#L494-L507</a><br=
></div><div><br></div><div>[7] Of course this assumes a combinatorial coin =
selection, but i believe it&#39;s ok given we limit the<br></div><div>numbe=
r of coins beforehand.<br></div><div><br></div><div>[8] Although there is t=
he argument to outbid a censorship, anyone censoring you isn&#39;t necessar=
ily a<br></div><div>miner.<br></div><div><br></div><div>[9] <a href=3D"http=
s://www.statoshi.info/" rel=3D"noopener noreferrer" target=3D"_blank">https=
://www.statoshi.info/</a><br></div><div><br></div><div>[10] <a href=3D"http=
s://www.statoshi.info/" rel=3D"noopener noreferrer" target=3D"_blank">https=
://www.statoshi.info/</a><br></div><div><br></div><div>[11] <a href=3D"http=
s://github.com/RCasatta/blocks_iterator" rel=3D"noopener noreferrer" target=
=3D"_blank">https://github.com/RCasatta/blocks_iterator</a><br></div><div>_=
______________________________________________<br></div><div>bitcoin-dev ma=
iling list<br></div><div><a rel=3D"noopener noreferrer" href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a><br></div><div><a href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev" rel=3D"noopener noreferrer" target=3D"_bl=
ank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>=
</div></blockquote></div></blockquote></div><div><br></div></blockquote></d=
iv>

--0000000000006034d205d2ab3ee1--