From: darosior <darosior@protonmail•com>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
Date: Fri, 28 May 2021 22:25:16 +0000 [thread overview]
Message-ID: <v4UrF63P8_Mvu9QiyP4bK6zkfHpmLR0eT2gfckNnvA8cNjRr6hcCZMenJid7lNtUQgtI2NcxjfHuvgmRXCp0WQMqCh_Nwo2Xx7nHESvgogY=@protonmail.com> (raw)
In-Reply-To: <CALZpt+G3cVam9oJRHA=11j9k7k4Fo99dP39P4pbWeHfh79Xs-g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]
> 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.
[-- Attachment #2: Type: text/html, Size: 3185 bytes --]
next prev parent reply other threads:[~2021-05-28 22:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-27 20:14 Antoine Riard
2021-05-27 21:45 ` darosior
2021-05-28 4:13 ` Antoine Riard
2021-05-28 22:25 ` darosior [this message]
2021-06-10 21:16 ` Antoine Riard
2021-06-10 13:18 ` darosior
2021-06-07 2:27 ` Lloyd Fournier
2021-06-10 21:45 ` Antoine Riard
2021-06-10 22:47 ` darosior
2021-06-13 5:56 ` Lloyd Fournier
2021-06-13 14:16 ` Jeremy
2021-06-14 17:18 ` Antoine Riard
2021-06-14 16:46 ` Antoine Riard
2021-06-15 0:59 ` Lloyd Fournier
2021-06-15 3:08 ` Lloyd Fournier
2021-07-08 11:17 ` Anthony Towns
2021-07-09 13:19 ` Antoine Riard
2021-07-10 1:47 ` Anthony Towns
2021-07-12 0:02 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='v4UrF63P8_Mvu9QiyP4bK6zkfHpmLR0eT2gfckNnvA8cNjRr6hcCZMenJid7lNtUQgtI2NcxjfHuvgmRXCp0WQMqCh_Nwo2Xx7nHESvgogY=@protonmail.com' \
--to=darosior@protonmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox