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