📅 Original date posted:2022-07-26
📝 Original message:What would be the canonical definition and examples of capabilities in the
Bitcoin context ?
In anycase, I believe it would be better to start a covenant process from
the use-cases in themselves, and analyse the trade-offs of any set of
contracting primitives, or even new Bitcoin fields if they're required
building blocks of the use-cases.
Le dim. 24 juil. 2022 à 14:23, Bram Cohen <bram at chia.net> a écrit :
> On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Indeed this range has grown wild. Without aiming to be exhaustive (I'm
>> certainly missing some interesting proposals lost in the abyss of
>> bitcointalk.org), we can mention the following use-cases: multi-party
>> stateful contracts [11], congestion trees [12], payment pools [13], "eltoo"
>> layered commitments [14], programmable vaults [15], multi-events contracts
>> [16], blockchain-as-oracle bets [17], spacechains [18], trustless
>> collateral lending [19], ...
>>
>
> The big question you missed is whether capabilities are in scope for a
> covenants proposal. In particular, vaults work a lot better when payments
> to them are immediately locked up in the vault rather than it having to do
> a step to accept them first.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220725/16bc82f3/attachment.html>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-06-08 01:12:07
in reply to nevent1q…nahn
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-06-08 01:12:07Event JSON
{
"id": "442f86e6d0553b8399a335ead1e2c1ad1c1f7eb75de5afc1e229f9b2c189379f",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1686179527,
"kind": 1,
"tags": [
[
"e",
"32278431461b2aef74d3e0bd3f2c67c0cb2a1196ed72c760c4d2cf2b42931ee2",
"",
"root"
],
[
"e",
"5b1a2a9ee2725666709b16f5e10ca52b6bed54379a1b75e523caed0898814cbc",
"",
"reply"
],
[
"p",
"d1366ceb183123950e20a9fb63467824b53a9f92be723c9c6f0aeda4c65523d8"
]
],
"content": "📅 Original date posted:2022-07-26\n📝 Original message:What would be the canonical definition and examples of capabilities in the\nBitcoin context ?\n\nIn anycase, I believe it would be better to start a covenant process from\nthe use-cases in themselves, and analyse the trade-offs of any set of\ncontracting primitives, or even new Bitcoin fields if they're required\nbuilding blocks of the use-cases.\n\nLe dim. 24 juil. 2022 à 14:23, Bram Cohen \u003cbram at chia.net\u003e a écrit :\n\n\u003e On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Indeed this range has grown wild. Without aiming to be exhaustive (I'm\n\u003e\u003e certainly missing some interesting proposals lost in the abyss of\n\u003e\u003e bitcointalk.org), we can mention the following use-cases: multi-party\n\u003e\u003e stateful contracts [11], congestion trees [12], payment pools [13], \"eltoo\"\n\u003e\u003e layered commitments [14], programmable vaults [15], multi-events contracts\n\u003e\u003e [16], blockchain-as-oracle bets [17], spacechains [18], trustless\n\u003e\u003e collateral lending [19], ...\n\u003e\u003e\n\u003e\n\u003e The big question you missed is whether capabilities are in scope for a\n\u003e covenants proposal. In particular, vaults work a lot better when payments\n\u003e to them are immediately locked up in the vault rather than it having to do\n\u003e a step to accept them first.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220725/16bc82f3/attachment.html\u003e",
"sig": "6e27728a0e42784dfa11289827bc51f8690aef715e6241e892bf91da6228d50a5299bd8ad6570e67f40da32e510342e6441c4d12e0d97ff7806c9da294de5222"
}