7 comments

[ 2.9 ms ] story [ 26.3 ms ] thread
I'm guessing this has some interesting legal implications. This specific incarnation might not survive.

I like it!

> This specific incarnation might not survive.

Actually, I am all for wallets implementing similar functionality and making the overall experience better. It's just that they are all really, really slow to do this. But escrow transactions are useful and the purpose of the app is just to allow you to create / redeem those.

Besides that, I plan to add some URL scheme where for example you create a payment request and send the link, and the buyer just pastes their private key and pays. (On a marketplace where the system generates the payment request and present the buyer with the link, for example.)

It's just that bitcoin:// URLs don't allow you to do things like this, and not every wallet supports URL scheme regardless.

> and the buyer just pastes their private key and pays

I thought your link was cool, but I'm a little scared that this is your stated intention. Are you serious? Doesn't that give you, the middleman, access to all of their funds (and not just the amount they needed to use to pay the invoice?)

The more I think about it, the more I think it seems like a well-reasoned and wise approach.

We probably ought to decouple "the wallet" from "the identity" as much as possible, and users handing over wallet keys to their favorite Trusted Entity to Facilitate Payment is a step in the right direction. If you want to keep funds separate, you will need a separate wallet and to get comfortable making payments from one wallet into another. Accounts in the same wallet, derived from the same private keys, are not sufficient.

One of the problems I consider in building a service like this is: how do you safely scale your fee schedule to match the level of funds your users trusted you to keep securely and escrow?

Do you charge a flat fee to list an advertisement on your forum, where your escrow services are included with the base price?

Do you take a percent fee on each transaction, and if so, how do you enforce it given that you're using three-party escrow such as this? If you're doing it right, they can literally complete the transaction without your help and perhaps should only feel compelled to pay you while you're actively involved in resolving disputes.

Maybe that's the right approach, it incentivizes users to police themselves and to do business with more trusted partners, to avoid paying fees, but you could wind up making very little compared to the volume of transactions that occurred between users of your advertising space. (Pro: the costs associated with fraud and managing escrow are very low.)

You could also charge a monthly membership fee and restrict access to the advertising space to only paid members with current accounts? They would get your escrow service for free (included in the price). That seems like the best option, but you have to deal with "critical mass" and network effects problems, there is little incentive to pay to advertise on a forum with no users.

It would also be easy to overshoot your target transaction fee percentage, or undervalue your time by charging too small of a fee when in reality attempts to perpetrate a fraud on even private internet forums are very common and very time consuming to investigate.

This may be slightly more naïve analysis than I thought, and reaching for a larger service than what you've actually provided, but it's more thought out than my first reply.

I wonder what the legal implications are, as the money isn't exactly being sent to the escrow agent, and the agent doesn't have the ability to steal the funds for himself.
It could still be construed as aiding in criminal enterprise or something like that. Maybe not.
Providing the web service as a marketplace and serving up advertising (and collecting revenue from advertising fees)... maybe

Publishing your key in a way such that people you don't know can authorize you as an escrow agent to transactions you're not aware of... I hope not!