{"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-06-10\n📝 Original message:\u003e So something like\n`or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))` with each `or`\nin their own leaf? I think it works, but only if the keys `A`, `B`, `C` are\n\"hot\", as in available to the\nfee-bumper. For Revault it means introducing a key for each watchtower in\nthe vaults descriptors, which is meh but technically feasible since they\nare identified. This kinda break our replication\nmodel though. On the other end for Lightning... You'd need to know what\nwatchtower (or your node) is going to be willing to feebump? The descriptor\ncan very quickly get very convoluted:\n`or(and(pk(FB),pk(A_NODE)),and(pk(FB),pk(A_WT1)),and(pk(FB),pk(A_WT2)),and(pk(FB),pk(B_NODE)),and(pk(FB),pk(B_WT1)),and(pk(FB),pk(B_WT2)))`\nfor only 2 participants in a channel\nwhere one of either the node or two watchtowers (identified beforehand !!)\ncan feebump.\n\nI'm not sure if we agree on the purpose of the finalizing key ? Its goal is\nto finalize the transaction state once another fee-bumping input has been\nattached and should be part of the witnessScript of the \"main\" input. If a\nthird-party try to attach a malicious pinning input, doing so breaks the\nfinalizing signature and the transaction will be rejected as invalid by\nnetwork mempools.\n\nThis key doesn't secure funds and as such can be shared to any fee-bumper\nentity (contract source, sourced towers, outsourced towers ?). Of course,\nit means an outsourced tower can re-introduce malicious transaction\nmalleability but at least it's moving away malleability from the\ncontract-level and it's now a holder tower policy decision ?\n\nOverall I agree any fee-bumping techniques comparison should also account\ntower key management complexity (and this one was missing).\n\n\u003e Yes. That's a bit concerning, but i guess it's a tradeoff. Amusingly the\nincentive is at odds with routing: you want to keep your channels\nunbalanced if you run on fractional fee-bumping reserves\nso that if things go south you can still salvage most of your funds by\nfocusing your fee-bumping on the unbalanced (to you) channels :p .\n\nThat's a good point! Switching to anchor now rebalances a security matter,\nnot sure if it was an intended effect of the design :) Also, you might take\nHTLC forwarding acceptance decisions holistically instead of a per-channel\nlevel. If your number of HTLC in-flight expressed as outputs on one\ncommitment transaction goes up, don't accept anymore HTLC on other\nchannels, otherwise, you might run short of fee-bumping reserve...\n\nLe ven. 28 mai 2021 à 18:25, darosior \u003cdarosior at protonmail.com\u003e a écrit :\n\n\u003e\n\u003e Oh yes, I should have mentioned this pinning vector. The witnessScript\n\u003e I've in mind to make secure that type of chain of transactions would be one\n\u003e MuSig key for all contract participants, where signature are committed with\n\u003e SIGHASH_ANYPREVOUT | SIGHASH_IOMAP, one pubkey per participant to lockdown\n\u003e the transaction with SIGHASH_ALL. I think it works and prevents malicious\n\u003e in-flight attachment of input/output to a multi-party transaction ?\n\u003e\n\u003e\n\u003e So something like\n\u003e `or(and(pk(FB),pk(A)),and(pk(FB),pk(B)),and(pk(FB),pk(C)))` with each `or`\n\u003e in their own leaf? I think it works, but only if the keys `A`, `B`, `C` are\n\u003e \"hot\", as in available to the\n\u003e fee-bumper. For Revault it means introducing a key for each watchtower in\n\u003e the vaults descriptors, which is meh but technically feasible since they\n\u003e are identified. This kinda break our replication\n\u003e model though. On the other end for Lightning... You'd need to know what\n\u003e watchtower (or your node) is going to be willing to feebump? The descriptor\n\u003e can very quickly get very convoluted:\n\u003e `or(and(pk(FB),pk(A_NODE)),and(pk(FB),pk(A_WT1)),and(pk(FB),pk(A_WT2)),and(pk(FB),pk(B_NODE)),and(pk(FB),pk(B_WT1)),and(pk(FB),pk(B_WT2)))`\n\u003e for only 2 participants in a channel\n\u003e where one of either the node or two watchtowers (identified beforehand !!)\n\u003e can feebump.\n\u003e\n\u003e I see, so you spread your bumping UTXO pool in two ranges : at least one\n\u003e bumping utxo per contract, and a subpool of emergency smaller coins, ready\n\u003e to be attached on any contract. I think this strategy makes sense for\n\u003e vaults as you can afford a bunch of small coins at different feerates,\n\u003e spending the ones not used afterwards. And higher cells of feerate reserve\n\u003e as the worst historical feerate are relatively not that much compared to\n\u003e locked-in vaults value. That said, I'm more dubious about LN, where node\n\u003e operators might not keep the worst-case fee-bumping reserve, as the time\n\u003e value of the coins aren't worth the channel liquidity at stake.\n\u003e\n\u003e\n\u003e Yes. That's a bit concerning, but i guess it's a tradeoff. Amusingly the\n\u003e incentive is at odds with routing: you want to keep your channels\n\u003e unbalanced if you run on fractional fee-bumping reserves\n\u003e so that if things go south you can still salvage most of your funds by\n\u003e focusing your fee-bumping on the unbalanced (to you) channels :p .\n\u003e\n\u003e Yes, input-based bumping targeting the tail of the chain works at the\n\u003e transaction level. But if you assume bounded visibility of network\n\u003e mempools, one of your counterparties might have broadcast a concurrent\n\u003e state, thus making your CPFP irrelevant for propagation. Though smarter\n\u003e tx-relay techniques such as \"attach-on-contract-utxo-root\" CPFP (or also\n\u003e known as \"blinded CPFP\") might solve this issue.\n\u003e\n\u003e\n\u003e Oh, yes, good point.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210610/19a75ce7/attachment-0001.html\u003e"}