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.

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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

Attachment: signature.asc
Description: PGP signature

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to