Hi,
Richard Myers has an implementation of Eltoo using Bitcoin Core's functional
test framework:
https://github.com/remyers/bitcoin/blob/eltoo-anyprevout/test/functional/simulate_eltoo.py.
He blogged about it, too. https://yakshaver.org/2021/07/26/first.html
He seems to have something similar for covenants, but it's WIP:
https://github.com/remyers/bitcoin/blob/covenant-anyprevout/test/functional/feature_apocovenant.py.
https://yakshaver.org/2021/11/18/covenants.html.
His APO page looks like a good reference on the topic:
https://yakshaver.org/bitcoin/#anyprevout.
------- Original Message -------
Le vendredi 22 avril 2022 à 1:44 PM, rot13maxi <rot13m...@protonmail.com> a
écrit :
> Good morning darosior,
>
> Do you know if there is a working implementation of APO somewhere that people
> can use to try out some of the proposed usecases? For example, it would be
> great to see what eltoo would actually look like on an APO signet. Or to see
> some working code for a vault using covenants in an APO world.
>
> I haven’t seen much in the way of APO implementations recently, but I also
> haven’t gone looking, so would appreciate any links!
>
> Thanks
>
> On Fri, Apr 22, 2022 at 7:11 AM, darosior via bitcoin-dev
> <bitcoin-dev@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.
>>
>> 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
>> _______________________________________________
>> 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
