On Wed, Jun 05, 2013 at 05:19:16PM -0700, 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.
A few issues: Revocable payments are almost always invoked in cases where the decision that a payment needs to be revoked is done by humans. To worry about the difficulty of finding a "trusted escrow service" is irrelevant at the protocol level - this isn't a problem that can be solved by math. Legally speaking revocation can generally happen any time in the future, even years in the future. Note the controversies involved around a variety of land transactions that occured hundreds of years in the past in North America and other parts of the world, where distant relatives of those who made the transactions are attempting to have them reversed partially or fully. Technical solutions with a limited revocation window are likely to be found unacceptable in the eyes of the law. Focusing on the need to "revoke" a transaction is taking a banking idea, and applying it very incorrectly to the Bitcoin world; in banking revoking a transaction can result in your balance being negative. What you need to focus on is the spirit of what revoking a transaction is about, which is to take money from someone who thought they had it, and give it to someone else. We can easily replicate this effect in Bitcoin by simply giving the private keys for our wallets to the relevant revocation authority, or, if more auditing is desired, storing our coins in 1-of-2 multisig addresses spendable by either us or that authority. In the event that a transaction needs to be revoked, simply have the escrow service make a transaction that takes the correct amount of coins from your wallet, and gives it to the person who sent you the money. Problem solved. -- 'peter'[:-1]@petertodd.org 0000000000000108f8cf27a2a2f49384346d915ff0970554358b9544bc7f5bfd
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
