Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent

From: Antoine Riard <antoine.riard@gmail•com>
To: Jeremy <jlrubin@mit•edu>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent
Date: Mon, 14 Jun 2021 13:18:38 -0400	[thread overview]
Message-ID: <CALZpt+HEzEvNY4O3TWR_LkPydzGdJFz-=NZ3Qd7mEHL6A=y5_g@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhjSN1LX_8L90UYy-r=sMPCRTonHetxKY4C0f1ghw548SA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

Thanks for this analysis of a sponsor-like mechanism.

For sure, "watchtower friendly" and "post hoc" are really good point
towards sponsorship, at least other proposals are struggling with
watchtower support, at least in way where your watchtower policy doesn't
leak to your counterparties (which is really gross from a security
standpoint when you think about it!)

W.r.t to sponsorship chain/fee overhead (at least compared to
ANYPREVOUT+IOMAP), I think it's ultimately a question of how many contracts
are closed cooperatively-vs-non-coop on the long-term. Even if we can hope
for emergency closure for security reasons to be pretty rare in practice,
we might still have significant non-coop closing when counterparties can't
agree on the economic opportunity of pursuing the contract or not. E.g, a
big LN hub unilaterally closes small channels, either because it doesn't
earn routing fees or those mobile nodes have been offline for too long.

Still, I think the next step of the discussion would be to come up with a
consistent simulation against which we can all agree on and score all the
proposals against it.

Le dim. 13 juin 2021 à 10:16, Jeremy via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> a écrit :

> The API of a sponsor-like mechanism is close to ideal in my opinion:
>
> - compatible with non malleable transactions
> - 0 overhead if fees accurately estimated
> - watchtower friendly
> - post hoc, requires minimal 'protocol awareness'
> - friendly with most mempool eviction policies, not much new required
> - can work to atomically bump multiple txns
> - can be bumped cooperatively by multiple sponsors w/o coordination
> - 0 'rebroadcast overhead' (e.g., for a large batch) leasing to cascading
> retransmission fees for replacement
> - can be piggy backed with other future transactions or protocols (e.g.
> coinjoin)
> - compatible with change being in cold storage
>
> The main drawback is it is chain space - wise less efficient, as an
> additional transaction gets made. However, I think the API benefits
> 'product market fit' over alternative solutions outweigh other concerns,
> and if the 'sponsorship efficiency hypothesis' holds true, then most
> transactions will not require sponsors and therefore the savings of not
> needing to preplan a few bumping mechanism will be more efficient overall
> (efficient market will drive accuracy in estimating fees rather than
> needing to sponsor).
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3555 bytes --]