Small update.

A bit ago I went ahead and implemented ephemeral anchors on top of the V3
proposal to see what the complexity looks like:

Roughly 130 loc excluding tests, using OP_2 instead of OP_TRUE to not camp
the value that is used elsewhere.

Please let me know if you have any early feedback on this!


On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders <> wrote:

> So it doesn't look like I'm ignoring a good question:
> No solid noninteractive ideas, unless we get some very flexible sighash
> softfork. Interactively, I think you can get collaborative fee bumps under
> the current consensus regime and ephemeral anchors. The child will just be
> built with inputs from different people.
> On Wed, Oct 19, 2022 at 11:12 AM James O'Beirne <>
> wrote:
>> I'm also very happy to see this proposal, since it gets us closer to
>> having a mechanism that allows the contribution to feerate in an
>> "unauthenticated" way, which seems to be a very helpful feature for vaults
>> and other contracting protocols.
>> One possible advantage of the sponsors interface -- and I'm curious for
>> your input here Greg -- is that with sponsors, assuming we relaxed the "one
>> sponsor per sponsoree" constraint, multiple uncoordinated parties can
>> collaboratively bump a tx's feerate. A simple example would be a batch
>> withdrawal from an exchange could be created with a low feerate, and then
>> multiple users with a vested interest of expedited confirmation could all
>> "chip in" to raise the feerate with multiple sponsor transactions.
>> Having a single ephemeral output seems to create a situation where a
>> single UTXO has to shoulder the burden of CPFPing a package. Is there some
>> way we could (possibly later) amend the ephemeral anchor interface to allow
>> for this kind of collaborative sponsoring? Could you maybe see "chained"
>> ephemeral anchors that would allow this?
>> On Tue, Oct 18, 2022 at 12:52 PM Jeremy Rubin via bitcoin-dev <
>>> wrote:
>>> Excellent proposal and I agree it does capture much of the spirit of
>>> sponsors w.r.t. how they might be used for V3 protocols.
>>> The only drawbacks I see is they don't work for lower tx version
>>> contracts, so there's still something to be desired there, and that the
>>> requirement to sweep the output must be incentive compatible for the miner,
>>> or else they won't enforce it (pass the buck onto the future bitcoiners).
>>> The Ephemeral UTXO concept can be a consensus rule (see
>>> "Intermediate
>>> UTXO") we add later on in lieu of managing them by incentive, so maybe it's
>>> a cleanup one can punt.
>>> One question I have is if V3 is designed for lightning, and this is
>>> designed for lightning, is there any sense in requiring these outputs for
>>> v3? That might help with e.g. anonymity set, as well as potentially keep
>>> the v3 surface smaller.
>>> On Tue, Oct 18, 2022 at 11:51 AM Greg Sanders via bitcoin-dev <
>>>> wrote:
>>>> > does that effectively mark output B as unspendable once the child
>>>> gets confirmed?
>>>> Not at all. It's a normal spend like before, since the parent has been
>>>> confirmed. It's completely unrestricted, not being bound to any
>>>> V3/ephemeral anchor restrictions on size, version, etc.
>>>> On Tue, Oct 18, 2022 at 11:47 AM Arik Sosman via bitcoin-dev <
>>>>> wrote:
>>>>> Hi Greg,
>>>>> Thank you very much for sharing your proposal!
>>>>> I think there's one thing about the second part of your proposal that
>>>>> I'm missing. Specifically, assuming the scenario of a v3 transaction with
>>>>> three outputs, A, B, and the ephemeral anchor OP_TRUE. If a child
>>>>> transaction spends A and OP_TRUE, does that effectively mark output B as
>>>>> unspendable once the child gets confirmed? If so, isn't the implication
>>>>> therefore that to safely spend a transaction with an ephemeral anchor, all
>>>>> outputs must be spent? Thanks!
>>>>> Best,
>>>>> Arik
>>>>> On Tue, Oct 18, 2022, at 6:52 AM, Greg Sanders via bitcoin-dev wrote:
>>>>> Hello Everyone,
>>>>> Following up on the "V3 Transaction" discussion here
>>>>> , I would like to elaborate a bit further on some potential follow-on work
>>>>> that would make pinning severely constrained in many setups].
>>>>> V3 transactions may solve bip125 rule#3 and rule#5 pinning attacks
>>>>> under some constraints[0]. This means that when a replacement is to be 
>>>>> made
>>>>> and propagated, it costs the expected amount of fees to do so. This is a
>>>>> great start. What's left in this subset of pinning is *package limit*
>>>>> pinning. In other words, a fee-paying transaction cannot enter the mempool
>>>>> due to the existing mempool package it is being added to already being too
>>>>> large in count or vsize.
>>>>> Zooming into the V3 simplified scenario for sake of discussion, though
>>>>> this problem exists in general today:
>>>>> V3 transactions restrict the package limit of a V3 package to one
>>>>> parent and one child. If the parent transaction includes two outputs which
>>>>> can be immediately spent by separate parties, this allows one party to
>>>>> disallow a spend from the other. In Gloria's proposal for ln-penalty, this
>>>>> is worked around by reducing the number of anchors per commitment
>>>>> transaction to 1, and each version of the commitment transaction has a
>>>>> unique party's key on it. The honest participant can spend their version
>>>>> with their anchor and package RBF the other commitment transaction safely.
>>>>> What if there's only one version of the commitment transaction, such
>>>>> as in other protocols like duplex payment channels, eltoo? What about 
>>>>> multi
>>>>> party payments?
>>>>> In the package RBF proposal, if the parent transaction is identical to
>>>>> an existing transaction in the mempool, the parent will be detected and
>>>>> removed from the package proposal. You are then left with a single V3 
>>>>> child
>>>>> transaction, which is then proposed for entry into the mempool. In the 
>>>>> case
>>>>> of another parent output already being spent, this is simply rejected,
>>>>> regardless of feerate of the new child.
>>>>> I have two proposed solutions, of which I strongly prefer the latter:
>>>>> 1) Expand a carveout for "sibling eviction", where if the new child is
>>>>> paying "enough" to bump spends from the same parent, it knocks its sibling
>>>>> out of the mempool and takes the one child slot. This would solve it, but
>>>>> is a new eviction paradigm that would need to be carefully worked through.
>>>>> 2) Ephemeral Anchors (my real policy-only proposal)
>>>>> Ephemeral Anchors is a term which means an output is watermarked as an
>>>>> output that MUST be spent in a V3 package. We mark this anchor by being 
>>>>> the
>>>>> bare script `OP_TRUE` and of course make these outputs standard to relay
>>>>> and spend with empty witness data.
>>>>> Also as a simplifying assumption, we require the parent transaction
>>>>> with such an output to be 0-fee. This makes mempool reasoning simpler in
>>>>> case the child-spend is somehow evicted, guaranteeing the parent will be 
>>>>> as
>>>>> well.
>>>>> Implications:
>>>>> a) If the ephemeral anchor MUST be spent, we can allow *any* value,
>>>>> even dust, even 0, without worrying about bloating the utxo set. We relax
>>>>> this policy for maximum smart contract flexibility and specification
>>>>> simplicity..
>>>>> b) Since this anchor MUST be spent, any spending of other outputs in
>>>>> the same parent transaction MUST directly double-spend prior spends of the
>>>>> ephemeral anchor. This causes the 1 block CSV timelock on outputs to be
>>>>> removed in these situations. This greatly magnifies composability of smart
>>>>> contracts, as now we can do things like safely splice directly into new
>>>>> channels, into statechains, your custodial wallet account, your cold
>>>>> wallet, wherever, without requiring other wallets to support arbitrary
>>>>> scripts. Also it hurts that 1 CSV time locked scripts may not be 
>>>>> miniscript
>>>>> compatible to begin with...
>>>>> c) *Anyone* can bump the transaction, without any transaction key
>>>>> material. This is essentially achieving Jeremy's Transaction Sponsors (
>>>>> proposal without consensus changes. As long as someone gets a fully signed
>>>>> parent, they can execute a bump with minimal wallet tooling. If a
>>>>> transaction author doesn’t want a “sponsor”, do not include the output.
>>>>> d) Lightning Carve-out(
>>>>> is superseded by this logic, as we are not restricted to two immediately
>>>>> spendable output scenarios. In its place, robust multi-party fee bumping 
>>>>> is
>>>>> possible.
>>>>> e) This also benefits more traditional wallet scenarios, as change
>>>>> outputs can no longer be pinned, and RBF/CPFP becomes robust. Payees in
>>>>> simple spends cannot pin you. Batched payouts become a lot less painful.
>>>>> This was one of the motivating use cases that created the term “pinning” 
>>>>> in
>>>>> the first place(
>>>>> even if LN/L2 discussion has largely overtaken it due to HTLC theft risks.
>>>>> Open Question(s):
>>>>>    1.
>>>>>    If we allow non-zero value in ephemeral outputs, does this open up
>>>>>    a MEV we are worried about? Wallets should toss all the value directly 
>>>>> to
>>>>>    fees, and add their own additional fees on top, otherwise miners have
>>>>>    incentive to make the smallest utxo burn transaction to claim those 
>>>>> funds.
>>>>>    They just confirmed your parent transaction anyways, so do we care?
>>>>>    2.
>>>>>    SIGHASH_GROUP like constructs would allow uncommitted ephemeral
>>>>>    anchors to be added at spend time, depending on spending requirements.
>>>>>    SIGHASH_SINGLE already allows this.
>>>>> Hopefully this gives people something to consider as we move forward
>>>>> in thinking about mempool design within the constraints we have today.
>>>>> Greg
>>>>> 0: With V3 transactions where you have "veto power" over all the
>>>>> inputs in that transaction. Therefore something like ANYONECANPAY is still
>>>>> broken. We need a more complex solution, which I’m punting for the sake of
>>>>> progress.
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>> _______________________________________________
>>> bitcoin-dev mailing list
bitcoin-dev mailing list

Reply via email to