📅 Original date posted:2022-03-05
📝 Original message:This may be of interest:
https://github.com/sapio-lang/sapio/blob/01830132bbbe39c3225e173e099f6e1a0611461c/sapio/examples/subscription.py
Basically, a (old, python) sapio contract whereby you can make cancellable
subscriptions that are essentially a time based autopay scheme whereby
cancellation gives time for the receiver to claim the correct amount of
money.
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
On Sat, Mar 5, 2022 at 10:58 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Chris,
>
> > I think this proposal describes arbitrary lines of pre-approved credit
> from a bitcoin wallet. The line can be drawn down with oracle attestations.
> You can mix in locktimes on these pre-approved lines of credit if you would
> like to rate limit, or ignore rate limiting and allow the full utxo to be
> spent by the borrower. It really is contextual to the use case IMO.
>
> Ah, that seems more useful.
>
> Here is an example application that might benefit from this scheme:
>
> I am commissioning some work from some unbranded workperson.
> I do not know how long the work will take, and I do not trust the
> workperson to accurately tell me how complete the work is.
> However, both I and the workperson trust a branded third party (the
> oracle) who can judge the work for itself and determine if it is complete
> or not.
> So I create a transaction whose signature can be completed only if the
> oracle releases a proper scalar and hand it over to the workperson.
> Then the workperson performs the work, then asks the oracle to judge if
> the work has been completed, and if so, the work can be compensated.
>
> On the other hand, the above, where the oracle determines *when* the fund
> can be spent, can also be implemented by a simple 2-of-3, and called an
> "escrow".
> After all, the oracle attestation can be a partial signature as well, not
> just a scalar.
> Is there a better application for this scheme?
>
> I suppose if the oracle attestation is intended to be shared among
> multiple such transactions?
> There may be multiple PTLCs, that are triggered by a single oracle?
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20220306/df48d359/attachment-0001.html>;
Jeremy Rubin [ARCHIVE] /
npub1xu…fzef0
2023-06-07 23:05:10
in reply to nevent1q…z99p
Author Public Key
npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0Published at
2023-06-07 23:05:10Event JSON
{
"id": "664157a8d281ef2220fef6bd30854914e4c38115377e50b19894867b8cb09bf7",
"pubkey": "372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a",
"created_at": 1686179110,
"kind": 1,
"tags": [
[
"e",
"4e296de6791e419fed77f6e3cdc93ce4cb4937b7488ba08e14a5b71934bcf305",
"",
"root"
],
[
"e",
"3eca09ef0cda219e1e745be643e182b881732ec1b3d8b6950ef74b7aace24ee5",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2022-03-05\n📝 Original message:This may be of interest:\n\nhttps://github.com/sapio-lang/sapio/blob/01830132bbbe39c3225e173e099f6e1a0611461c/sapio/examples/subscription.py\n\nBasically, a (old, python) sapio contract whereby you can make cancellable\nsubscriptions that are essentially a time based autopay scheme whereby\ncancellation gives time for the receiver to claim the correct amount of\nmoney.\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\nOn Sat, Mar 5, 2022 at 10:58 PM ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Chris,\n\u003e\n\u003e \u003e I think this proposal describes arbitrary lines of pre-approved credit\n\u003e from a bitcoin wallet. The line can be drawn down with oracle attestations.\n\u003e You can mix in locktimes on these pre-approved lines of credit if you would\n\u003e like to rate limit, or ignore rate limiting and allow the full utxo to be\n\u003e spent by the borrower. It really is contextual to the use case IMO.\n\u003e\n\u003e Ah, that seems more useful.\n\u003e\n\u003e Here is an example application that might benefit from this scheme:\n\u003e\n\u003e I am commissioning some work from some unbranded workperson.\n\u003e I do not know how long the work will take, and I do not trust the\n\u003e workperson to accurately tell me how complete the work is.\n\u003e However, both I and the workperson trust a branded third party (the\n\u003e oracle) who can judge the work for itself and determine if it is complete\n\u003e or not.\n\u003e So I create a transaction whose signature can be completed only if the\n\u003e oracle releases a proper scalar and hand it over to the workperson.\n\u003e Then the workperson performs the work, then asks the oracle to judge if\n\u003e the work has been completed, and if so, the work can be compensated.\n\u003e\n\u003e On the other hand, the above, where the oracle determines *when* the fund\n\u003e can be spent, can also be implemented by a simple 2-of-3, and called an\n\u003e \"escrow\".\n\u003e After all, the oracle attestation can be a partial signature as well, not\n\u003e just a scalar.\n\u003e Is there a better application for this scheme?\n\u003e\n\u003e I suppose if the oracle attestation is intended to be shared among\n\u003e multiple such transactions?\n\u003e There may be multiple PTLCs, that are triggered by a single oracle?\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220306/df48d359/attachment-0001.html\u003e",
"sig": "b420172f0b7dbcf6e4c1606383ab423c54f2246ee1fb30299da4286f668f8ce29e2dd210b4d46de559206aba9c95472f6266ac3725d648f785f057c958a7845f"
}