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. Per channel, with the above numbers, you'd need <10KB worth of extra signatures to fee bump the current commitment (with pre-signed txs), and if HTLCs happen to be in flight, say <10KB of extra signatures per HTLC. Amazon AWS charges $0.125/GB/month for their most expensive SSD volumes. Let's round that up to $1/GB/month to account for RAID and backups. Let's say each channel constantly has 483 HTLC's in flight, and each HTLC is associated with ~10KB of extra data for pre-signed transactions. That's ~5MB/channel of data you constantly need to store, or $0.005/month. In what world is that too expensive or too much of a pain to deal with? If you're node is actually that busy, you're probably making that cost back per channel every minute, or better. > > 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% 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. -- https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
