📅 Original date posted:2013-06-05
📝 Original message:The two most basic ways would be simply:
(1) You create your transactions having a locktime of X days and has
sequence numbers such that it can be replaced exactly once. The
replacement, can be executed within 30 days.
(2) You simply send money to 1-of-2 transactions: me-or-you. If the
person who is receiving it wants it, they have to sign for it by sending
it to one of their own single-sig addresses. Otherwise, you can return
it to yourself at some point in the future.
I don't totally understand the goal, and how/if these solutions actually
achieve such goal. But it does add a way for transactions to exist a
non-final state for some amount of time. But in both cases,
accessibility is still binary: you have complete access to it, until
you don't. Which might be seen as the point of irrevocable transfer.
-Alan
On 06/05/2013 08:19 PM, Peter Vessenes wrote:
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
> article got posted today, noting that FinCEN thinks irrevocable
> payments are money laundering tools.
>
> I will hold my thoughts about the net social good of rent-seeking
> large corporations taking money from consumers over fraudulent
> reversals. Actually, I won't, I just said it.
>
> At any rate, it got me thinking, can we layer on revocability somehow
> without any protocol change, as an opt-in?
>
> My initial scheme is a trusted (hah) escrow service that issues time
> promises for signing. If it doesn't receive a cancel message, it will
> sign at the end of the time.
>
> The addresses would be listed by the escrow service, or in an open
> registry, so you could see if you were going to have a delay period
> when you saw a transaction go out.
>
> This seems sort of poor to me, it imagines that mythical thing, a
> trusted escrow service, and is vulnerable to griefing, but I thought
> I'd see if some of the brighter minds than me can come up with a
> layer-on approach here.
>
> When I think about it, I can imagine that I would put a good number of
> my coins in a one day reversible system, because I would have warning
> if someone wanted to try and spend them, and could do something about
> it. I'm not sure if it gets me anything over a standard escrow
> arrangement, though.
>
> Peter
>
> --
>
> ------------------------------------------------------------------------
>
> CoinLab LogoPETER VESSENES
> CEO
>
> *peter at coinlab.com <mailto:peter at coinlab.com> * / 206.486.6856
> / SKYPE: vessenes
> 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130605/a7e538e5/attachment.html>;
Alan Reiner [ARCHIVE] /
npub1sm…mnq7h
2023-06-07 15:02:48
in reply to nevent1q…pu0q
Author Public Key
npub1sm6zhjmk5scuz294jmpkw99wwwjzetjgwp4fu4gn6utqgdz87hkqamnq7hPublished at
2023-06-07 15:02:48Event JSON
{
"id": "33053aeb71c2656c341f0ccddb8ab2ba2364c75e85860270f7a00ee904c45e52",
"pubkey": "86f42bcb76a431c128b596c36714ae73a42cae48706a9e5513d716043447f5ec",
"created_at": 1686150168,
"kind": 1,
"tags": [
[
"e",
"7a7612c1e97c5bef1df07d5eefc155771b13089978b697fd0ef5522c3612913b",
"",
"root"
],
[
"e",
"d19402b418cce9a1d2c52a5662d2db17d8cd117d206f42e831f8cd632a7a3a0a",
"",
"reply"
],
[
"p",
"c8914ab5f1efb93771e9c5b7fe20dcff2c343f46f4846ae6689a0c9478b04e01"
]
],
"content": "📅 Original date posted:2013-06-05\n📝 Original message:The two most basic ways would be simply:\n\n(1) You create your transactions having a locktime of X days and has\nsequence numbers such that it can be replaced exactly once. The\nreplacement, can be executed within 30 days.\n\n(2) You simply send money to 1-of-2 transactions: me-or-you. If the\nperson who is receiving it wants it, they have to sign for it by sending\nit to one of their own single-sig addresses. Otherwise, you can return\nit to yourself at some point in the future.\n\nI don't totally understand the goal, and how/if these solutions actually\nachieve such goal. But it does add a way for transactions to exist a\nnon-final state for some amount of time. But in both cases,\naccessibility is still binary: you have complete access to it, until\nyou don't. Which might be seen as the point of irrevocable transfer.\n\n-Alan\n\n\n\nOn 06/05/2013 08:19 PM, Peter Vessenes wrote:\n\u003e So, this\n\u003e http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1\n\u003e article got posted today, noting that FinCEN thinks irrevocable\n\u003e payments are money laundering tools. \n\u003e\n\u003e I will hold my thoughts about the net social good of rent-seeking\n\u003e large corporations taking money from consumers over fraudulent\n\u003e reversals. Actually, I won't, I just said it.\n\u003e\n\u003e At any rate, it got me thinking, can we layer on revocability somehow\n\u003e without any protocol change, as an opt-in?\n\u003e\n\u003e My initial scheme is a trusted (hah) escrow service that issues time\n\u003e promises for signing. If it doesn't receive a cancel message, it will\n\u003e sign at the end of the time. \n\u003e\n\u003e The addresses would be listed by the escrow service, or in an open\n\u003e registry, so you could see if you were going to have a delay period\n\u003e when you saw a transaction go out.\n\u003e\n\u003e This seems sort of poor to me, it imagines that mythical thing, a\n\u003e trusted escrow service, and is vulnerable to griefing, but I thought\n\u003e I'd see if some of the brighter minds than me can come up with a\n\u003e layer-on approach here.\n\u003e\n\u003e When I think about it, I can imagine that I would put a good number of\n\u003e my coins in a one day reversible system, because I would have warning\n\u003e if someone wanted to try and spend them, and could do something about\n\u003e it. I'm not sure if it gets me anything over a standard escrow\n\u003e arrangement, though.\n\u003e\n\u003e Peter\n\u003e\n\u003e -- \n\u003e\n\u003e ------------------------------------------------------------------------\n\u003e\n\u003e CoinLab LogoPETER VESSENES \n\u003e CEO\n\u003e\n\u003e *peter at coinlab.com \u003cmailto:peter at coinlab.com\u003e * / 206.486.6856\n\u003e / SKYPE: vessenes \n\u003e 71 COLUMBIA ST / SUITE 300 / SEATTLE, WA 98104\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e How ServiceNow helps IT people transform IT departments:\n\u003e 1. A cloud service to automate IT design, transition and operations\n\u003e 2. Dashboards that offer high-level views of enterprise services\n\u003e 3. A single system of record for all IT processes\n\u003e http://p.sf.net/sfu/servicenow-d2d-j\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130605/a7e538e5/attachment.html\u003e",
"sig": "0d7f8de6b9018b18583417677567ba85bead1888a902cc70fa48596608e5727b4357c86292620ea4408bbc0dd336e58f32b6e8f3fd4c5dcfd7c1bfc76a509b10"
}