From: Matt Corallo <lf-lists@mattcorallo•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
security@ariard•me,
"lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org"
<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
Date: Fri, 20 Oct 2023 21:55:12 -0400 [thread overview]
Message-ID: <c7ca9861-0734-4065-851a-8af9cabd7e87@mattcorallo.com> (raw)
In-Reply-To: <ZTModpNyIQ3qFFI3@petertodd.org>
On 10/20/23 9:25 PM, Peter Todd wrote:
> On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote:
>>> What are anchor outputs used for other than increasing fees?
>>>
>>> Because if we've pre-signed the full fee range, there is simply no need for
>>> anchor outputs. Under any circumstance we can broadcast a transaction with a
>>> sufficiently high fee to get mined.
>>
>>
>> Indeed, that is what anchor outputs are for. Removing the pre-set feerate
>> solved a number of issues with edge-cases and helped address the
>> fee-inflation attack. Now, just using pre-signed transactions doesn't have
>> to re-introduce those issues - as long as the broadcaster gets to pick which
>> of the possible transactions they broadcast its just another transaction of
>> theirs.
>>
>> Still, I'm generally really dubious of the multiple pre-signed transaction
>> thing, (a) it would mean more fee overhead (not the end of the world for a
>> force-closure, but it sucks to have all these individual transactions
>> rolling around and be unable to batch), but more importantly (b) its a bunch
>> of overhead to keep track of a ton of variants across a sufficiently
>> granular set of feerates for it to not result in substantially overspending
>> on fees.
>
> Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
> lightning where the transaction form is deterministically derived, signing 100
> extra transactions requires just 6400 extra bytes. Even a very slow 100KB/s
> connection can transfer that in 64ms; latency will still dominate.
Lightning today isn't all that much data, but multiply it by 100 and we start racking up data enough
that people may start to have to store a really material amount of data for larger nodes and dealing
with that starts to be a much bigger pain then when we're talking about a GiB or twenty.
> RBF has a minimum incremental relay fee of 1sat/vByte by default. So if you use
> those 100 pre-signed transaction variants to do nothing more than sign every
> possible minimum incremental relay, you've covered a range of 1sat/vByte to
> 100sat/vByte. I believe that is sufficient to get mined for any block in
> Bitcoin's entire modern history.
>
> CPFP meanwhile requires two transactions, and thus extra bytes. Other than edge
> cases with very large transactions in low-fee environments, there's no
> circumstance where CPFP beats RBF.
What I was referring to is that if we have the SIGHASH_SINGLE|ANYONECANPAY we can combine many HTLC
claims into one transaction, vs pre-signing means we're stuck with a ton of individual transactions.
Matt
next prev parent reply other threads:[~2023-10-21 1:55 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-16 16:57 [bitcoin-dev] " Antoine Riard
2023-10-16 19:13 ` Peter Todd
2023-10-16 22:10 ` Matt Morehouse
2023-10-17 1:11 ` Antoine Riard
2023-10-20 10:47 ` Peter Todd
2023-10-20 11:18 ` Jochen Hoenicke
2023-10-16 22:51 ` Olaoluwa Osuntokun
2023-10-17 7:21 ` [bitcoin-dev] [Lightning-dev] " ziggie1984
2023-10-17 10:34 ` ZmnSCPxj
2023-10-17 18:34 ` Antoine Riard
2023-10-20 10:31 ` Peter Todd
2023-10-20 11:03 ` Peter Todd
2023-10-20 18:35 ` Matt Morehouse
2023-10-20 21:05 ` Matt Corallo
2023-10-21 0:15 ` Peter Todd
2023-10-21 1:03 ` Matt Corallo
2023-10-21 1:25 ` Peter Todd
2023-10-21 1:55 ` Matt Corallo [this message]
2023-10-21 2:43 ` Peter Todd
2023-10-23 16:09 ` Matt Corallo
2023-10-17 17:47 ` Antoine Riard
2023-10-17 18:47 ` Antoine Riard
2023-10-18 0:17 ` Matt Corallo
2023-10-18 2:57 ` Antoine Riard
2023-10-19 8:12 ` Bastien TEINTURIER
2023-10-19 16:23 ` Matt Morehouse
2023-10-19 17:22 ` Antoine Riard
2023-10-19 17:53 ` Matt Morehouse
2023-10-19 19:33 ` Antoine Riard
2023-10-21 0:18 ` Olaoluwa Osuntokun
2023-11-17 22:36 ` Antoine Riard
2023-10-19 18:02 ` Matt Corallo
2023-10-20 6:56 ` [bitcoin-dev] " Antoine Riard
2023-10-21 20:05 ` Antoine Riard
2023-10-27 0:43 ` Peter Todd
2023-11-02 4:46 ` Antoine Riard
2023-10-21 0:09 ` [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely Peter Todd
2023-10-21 8:58 ` David A. Harding
2023-10-21 10:31 ` Peter Todd
2023-10-22 8:30 ` vjudeu
2023-10-23 11:10 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-10-23 15:45 ` Peter Todd
2023-11-02 5:24 ` [bitcoin-dev] " Antoine Riard
2023-11-02 6:26 ` Peter Todd
2023-11-02 17:07 ` Matt Morehouse
2023-11-03 5:27 ` Antoine Riard
2023-11-03 5:25 ` Antoine Riard
2023-11-04 7:26 ` Peter Todd
2023-11-06 18:45 ` Antoine Riard
2023-11-07 11:11 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-11-07 15:44 ` Antoine Riard
2023-11-08 0:51 ` [bitcoin-dev] " Peter Todd
2023-11-08 2:06 ` Peter Todd
2023-11-13 2:18 ` Antoine Riard
2023-11-14 19:50 ` Peter Todd
[not found] ` <CALZpt+H38cU9L8kq0mSYCDirzL39fxhdoz4pAPiS8dGJP8akKg@mail.gmail.com>
2023-11-15 17:53 ` [bitcoin-dev] Fwd: " Antoine Riard
2023-10-22 4:49 ` [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Nadav Ivgi
2023-10-23 8:49 ` David A. Harding
2023-10-21 14:21 [bitcoin-dev] [Lightning-dev] " Nagaev Boris
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=c7ca9861-0734-4065-851a-8af9cabd7e87@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
--cc=security@ariard$(echo .)me \
/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