đź“… Original date posted:2022-04-22
đź“ť Original message: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 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.
>
> 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 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/20220422/801f1d1e/attachment.html>;
rot13maxi [ARCHIVE] /
npub12a…llglz
2023-06-07 23:07:57
in reply to nevent1q…26k0
Author Public Key
npub12aguh8y7hacsxc3c7fsjzkqh95nu9cuh4ec6htx9y3sz75722npqmllglzPublished at
2023-06-07 23:07:57Event JSON
{
"id": "fe2159535f45c76b72462282870f99461fd30a9aa451a43cbc9808968cd2b9a6",
"pubkey": "5751cb9c9ebf71036238f2612158172d27c2e397ae71abacc524602f53ca54c2",
"created_at": 1686179277,
"kind": 1,
"tags": [
[
"e",
"744ae2e156228361733cf74acfff3433f11541ee820fe9185cc72f3c98beb11b",
"",
"root"
],
[
"e",
"80894dcdc05c54aec816bd5822a2781c3f82998695e953bf19210935ee3c3ccc",
"",
"reply"
],
[
"p",
"0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2"
]
],
"content": "📅 Original date posted:2022-04-22\n📝 Original message:Good morning darosior,\n\nDo 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.\n\nI haven’t seen much in the way of APO implementations recently, but I also haven’t gone looking, so would appreciate any links!\n\nThanks\n\nOn Fri, Apr 22, 2022 at 7:11 AM, darosior via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I would like to know people's sentiment about doing (a very slightly tweaked version of) BIP118 in place of\n\u003e (or before doing) BIP119.\n\u003e\n\u003e SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 years. It presents proven and\n\u003e implemented usecases, that are demanded and (please someone correct me if i'm wrong) more widely accepted than\n\u003e CTV's.\n\u003e\n\u003e SIGHASH_ANYPREVOUTANYSCRIPT, if its \"ANYONECANPAY\" behaviour is made optional [0], can emulate CTV just fine.\n\u003e 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\n\u003e an optimization of APO-AS covenants.\n\u003e\n\u003e CTV advocates have been presenting vaults as the flagship usecase. Although as someone who've been trying to\n\u003e implement practical vaults for the past 2 years i doubt CTV is necessary nor sufficient for this (but still\n\u003e useful!), using APO-AS covers it. And it's not a couple dozen more virtual bytes that are going to matter for\n\u003e a potential vault user.\n\u003e\n\u003e If after some time all of us who are currently dubious about CTV's stated usecases are proven wrong by onchain\n\u003e usage of a less efficient construction to achieve the same goal, we could roll-out CTV as an optimization. In\n\u003e the meantime others will have been able to deploy new applications leveraging ANYPREVOUT (Eltoo, blind\n\u003e statechains, etc..[1]).\n\u003e\n\u003e Given the interest in, and demand for, both simple covenants and better offchain protocols it seems to me that\n\u003e BIP118 is a soft fork candidate that could benefit more (if not most of) Bitcoin users.\n\u003e Actually i'd also be interested in knowing if people would oppose the APO-AS part of BIP118, since it enables\n\u003e CTV's features, for the same reason they'd oppose BIP119.\n\u003e\n\u003e [0] That is, to not commit to the other inputs of the transaction (via `sha_sequences` and maybe also\n\u003e `sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message.\n\u003e\n\u003e [1] https://anyprevout.xyz/ \"Use Cases\" section\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220422/801f1d1e/attachment.html\u003e",
"sig": "84c4c6cd0f9997a8ccc58150a2e3a5e3ea0b73af63cca110efe884ed489b257939bef7b984f353b4efe9ce16bbddae32ea5ab8fd039994aa941968fc2d3f1b88"
}