{"type":"rich","version":"1.0","title":"Antoine Riard [ARCHIVE] wrote","author_name":"Antoine Riard [ARCHIVE] (npub1vj…4x8dd)","author_url":"https://yabu.me/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-05-28\n📝 Original message:\u003e Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just\nattach an output paying immediately to me, and construct a tx chain\nspending it). We are using ACP | ALL for Revault,\n\u003e which is the reason why we need a well laid-out pool of fee-bumping UTXOs\n(as you need to consume them entirely).\n\nOh yes, I should have mentioned this pinning vector. The witnessScript I've\nin mind to make secure that type of chain of transactions would be one\nMuSig key for all contract participants, where signature are committed with\nSIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one pubkey per participant to lockdown\nthe transaction with SIGHASH_ALL. I think it works and prevents malicious\nin-flight attachment of input/output to a multi-party transaction ?\n\n\u003e I believe that it's better to broadcast a single fan-out transaction\ncreating your entire UTXO pool in advance. You could create one coin per\ncontract you are watching which value would be\n\u003e used to bump your transaction feerate from the presigned one to -say- the\naverage feerate over the past month, and then have smaller coins that you\ncould attach to any transaction to bump\n\u003e by a certain threshold (say, 10sat/vbyte). You would create as many small\ncoin as your reserve algorithm tells you (which could be \"i need to be\nable, worst case, to close all my contracts\n\u003e with the worst historical feerate.\" or (fractional reserve version) \"i\nneed to be able, worst case, to close 10% of my contracts at the average\nfeerate of the past year, the remaining ones sorry\n\u003e for my loss\"). [1]\n\n\u003e This method is both much more optimal (though you need to sometimes incur\nthe cost of many small additional inputs) and also makes sure that your\nfeebump does not depend on the confirmation of a first stage transaction\n(as you can only RBF with new inputs if they are confirmed).\n\nI see, so you spread your bumping UTXO pool in two ranges : at least one\nbumping utxo per contract, and a subpool of emergency smaller coins, ready\nto be attached on any contract. I think this strategy makes sense for\nvaults as you can afford a bunch of small coins at different feerates,\nspending the ones not used afterwards. And higher cells of feerate reserve\nas the worst historical feerate are relatively not that much compared to\nlocked-in vaults value. That said, I'm more dubious about LN, where node\noperators might not keep the worst-case fee-bumping reserve, as the time\nvalue of the coins aren't worth the channel liquidity at stake.\n\n\u003e Why not just attaching it at the tail of the chain? Bumping the last\nchild with additional input would effectively be a CPFP for the entire\nchain in this case.\n\nYes, input-based bumping targeting the tail of the chain works at the\ntransaction level. But if you assume bounded visibility of network\nmempools, one of your counterparties might have broadcast a concurrent\nstate, thus making your CPFP irrelevant for propagation. Though smarter\ntx-relay techniques such as \"attach-on-contract-utxo-root\" CPFP (or also\nknown as \"blinded CPFP\") might solve this issue.\n\nLe jeu. 27 mai 2021 à 17:45, darosior \u003cdarosior at protonmail.com\u003e a écrit :\n\n\u003e Hi,\n\u003e\n\u003e ## Input-Based\n\u003e\n\u003e I think input-based fee-bumping has been less studied as fee-bumping\n\u003e primitive for L2s [1]. One variant of input-based fee-bumping usable today\n\u003e is the leverage of the SIGHASH_ANYONECANPAY/SIGHASH_SINGLE malleability\n\u003e flags. If the transaction is the latest stage of the contract, a bumping\n\u003e input can be attached just-in-time, thus increasing the feerate of the\n\u003e whole package.\n\u003e\n\u003e\n\u003e Unfortunately, ACP | SINGLE is trivially pinable [0] (TL;DR: i can just\n\u003e attach an output paying immediately to me, and construct a tx chain\n\u003e spending it). We are using ACP | ALL for Revault,\n\u003e which is the reason why we need a well laid-out pool of fee-bumping UTXOs\n\u003e (as you need to consume them entirely).\n\u003e\n\u003e Input-based (today): If the bumping utxo is offering an adequate feerate\n\u003e point in function of network mempools congestion at time of broadcast, only\n\u003e 1 input. If a preliminary fan-out transaction to adjust feerate point must\n\u003e be broadcasted first, 1 input and 2 outputs more must be accounted for.\n\u003e Onchain footprint: 2 inputs + 3 outputs.\n\u003e\n\u003e\n\u003e I believe that it's better to broadcast a single fan-out transaction\n\u003e creating your entire UTXO pool in advance. You could create one coin per\n\u003e contract you are watching which value would be\n\u003e used to bump your transaction feerate from the presigned one to -say- the\n\u003e average feerate over the past month, and then have smaller coins that you\n\u003e could attach to any transaction to bump\n\u003e by a certain threshold (say, 10sat/vbyte). You would create as many small\n\u003e coin as your reserve algorithm tells you (which could be \"i need to be\n\u003e able, worst case, to close all my contracts\n\u003e with the worst historical feerate.\" or (fractional reserve version) \"i\n\u003e need to be able, worst case, to close 10% of my contracts at the average\n\u003e feerate of the past year, the remaining ones sorry\n\u003e for my loss\"). [1]\n\u003e\n\u003e This method is both much more optimal (though you need to sometimes incur\n\u003e the cost of many small additional inputs) and also makes sure that your\n\u003e feebump does not depend on the confirmation\n\u003e of a first stage transaction (as you can only RBF with new inputs if they\n\u003e are confirmed).\n\u003e\n\u003e Input-based (today): In case of rebroadcast, the fee-bumping input is\n\u003e attached to the root of the chain of transactions and as such breaks the\n\u003e chain validity in itself. Beyond the rebroadcast of the updated root under\n\u003e replacement policy, the remaining transactions must be updated and\n\u003e rebroadcast. Rebroadcast footprint: the whole chain of transactions.\n\u003e\n\u003e\n\u003e Why not just attaching it at the tail of the chain? Bumping the last child\n\u003e with additional input would effectively be a CPFP for the entire chain in\n\u003e this case.\n\u003e\n\u003e\n\u003e Thanks for starting this discussion :)\n\u003e Antoine\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html\n\u003e [1] Credits to Jacob Swambo, who came up with the single fan-out\n\u003e transaction and with whom i'm discussing how to practically apply these\n\u003e ideas to Revault.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210528/00cce027/attachment.html\u003e"}