On 10/20/23 7:43 PM, Peter Todd wrote:
On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote:
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.
We are talking about storing ephemeral data here, HTLC transactions and
possibly commitment transactions. Since lightning uses disclosed secrets to
invalidate old state, you do not need to keep every signature from your
counterparty indefinitely.
Mmm, fair point, yes.
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.
Since SIGHASH_SINGLE requires one output per input, the savings you get by
combining multiple SIGHASH_SINGLE transactions together aren't very
significant. Just 18 bytes for nVersion, nLockTime, and the txin and txout size
fields. The HTLC-timeout transaction is 166.5 vBytes, so that's a savings of
just 11%
Yep, its not a lot, but for a thing that's inherently super chain-spammy, its
still quite nice.
Of course, if you _do_ need to fee bump and add an additional input, that input
takes up space, and you'll probably need a change output. At which point you
again would probably have been better off with a pre-signed transaction.
You are also assuming there's lots of HTLC's in flight that need to be spent.
That's very often not the case.
In general, yes, in force-close cases often there's been some failure which is repeated in several
HTLCs :).
More generally, I think we're getting lost here - this isn't really a material change for
lightning's trust model - its already the case that a peer that is willing to put a lot of work in
can probably steal your money, and there's now just one more way they can do that. We really don't
need to rush to "fix lightning" here, we can do it right and fix it at the ecosystem level. It
shouldn't be the case that a policy restriction results in both screwing up a L2 network *and*
results in miners getting paid less. That's a policy bug.
Matt
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
