Hi Peter, > You make a good point that the commitment transaction also needs to be included > in my calculations. But you are incorrect about the size of them.
> With taproot and ephemeral anchors, a typical commitment transaction would have > a single-sig input (musig), two taproot outputs, and an ephemeral anchor > output. Such a transaction is only 162vB, much less than 1000vB. Note that these scenarios are much less interesting for commitment transactions with no HTLC outputs, so 162 isn't what I would use for the minimum. Looking at expected weights in bolt 3 ( https://github.com/lightning/bolts/blob/master/03-transactions.md#expected-weight-of-the-commitment-transaction) with 1 HTLC and anchors, we get (900 + 172 * num-htlc-outputs + 224 weight)/4 = 324vB. So, I apologize for not using a more accurate minimum, though I think this helps illustrate the 100x reduction of v3 a lot better. While I think the true minimum is higher, let's go ahead and use your number N=162vB. - Alice is happy to pay 162sat/vB * (162 + 152vB) = 50,868sat - In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) + 152 = 80,152sat - Mallory succeeds, forcing Alice to pay 80,152 - 50,868 = *29,284sat* more - In a non-v3 world, Mallory can make the cost to replace 80sat/vB * (100,000vB) + 152 = 8,000,152sat - Mallory succeeds, forcing Alice to pay 8,000,152 - 50,868 = *7,949,284sat *more (maxed out by the HTLC amount) As framed above, what we've done here is quantify the severity of the pinning damage in the v3 and non-v3 world by calculating the additional fees Mallory can force Alice to pay using Rule 3. To summarize this discussion, at the lower end of possible commitment transaction sizes, pinning is possible but is restricted by 100x, as claimed. Best, Gloria On Wed, Dec 20, 2023 at 9:11 PM Peter Todd <p...@petertodd.org> wrote: > On Wed, Dec 20, 2023 at 03:16:25PM -0500, Greg Sanders wrote: > > Hi Peter, > > > > Thanks for taking the time to understand the proposal and give thoughtful > > feedback. > > > > With this kind of "static" approach I think there are fundamental > > limitations because > > the user has to commit "up front" how large the CPFP later will have to > be. > > 1kvB > > is an arbitrary value that is two orders of magnitude less than the > > possible package > > size, and allows fairly flexible amounts of inputs(~14 taproot inputs > > IIRC?) to effectuate a CPFP. > > Why would you need so many inputs to do a CPFP if they all have to be > confirmed? The purpose of doing a CPFP is to pay fees to get another > transaction mined. Unless you're in some degenerate, unusual, situation > where > you've somehow ended up with just some dust left in your wallet, dust that > is > barely worth its own fees to spend, one or maybe two UTXOs are going to be > sufficient for a fee payment. > > I had incorrectly thought that V3 transctions allowed for a single up-to > 1000vB > transaction to pay for multiple parents at once. But if you can't do that, > due > to the restriction on unconfirmed inputs, I can't see any reason to have > such a > large limit. > > > I'd like something much more flexible, but we're barely at whiteboard > stage > > for alternatives and > > they probably require more fundamental work. So within these limits, we > > have to pick some number, > > and it'll have tradeoffs. > > > > When I think of "pinning potential", I consider not only the parent size, > > and not > > only the maximum child size, but also the "honest" child size. If the > honest > > user does relatively poor utxo management, or the commitment transaction > > is of very high value(e.g., lots of high value HTLCs), the pin is > > essentially zero. > > If the honest user ever only have one utxo, then the "max pin" is > effective > > indeed. > > Which is the situation you would expect in the vast majority of cases. > > > > Alice would have had to pay a 2.6x higher fee than > > expected. > > > > I think that's an acceptable worst case starting point, versus the status > > quo which is ~500-1000x+. > > No, the status quo is signed anchors, like Lightning already has with > anchor > channels. Those anchors could still be zero-valued. But as long as there > is a > signature associated with them, pinning isn't a problem as only the > intended > party can spend them. > > Note BTW that existing Lightning anchor channels inefficiently use two > anchor > outputs when just one is sufficient: > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004246.html > [Lightning-dev] The remote anchor of anchor channels is redundant > Peter Todd, Dec 13th, 2023 > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
