Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
On Tue, 15 Jun 2021 at 02:47, Antoine Riard wrote: > > This makes a lot of sense as it matches the semantics of what we are > trying > to achieve: allow the owner of an output (whether an individual or group) > to reduce that output's value to pay a higher fee. > > Note, I think you're still struggling with some trust issue that anchor > upgrade is at least eliminating for LN, namely the pre-agreement among a > group of signers about the effective feerate to use at some unknown time > point in the future. If you authorize your counterparty for a broadcast at > feerate X, how do you prevent a broadcast at feerate Y, where Y is far > under X, thus maliciously burning a lot of your fee-bumping reserve ? > > Of course, one mitigation is to make a contribution to a common > fee-bumping output reserve proportional to what has been contributed as a > funding collateral. Thus disincentivizing misuse of the common fee-bumping > reserve in a game-theoretical way. But if you take the example of a LN > channel, you're now running into another issue. Off-chain balances might > fluctuate in a way that most of the time, your fee-bumping reserve > contribution is out-of-proportion with your balance amounts to protect ? > And as such enduring some significant timevalue bleeding on your > fee-bumping reserve. > > Single-party managed fee-bumping reserve doesn't seem to suffer from this > drawback ? > I claim that what I am suggesting is a single-party managed fee-bumping system that solves all fee-bumping requirements of lightning without needing external utxos and without additional interaction or fee pre-agreement between parties. On the commit tx you have your balance going exclusively towards you which you can unilaterally reduce to increase the fee up to whatever threshold you want. With a HTLC or PTLC you also always have a tx with an output that you can unilaterally drain to bump fee (either the hltc-success or htlc-timeout). Are you saying that there are protocols where this would require pre-arrangement or are you saying that it would require pre-arrangement in lightning for some reason I don't see? To further emphasise the generality of this idea you can easily imagine a world where this is enabled on all Bitcoin transactions (of course you have to stomach tx malleability -- a bit more palatable with ANYPREVOUT everywhere). Even for a normal wallet-to-wallet payment the receiver could efficiently increase the tx fee by making a signature under the key of their output and replacing the original tx without interacting with the sender who actually provided the funds for the payment. Cheers, LL ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
Thanks for this analysis of a sponsor-like mechanism. For sure, "watchtower friendly" and "post hoc" are really good point towards sponsorship, at least other proposals are struggling with watchtower support, at least in way where your watchtower policy doesn't leak to your counterparties (which is really gross from a security standpoint when you think about it!) W.r.t to sponsorship chain/fee overhead (at least compared to ANYPREVOUT+IOMAP), I think it's ultimately a question of how many contracts are closed cooperatively-vs-non-coop on the long-term. Even if we can hope for emergency closure for security reasons to be pretty rare in practice, we might still have significant non-coop closing when counterparties can't agree on the economic opportunity of pursuing the contract or not. E.g, a big LN hub unilaterally closes small channels, either because it doesn't earn routing fees or those mobile nodes have been offline for too long. Still, I think the next step of the discussion would be to come up with a consistent simulation against which we can all agree on and score all the proposals against it. Le dim. 13 juin 2021 à 10:16, Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > The API of a sponsor-like mechanism is close to ideal in my opinion: > > - compatible with non malleable transactions > - 0 overhead if fees accurately estimated > - watchtower friendly > - post hoc, requires minimal 'protocol awareness' > - friendly with most mempool eviction policies, not much new required > - can work to atomically bump multiple txns > - can be bumped cooperatively by multiple sponsors w/o coordination > - 0 'rebroadcast overhead' (e.g., for a large batch) leasing to cascading > retransmission fees for replacement > - can be piggy backed with other future transactions or protocols (e.g. > coinjoin) > - compatible with change being in cold storage > > The main drawback is it is chain space - wise less efficient, as an > additional transaction gets made. However, I think the API benefits > 'product market fit' over alternative solutions outweigh other concerns, > and if the 'sponsorship efficiency hypothesis' holds true, then most > transactions will not require sponsors and therefore the savings of not > needing to preplan a few bumping mechanism will be more efficient overall > (efficient market will drive accuracy in estimating fees rather than > needing to sponsor). > > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
> This makes a lot of sense as it matches the semantics of what we are trying to achieve: allow the owner of an output (whether an individual or group) to reduce that output's value to pay a higher fee. Note, I think you're still struggling with some trust issue that anchor upgrade is at least eliminating for LN, namely the pre-agreement among a group of signers about the effective feerate to use at some unknown time point in the future. If you authorize your counterparty for a broadcast at feerate X, how do you prevent a broadcast at feerate Y, where Y is far under X, thus maliciously burning a lot of your fee-bumping reserve ? Of course, one mitigation is to make a contribution to a common fee-bumping output reserve proportional to what has been contributed as a funding collateral. Thus disincentivizing misuse of the common fee-bumping reserve in a game-theoretical way. But if you take the example of a LN channel, you're now running into another issue. Off-chain balances might fluctuate in a way that most of the time, your fee-bumping reserve contribution is out-of-proportion with your balance amounts to protect ? And as such enduring some significant timevalue bleeding on your fee-bumping reserve. Single-party managed fee-bumping reserve doesn't seem to suffer from this drawback ? Otherwise, I think your new construction OP_PUSH_TAPROOT_OUTPUT_KEY is correct and solves the O(log(n)) tapleaves issue. Le dim. 13 juin 2021 à 01:57, Lloyd Fournier a écrit : > On Fri, 11 Jun 2021 at 07:45, Antoine Riard > wrote: > >> Hi Lloyd, >> >> Thanks for this tx mutation proposal extending the scope of fee-bumping >> techniques. IIUC, the serves as a pointer to increase the >> output amount by value to recover the recompute the transaction hash >> against which the original signature is valid ? >> > > Right. > > >> Let's do a quick analysis of this scheme. >> * onchain footprint : one tapleaf per contract participant, with O(log n) >> increase of witness size, also one output per contract participant >> > > Yes but we can fix this (see below). > > * tx-relay bandwidth rebroadcast : assuming aforementioned in-place >> mempool substitution policy, the mutated transaction >> > * batching : fee-bumping value is extract from contract transaction >> itself, so O(n) per contract >> * mempool flexibility : the mutated transaction >> * watchtower key management : to enable outsourcing, the mutating key >> must be shared, in theory enabling contract value siphoning to miner fees ? >> > > Yes. You could use OP_LESSTHAN to make sure the value being deducted by > the watchtower is not above a threshold. > > >> Further, I think tx mutation scheme can be achieved in another way, with >> SIGHASH_ANYAMOUNT. A contract participant tapscript will be the following : >> >> >> >> Where is committed with SIGHASH_ANYAMOUNT, blanking >> nValue of one or more outputs. That way, the fee-to-contract-value >> distribution can be unilaterally finalized at a later time through the >> finalizing key [0]. >> > > Yes, that's also a way to do it. I was trying to preserve the original > external key signature in my attempt but this is probably not necessary. L2 > protocols could just exchange two signatures instead. One optimistic one on > the external key and one pessimistic SIGHASH_ANYAMOUNT one on the > . > > >> Note, I think that the tx mutation proposal relies on interactivity in >> the worst-case scenario where a counterparty wants to increase its >> fee-bumping output from the contract balance. This interactivity may lure a >> counterparty to alway lock the worst-case fee-bumping reserve in the >> output. I believe anchor output enables more "real-time" fee-bumping >> reserve adjustment ? >> > > Hmmm well I was hoping that you wouldn't need interaction ever. I can see > that my commitment TX example was too contrived because it has balance > outputs that go exclusively to one party. > Let's take a better example: A PTLC output with both timeout and success > pre-signed transactions spending from it. We must only let the person > offering the PTLC reduce the output of the timeout tx and the converse for > the success tx. > Note very carefully that if we naively apply OP_CHECKSIG_MUTATED or > SIGHASH_ANYAMOUNT with one tapleaf for each party then we risk one party > being able to lower the other party's output by doing a switcharoo on the > tapleaf after they see the signature for their counterparty's tx in the > mempool. In your example you could fix it by having a different > but this means we can't compress by just > using the taproot internal/external key. > > What about this: Instead of party specific "finalizing_alice_key" or > p1-fee-bump-key as I denoted it, we just use the key of the output whose > value we are reducing. This also solves the O(log(n)) tapleaves for > OP_CHECKSIG_MUTATED approach as well -- just have one tapleaf for fee > bumping but authorize it under the key of the output we are reducing. Thus > we need
[bitcoin-dev] Reminder: Transaction relay workshop on IRC Libera - Tuesday 15th June 19:00 UTC
Hi, A short reminder about the 1st transaction relay workshop happening tomorrow on #l2-onchain-support Libera chat (!), Tuesday 15th June, from 19:00 UTC to 20:30 UTC Scheduled topics are: * "Guidelines about L2 protocols onchain security design" * "Coordinated cross-layers security disclosures" * "Full-RBF proposal" Find notes and open questions for the two first topics here: * https://github.com/ariard/L2-zoology/blob/master/workshops/guidelines.md * https://github.com/ariard/L2-zoology/blob/master/workshops/coordinated.md Going to send the "Move toward full-rbf" proposal soon, deserves its own thread. Workshops will stick to a socratic format to foster as much knowledge sharing among attendees and ideally we'll reach rough consensus about expected goals. If you're a second-layer protocol designer, a Lightning dev, a Bitcoin Core dev contributing around mempool/p2p areas, or a Bitcoin service operator with intense usage of the mempool, I hope you'll find those workshops of interest and you'll learn a lot :) Again it's happening on Libera, not Freenode, contrary to the former mail about agenda & schedule. Cheers, Antoine ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
