{"type":"rich","version":"1.0","title":"Jeremy Rubin [ARCHIVE] wrote","author_name":"Jeremy Rubin [ARCHIVE] (npub1xu…fzef0)","author_url":"https://yabu.me/npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2022-03-13\n📝 Original message:Hi Antoine,\n\nI have a few high level thoughts on your post comparing these types of\nprimitive to an explicit soft fork approach:\n\n1) Transaction sponsors *is* a type of covenant. Precisely, it is very\nsimilar to an \"Impossible Input\" covenant in conjunction with a \"IUTXO\" I\ndefined in my 2017 workshop\nhttps://rubin.io/public/pdfs/multi-txn-contracts.pdf (I know, I know...\nself citation, not cool, but helps with context).\n\nHowever, for Sponsors itself we optimize the properties of how it works \u0026\nis represented, as well as \"tighten the hatches\" on binding to specific TX\nvs merely spend of the outputs (which wouldn't work as well with APO).\n\nPerhaps thinking of something like sponsors as a form of covenant, rather\nthan a special purpose thing, is helpful?\n\nThere's a lot you could do with a general \"observe other txns in {this\nblock, the chain}\" primitive. The catch is that for sponsors we don't\n*care* to enable people to use this as a \"smart contracting primitive\", we\nwant to use it for fee bumping. So we don't care about programmability, we\ncare about being able to use the covenant to bump fees.\n\n2) On Chain Efficiency.\n\n\nA) Precommitted Levels\nAs you've noted, an approach like precomitted different fee levels might\nwork, but has substantial costs.\n\nHowever, with sponsors, the minimum viable version of this (not quite what\nis spec'd in my prior email, but it could be done this way if we care to\noptimize for bytes) would require 1 in and 1 out with only 32 bytes extra.\nSo that's around 40 bytes outpoint + 64 bytes signature + 40 bytes output +\n32 bytes metadata = 174 bytes per bump. Bumps in this way can also\namortize, so bumping \u003e1 txn at the same time would hit the limit of 32\nbytes + 144/n  bytes to bump more than one thing. You can imagine cases\nwhere this might be popular, like \"close \u003e1 of my LN channels\" or \"start\nwithdrawals for 5 of my JamesOB vaulted coins\"\n\nB) Fancy(er) Covenants\n\nWe might also have something with OP_CAT and CSFS where bumps are done as\nsome sort of covenant-y thing that lets you arbitrarily rewrite\ntransactions.\n\nNot too much to say other than that it is difficult to get these down in\nsize as the scripts become more complex, not to mention the (hotly\ndiscussed of late) ramifications of those covenants more generally.\n\nAbsent a concrete fancy covenant with fee bumping, I can't comment.\n\n3) On Capital Efficiency\n\nSomething like a precommitted or covenant fee bump requires the fee capital\nto be pre-committed inside the UTXO, whereas for something like Sponsors\nyou can use capital you get sometime later. In certain models -- e.g.,\nchannels -- where you might expect only log(N) of your channels to fail in\na given epoch, you don't need to allocate as much capital as if you were to\nhave to do it in-band. This is also true for vaults where you know you only\nwant to open 1 per month let's say, and not \u003call of your vaults\u003e per month,\nwhich pre-committing requires.\n\n4) On Protocol Design\n\nIt's nice that you can abstract away your protocol design concerns as a\n\"second tier composition check\" v.s. having to modify your protocol to work\nwith a fee bumping thing.\n\nThere are a myriad of ways dynamic txns (e.g. for Eltoo) can lead to RBF\npinning and similar, Sponsor type things allow you to design such protocols\nto not have any native way of paying for fees inside the actual\n\"Transaction Intents\" and use an external system to create the intended\neffect. It seems (to me) more robust that we can prove that a Sponsors\nmechanism allows any transaction -- regardless of covenant stuff, bugs,\npinning, etc -- to move forward.\n\nStill... careful protocol design may permit the use of optimized\nconstructions! For example, in a vault rather than assigning *no fee* maybe\nyou can have a single branch with a reasonable estimated fee. If you are\ncorrect or overshot (let's say 50% chance?) then you don't need to add a\nsponsor. If you undershot, not to worry, just add a sponsor. Adopted\nbroadly, this would cut the expected value of using sponsors by \u003chowever\ngood you are at estimating future fees\u003e. This basically enables all\nprotocols to try to be more efficient, but backstop that with a guaranteed\nto work safe mechanism.\n\n\n\nThere was something else I was going to say but I forgot about it... if it\ncomes to me I'll send a follow up email.\n\nCheers,\n\nJeremy\n\np.s.\n\n\u003e\n\n\n\u003e *Of course this makes for a perfect DoS: it would be trivial for a miner\n\u003e to infer that you are using*\n\u003e *a specific vault standard and guess other leaves and replace the witness\n\u003e to use the highest-feerate*\n\u003e *spending path. You could require a signature from any of the\n\u003e participants. Or, at the cost of an**additional depth, in the tree you\n\u003e could \"salt\" each leaf by pairing it with -say- an OP_RETURN leaf.*\n\n\n\nyou don't need a salt, you just need a unique payout addr (e.g. hardened\nderivation) per revocation txn and you cannot guess the branch.\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\nOn Sat, Mar 12, 2022 at 10:34 AM darosior via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The idea of a soft fork to fix dynamic fee bumping was recently put back\n\u003e on the table. It might\n\u003e sound radical, as what prevents today reasonable fee bumping for contracts\n\u003e with presigned\n\u003e transactions (pinning) has to do with nodes' relay policy. But the\n\u003e frustration is understandable\n\u003e given the complexity of designing fee bumping with today's primitives. [0]\n\u003e Recently too, there was a lot of discussions around covenants. Covenants\n\u003e (conceptually, not talking\n\u003e about any specific proposal) seem to open lots of new use cases and to be\n\u003e desired by (some?) Bitcoin\n\u003e application developers and users.\n\u003e I think that fee bumping using covenants has attractive properties, and it\n\u003e requires a soft fork that\n\u003e is already desirable beyond (trying) to fix fee bumping. However i could\n\u003e not come up with a solution\n\u003e as neat for other protocols than vaults. I'd like to hear from others\n\u003e about 1) taking this route for\n\u003e fee bumping 2) better ideas on applying this to other protocols.\n\u003e\n\u003e\n\u003e In a vault construction you have a UTxO which can only be spent by an\n\u003e Unvaulting transaction, whose\n\u003e output triggers a timelock before the expiration of which a revocation\n\u003e transaction may be confirmed.\n\u003e The revocation transaction being signed in advance (typically before\n\u003e sharing the signature for the\n\u003e Unvault transaction) you need fee bumping in order for the contract to\n\u003e actually be enforceable.\n\u003e\n\u003e Now, with a covenant you could commit to the revocation tx instead of\n\u003e presigning it. And using a\n\u003e Taproot tree you could commit to different versions of it with increasing\n\u003e feerate. Any network\n\u003e monitor (the brooadcaster, a watchtower, ..) would be able to RBF the\n\u003e revocation transaction if it\n\u003e doesn't confirm by spending using a leaf with a higher-feerate transaction\n\u003e being committed to.\n\u003e\n\u003e Of course this makes for a perfect DoS: it would be trivial for a miner to\n\u003e infer that you are using\n\u003e a specific vault standard and guess other leaves and replace the witness\n\u003e to use the highest-feerate\n\u003e spending path. You could require a signature from any of the participants.\n\u003e Or, at the cost of an\n\u003e additional depth, in the tree you could \"salt\" each leaf by pairing it\n\u003e with -say- an OP_RETURN leaf.\n\u003e But this leaves you with a possible internal blackmail for multi-party\n\u003e contracts (although it's less\n\u003e of an issue for vaults, and not one for single-party vaults).\n\u003e What you could do instead is attaching an increasing relative timelock to\n\u003e each leaf (as the committed\n\u003e revocation feerate increases, so does the timelock). You need to be\n\u003e careful to note wreck miner\n\u003e incentives here (see [0], [1], [2] on \"miner harvesting\"), but this\n\u003e enables the nice property of a\n\u003e feerate which \"adapts\" to the block space market. Another nice property of\n\u003e this approach is the\n\u003e integrated anti fee sniping protection if the revocation transaction pays\n\u003e a non-trivial amount of\n\u003e fees.\n\u003e\n\u003e Paying fees from \"shared\" funds instead of a per-watchtower fee-bumping\n\u003e wallet opened up the\n\u003e blackmail from the previous section, but the benefits of paying from\n\u003e internal funds shouldn't be\n\u003e understated.\n\u003e No need to decide on an amount to be refilled. No need to bother the user\n\u003e to refill the fee-bumping\n\u003e wallet (before they can participate in more contracts, or worse before a\n\u003e deadline at which all\n\u003e contracts are closed). No need for a potentially large amount of funds to\n\u003e just sit on a hot wallet\n\u003e \"just in case\". No need to duplicate this amount as you replicate the\n\u003e number of network monitors\n\u003e (which is critical to the security of such contracts).\n\u003e In addition, note how modifying the feerate of the revocation transaction\n\u003e in place is less expensive\n\u003e than adding a (pair of) new input (and output), let alone adding an entire\n\u003e new transaction to CPFP.\n\u003e Aside, and less importantly, it can be made to work with today's relay\n\u003e rules (just use fee thresholds\n\u003e adapted to the current RBF thresholds, potentially with some leeway to\n\u003e account for policy changes).\n\u003e Paying from shared funds (in addition to paying from internal funds) also\n\u003e prevents pervert\n\u003e incentives for contracts with more than 2 parties. In case one of the\n\u003e parties breaches it, all\n\u003e remaining parties have an incentive to enforce the contract.. But only one\n\u003e would otherwise pay for\n\u003e it! It would open up the door to some potential sneaky techniques to wait\n\u003e for another party to pay\n\u003e for the fees, which is at odd with the reactive security model.\n\u003e\n\u003e Let's examine how it could be concretely designed. Say you have a vault\n\u003e wallet software for a setup\n\u003e with 5 participants. The revocation delay is 144 blocks. You assume\n\u003e revocation to be infrequent (if\n\u003e one happens it's probably a misconfigured watchtower that needs be fixed\n\u003e before the next\n\u003e unvaulting), so you can afford infrequent overpayments and larger fee\n\u003e thresholds. Participants\n\u003e assume the vault will be spent within a year and assume a maximum possible\n\u003e feerate for this year of\n\u003e 10ksat/vb.\n\u003e They create a Taproot tree of depth 7. First leaf is the spending path\n\u003e (open to whomever the vault\n\u003e pays after the 144 blocks). Then the leaf `i` for `i` in `[1, 127]` is a\n\u003e covenant to the revocation\n\u003e transaction with a feerate `i * 79` sats/vb and a relative timelock of `i\n\u003e - 1` blocks.\n\u003e Assuming the covenant to the revocation transaction is 33 bytes [3],\n\u003e that's a witness of:\n\u003e     1 + 33     + 1 + 33 + 7 * 32 = 292 WU (73 vb)\n\u003e     ^^^^^^       ^^^^^^^^^^^^^^\n\u003e     witscript     control block\n\u003e for any of the revocation paths. The revocation transaction is 1-input\n\u003e 1-output, so in total it's\n\u003e     10.5 +   41 + 73      + 43    = 167.5 vb\n\u003e     ^^^^    ^^^^^^^^^^^    ^^^^\n\u003e     header  input|witness  output\n\u003e The transaction size is not what you'd necessarily want to optimize for\n\u003e first, still, it is smaller\n\u003e in this case than using other feebumping primitives and has a smaller\n\u003e footprint on the UTxO set. For\n\u003e instance for adding a feebumping input and change output assuming all\n\u003e Taproot inputs and outputs\n\u003e (CPFP is necessarily even larger):\n\u003e     5 * 64 +  1 + 5 * (32 + 1) + 1 + 33 = 520 WU (105 vb)\n\u003e     ^^^^^^    ^^^^^^^^^^^^^^^    ^^^^^^\n\u003e     witness      witscript       control\n\u003e     10.5  +  41 + 105      + 41 + 16.5         + 2 * 43  = 300 vb\n\u003e     ^^^^     ^^^^^^^^        ^^^^^^^^^           ^^^^^^\n\u003e     header   input|witness   fb input|witness    outputs\n\u003e From there, you can afford more depths at the tiny cost of 8 more vbytes\n\u003e each. You might want them\n\u003e for:\n\u003e - more granularity (if you can afford large enough timelocks)\n\u003e - optimizing for the spending path rather than the revocation one\n\u003e - adding a hashlock to prevent nuisance (with the above script a third\n\u003e party could malleate a\n\u003e   spending path into a revocation one). You can use the OP_RETURN trick\n\u003e from above to prevent that.\n\u003e\n\u003e Unfortunately, the timelocked-covenant approach to feebumping only applies\n\u003e to bumping the first\n\u003e transaction of a chain (you can't pay for the parent with a timelock) so\n\u003e for instance it's not\n\u003e usable for HTLC transactions in Lightning to bump the parent commitment\n\u003e tx. The same goes for\n\u003e bumping the update tx in Coinpool.\n\u003e It could be worked around by having a different covenant per participant\n\u003e (paying the fee from either\n\u003e of the participants' output) behind a signature check. Of course it\n\u003e requires funds to already be in\n\u003e the contract (HTLC, Coinpool leaf) to pay for your own unilateral close,\n\u003e but if you don't have any\n\u003e fund in the contract it doesn't make sense to try to feebump it in the\n\u003e first place. The same goes\n\u003e for small amounts: you'd only allocate up to the value of the contract\n\u003e (minus a dust preference) in\n\u003e fees in order to enforce it.\n\u003e This is less nice for external monitors as it requires a private key (or\n\u003e another secret) to be\n\u003e committed to in advance) to be able to bump [4] and does not get rid of\n\u003e the \"who's gonna pay for the\n\u003e enforcement\" issue in \u003e2-parties contracts. Still, it's more optimal and\n\u003e usable than CPFP or adding\n\u003e a pair of input/output for all the reasons mentioned above.\n\u003e\n\u003e\n\u003e Thoughts?\n\u003e Antoine\n\u003e\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019615.html\n\u003e [2]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019627.html\n\u003e [3] That's obviously close to the CTV construction. But using another more\n\u003e flexible (and therefore\n\u003e     less optimized) construction would not be a big deal. It might in fact\n\u003e be necessary for more\n\u003e     elaborated (realistic?) usecases than the simple one detailed here.\n\u003e [4]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html\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/20220312/980f7dcc/attachment-0001.html\u003e"}