Hello again dev, Due to the interest in the proposal and the prodding of certain folks, I've written up a short draft BIP of the Ephemeral Anchors idea here: https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki
The pull request at https://github.com/bitcoin/bitcoin/pull/26403 has been refreshed on top of the latest V3 proposal, but the BIP itself is unaffected. Cheers, Greg On Wed, Nov 30, 2022 at 10:32 AM Greg Sanders <gsander...@gmail.com> wrote: > 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: > https://github.com/bitcoin/bitcoin/pull/26403 > > 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! > > Greg > > On Thu, Oct 20, 2022 at 9:42 AM Greg Sanders <gsander...@gmail.com> 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 <james.obei...@gmail.com> >> 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 < >>> bitcoin-dev@lists.linuxfoundation.org> 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 >>>> https://rubin.io/public/pdfs/multi-txn-contracts.pdf "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 < >>>> bitcoin-dev@lists.linuxfoundation.org> 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 < >>>>> bitcoin-dev@lists.linuxfoundation.org> 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 >>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html >>>>>> , 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 ( >>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html) >>>>>> 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( >>>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html) >>>>>> 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( >>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html), >>>>>> 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@lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> bitcoin-dev mailing list >>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>> >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
