From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 902DEC000B for ; Sat, 12 Mar 2022 18:08:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 7959C813DA for ; Sat, 12 Mar 2022 18:08:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJDP4gGQ4d_w for ; Sat, 12 Mar 2022 18:08:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by smtp1.osuosl.org (Postfix) with ESMTPS id A98F8813A4 for ; Sat, 12 Mar 2022 18:08:44 +0000 (UTC) Date: Sat, 12 Mar 2022 18:08:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1647108521; bh=uT9rw3HBaSrifK4LGsLd83XEggx+GBbDUknLxYirNeE=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc:Date:Subject: Reply-To:Feedback-ID:Message-ID; b=DtNXmvrR3dn4XmL1lXsKX57cRIBS1IVU67GVcL6vXANLXELHArzBpMTBDOdy5AjOK 2Hs8j/unwnVv9ZzYiu5em0c9oz8bd6b1UHfPTXcoWBGzGbOyM35YjWtcFrR8D7U1/d ak+K1yaZkm2Mci7Vd2sTI46PVfVzNNUOAY0cumgiqBlrBtWujkpUHRG9yYWrio077g eQ9WvAwNNfDyGbC7boBJ8MVyK0y2/P2n3dq/mzVzZ8ND5HeLMTTP/sduGlYdbqDnLX laBDvMqP2bODNjiPnZjddljO5c+UPgEDCfWhTgqggKXwHCXLG7E2oVMH0XYQ1/2abX 5XZ0tGTpP/Xjg== To: Bitcoin Protocol Discussion From: darosior Reply-To: darosior Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 12 Mar 2022 18:33:48 +0000 Subject: [bitcoin-dev] Covenants and feebumping X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2022 18:08:46 -0000 The idea of a soft fork to fix dynamic fee bumping was recently put back on= the table. It might sound radical, as what prevents today reasonable fee bumping for contracts = with presigned transactions (pinning) has to do with nodes' relay policy. But the frustrat= ion is understandable given the complexity of designing fee bumping with today's primitives. [0] Recently too, there was a lot of discussions around covenants. Covenants (c= onceptually, not talking about any specific proposal) seem to open lots of new use cases and to be d= esired by (some?) Bitcoin application developers and users. I think that fee bumping using covenants has attractive properties, and it = requires a soft fork that is already desirable beyond (trying) to fix fee bumping. However i could no= t come up with a solution as neat for other protocols than vaults. I'd like to hear from others about= 1) taking this route for fee bumping 2) better ideas on applying this to other protocols. In a vault construction you have a UTxO which can only be spent by an Unvau= lting transaction, whose output triggers a timelock before the expiration of which a revocation tran= saction may be confirmed. The revocation transaction being signed in advance (typically before sharin= g the signature for the Unvault transaction) you need fee bumping in order for the contract to actu= ally be enforceable. Now, with a covenant you could commit to the revocation tx instead of presi= gning it. And using a Taproot tree you could commit to different versions of it with increasing f= eerate. Any network monitor (the brooadcaster, a watchtower, ..) would be able to RBF the revoc= ation transaction if it doesn't confirm by spending using a leaf with a higher-feerate transaction = being committed to. Of course this makes for a perfect DoS: it would be trivial for a miner to = infer that you are using a specific vault standard and guess other leaves and replace the witness to= use the highest-feerate spending path. You could require a signature from any of the participants. = Or, at the cost of an additional depth, in the tree you could "salt" each leaf by pairing it with= -say- an OP_RETURN leaf. But this leaves you with a possible internal blackmail for multi-party cont= racts (although it's less of an issue for vaults, and not one for single-party vaults). What you could do instead is attaching an increasing relative timelock to e= ach leaf (as the committed revocation feerate increases, so does the timelock). You need to be careful= to note wreck miner incentives here (see [0], [1], [2] on "miner harvesting"), but this enables= the nice property of a feerate which "adapts" to the block space market. Another nice property of = this approach is the integrated anti fee sniping protection if the revocation transaction pays a= non-trivial amount of fees. Paying fees from "shared" funds instead of a per-watchtower fee-bumping wal= let opened up the blackmail from the previous section, but the benefits of paying from intern= al funds shouldn't be understated. No need to decide on an amount to be refilled. No need to bother the user t= o refill the fee-bumping wallet (before they can participate in more contracts, or worse before a de= adline at which all contracts are closed). No need for a potentially large amount of funds to j= ust sit on a hot wallet "just in case". No need to duplicate this amount as you replicate the numbe= r of network monitors (which is critical to the security of such contracts). In addition, note how modifying the feerate of the revocation transaction i= n place is less expensive than adding a (pair of) new input (and output), let alone adding an entire = new transaction to CPFP. Aside, and less importantly, it can be made to work with today's relay rule= s (just use fee thresholds adapted to the current RBF thresholds, potentially with some leeway to acco= unt for policy changes). Paying from shared funds (in addition to paying from internal funds) also p= revents pervert incentives for contracts with more than 2 parties. In case one of the parti= es breaches it, all remaining parties have an incentive to enforce the contract.. But only one = would otherwise pay for it! It would open up the door to some potential sneaky techniques to wait f= or another party to pay for the fees, which is at odd with the reactive security model. Let's examine how it could be concretely designed. Say you have a vault wal= let software for a setup with 5 participants. The revocation delay is 144 blocks. You assume revocat= ion to be infrequent (if one happens it's probably a misconfigured watchtower that needs be fixed be= fore the next unvaulting), so you can afford infrequent overpayments and larger fee thres= holds. Participants assume the vault will be spent within a year and assume a maximum possible = feerate for this year of 10ksat/vb. They create a Taproot tree of depth 7. First leaf is the spending path (ope= n to whomever the vault pays after the 144 blocks). Then the leaf `i` for `i` in `[1, 127]` is a co= venant to the revocation transaction with a feerate `i * 79` sats/vb and a relative timelock of `i -= 1` blocks. Assuming the covenant to the revocation transaction is 33 bytes [3], that's= a witness of: 1 + 33 + 1 + 33 + 7 * 32 =3D 292 WU (73 vb) ^^^^^^ ^^^^^^^^^^^^^^ witscript control block for any of the revocation paths. The revocation transaction is 1-input 1-ou= tput, so in total it's 10.5 + 41 + 73 + 43 =3D 167.5 vb ^^^^ ^^^^^^^^^^^ ^^^^ header input|witness output The transaction size is not what you'd necessarily want to optimize for fir= st, still, it is smaller in this case than using other feebumping primitives and has a smaller footp= rint on the UTxO set. For instance for adding a feebumping input and change output assuming all Tapro= ot inputs and outputs (CPFP is necessarily even larger): 5 * 64 + 1 + 5 * (32 + 1) + 1 + 33 =3D 520 WU (105 vb) ^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^ witness witscript control 10.5 + 41 + 105 + 41 + 16.5 + 2 * 43 =3D 300 vb ^^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^ header input|witness fb input|witness outputs >From there, you can afford more depths at the tiny cost of 8 more vbytes ea= ch. You might want them for: - more granularity (if you can afford large enough timelocks) - optimizing for the spending path rather than the revocation one - adding a hashlock to prevent nuisance (with the above script a third part= y could malleate a spending path into a revocation one). You can use the OP_RETURN trick fro= m above to prevent that. Unfortunately, the timelocked-covenant approach to feebumping only applies = to bumping the first transaction of a chain (you can't pay for the parent with a timelock) so fo= r instance it's not usable for HTLC transactions in Lightning to bump the parent commitment tx.= The same goes for bumping the update tx in Coinpool. It could be worked around by having a different covenant per participant (p= aying the fee from either of the participants' output) behind a signature check. Of course it require= s funds to already be in the contract (HTLC, Coinpool leaf) to pay for your own unilateral close, bu= t if you don't have any fund in the contract it doesn't make sense to try to feebump it in the firs= t place. The same goes for small amounts: you'd only allocate up to the value of the contract (min= us a dust preference) in fees in order to enforce it. This is less nice for external monitors as it requires a private key (or an= other secret) to be committed to in advance) to be able to bump [4] and does not get rid of the= "who's gonna pay for the enforcement" issue in >2-parties contracts. Still, it's more optimal and us= able than CPFP or adding a pair of input/output for all the reasons mentioned above. Thoughts? Antoine [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/0= 19614.html [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/0= 19615.html [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/0= 19627.html [3] That's obviously close to the CTV construction. But using another more = flexible (and therefore less optimized) construction would not be a big deal. It might in fact = be necessary for more elaborated (realistic?) usecases than the simple one detailed here. [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/0= 19879.html