rich1.0Hampus Sjöberg [ARCHIVE] (npub10u…hln8t)https://yabu.me/npub10uzud4rf4636awmfgvarmcfndcmdnv8rfd2y3rx2sqgckv9zur4qahln8tnjumphttps://yabu.me📅 Original date posted:2022-04-25 📝 Original message:Hi pushd. Would you mind clarifying what you mean by BIP118 being a premature idea? SIGHASH_ANYPREVOUT, or SIGHASH_NOINPUT, as it was called back then, was first proposed in the original Lightning Network whitepaper back in 2015. It has been discussed on and off for many years now. I would not call it a premature idea. Now, the revised "Taprooted" version called ANYPREVOUT is a couple of years old, so going with the NOINPUT version could be a safer bet (though that's a bit ridiculous in my opinion). Regarding that you do not find use-cases interesting. That's all fine I suppose, but in the Lightning Network scene, I think it's fair to say that there's widespread enthusiasm in getting a working eltoo solution, which necessitates something like NOINPUT/ANYPREVOUT. And even if eltoo wouldn't happen, enabling spacechains, covenants and blind statechains seem like sufficient use-cases to me. Cheers Hampus On Fri, Apr 22, 2022 at 9:32 PM pushd via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > I would like to know people's sentiment about doing (a very slightly > tweaked version of) BIP118 in place of (or before doing) BIP119. > > > NACK for the below reasons: > > - Premature idea > - I do not find use cases interesting > - We are still in research phase of implementing covenants in bitcoin and > looking for the best proposal > - Taproot soft fork was recently activated and its too soon > - Not enough documentation available > - Could not find any pull request in core for BIP 118 that can be reviewed > - Not enough tools available for testing > > > pushd > --- > > parallel lines meet at infinity? > > ------- Original Message ------- > On Friday, April 22nd, 2022 at 5:30 PM, > bitcoin-dev-request at lists.linuxfoundation.org wrote: > > Send bitcoin-dev mailing list submissions to > bitcoin-dev at lists.linuxfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > or, via email, send a message with subject or body 'help' to > bitcoin-dev-request at lists.linuxfoundation.org > > You can reach the person managing the list at > bitcoin-dev-owner at lists.linuxfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bitcoin-dev digest..." > > Today's Topics: > > 1. ANYPREVOUT in place of CTV (darosior) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 22 Apr 2022 11:11:41 +0000 > From: darosior darosior at protonmail.com > > To: Bitcoin Protocol Discussion > bitcoin-dev at lists.linuxfoundation.org > > Subject: [bitcoin-dev] ANYPREVOUT in place of CTV > Message-ID: > > p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com > > Content-Type: text/plain; charset=utf-8 > > I would like to know people's sentiment about doing (a very slightly > tweaked version of) BIP118 in place of > (or before doing) BIP119. > > SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for > over 6 years. It presents proven and > implemented usecases, that are demanded and (please someone correct me if > i'm wrong) more widely accepted than > CTV's. > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made > optional [0], can emulate CTV just fine. > Sure then you can't have bare or Segwit v0 CTV, and it's a bit more > expensive to use. But we can consider CTV > an optimization of APO-AS covenants. > > CTV advocates have been presenting vaults as the flagship usecase. > Although as someone who've been trying to > implement practical vaults for the past 2 years i doubt CTV is necessary > nor sufficient for this (but still > useful!), using APO-AS covers it. And it's not a couple dozen more virtual > bytes that are going to matter for > a potential vault user. > > If after some time all of us who are currently dubious about CTV's stated > usecases are proven wrong by onchain > usage of a less efficient construction to achieve the same goal, we could > roll-out CTV as an optimization. In > the meantime others will have been able to deploy new applications > leveraging ANYPREVOUT (Eltoo, blind > statechains, etc..[1]). > > Given the interest in, and demand for, both simple covenants and better > offchain protocols it seems to me that > BIP118 is a soft fork candidate that could benefit more (if not most of) > Bitcoin users. > Actually i'd also be interested in knowing if people would oppose the > APO-AS part of BIP118, since it enables > CTV's features, for the same reason they'd oppose BIP119. > > [0] That is, to not commit to the other inputs of the transaction (via > sha_sequences and maybe also > sha_amounts). Cf > https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message > . > > [1] https://anyprevout.xyz/ "Use Cases" section > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ------------------------------ > > End of bitcoin-dev Digest, Vol 83, Issue 40 > ******************************************* > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220425/ee7678ee/attachment.html>