Very interesting question datafish.
I don't think under current rules that a localbitcoins transaction is subject to the money transmitter rule. A one way transaction of dollars for bitcoin does not violate the rules (arbitrary as they are, but never mind), from what I remember. But I could be wrong.
I think it more likely that they would seek to shut down localbitcoins itself (even understanding fully that another website would spring up - it's just to intimidate people really).
They *could* pose as a member of the network and engage in voluntary USD for bitcoins transactions with other members and then, (according to what law I don't know), try to prosecute the other side of the transaction. Like, one by one. Some certain amount of "one by one" has been done against bittorrenters but not much and it hasn't put people off. And it that case, it's very clear that a law is being violated. Here, not so much.
There is no doubt that what I'm proposing is not a watertight guarantee against government action, but it makes it much more difficult to create a blanket ban because there is no central server to attack.
Topic: Proposal for BTC-fiat P2P software (NOT for real time trading, only funding) (Read 1568 times)
May 27, 2013, 01:43:21 AM
May 26, 2013, 01:26:09 PM
To amplify the above, for those interested:
Imagine you want to do a localbitcoins trade in your local cafe, but you are really paranoid and want to do it TOTALLY safely. Think about what you would have to do.
The simple "turn up at the cafe and exchange model" is not safe for the either party. As well as all kinds of ways each party can defraud each other, there's always the risk of violence, perhaps the most efficient kind of fraud.
Imagine you want to do a localbitcoins trade in your local cafe, but you are really paranoid and want to do it TOTALLY safely. Think about what you would have to do.
The simple "turn up at the cafe and exchange model" is not safe for the either party. As well as all kinds of ways each party can defraud each other, there's always the risk of violence, perhaps the most efficient kind of fraud.
I've done quite a bit of in-person trading, and I was never worried about the violence risk. The reason that I stopped doing it was because of the FinCEN ruling on being a "money transmitter." How would your idea protect someone from entrapment by law enforcement agents?
May 24, 2013, 07:25:05 AM
I have to give credit to dansmith, who some time ago proposed the following very ingenious approach to try to solve the above problem:
https://bitcointalksearch.org/topic/tlsnotary-cryptographic-proof-of-fiat-transfer-for-p2p-exchanges-173220
EDIT: I am now not at all sure than dansmith's idea cannot work, it is technically difficult but if it can be made to work it solves the problem. Discussing it further with him at the above link.
(Earlier opinion:)
But I really doubt that this kind of approach can work, not least because banks would not consider this remotely acceptable behaviour, and no user will want to risk getting their bank account frozen for violation of TOS or something equivalent.
https://bitcointalksearch.org/topic/tlsnotary-cryptographic-proof-of-fiat-transfer-for-p2p-exchanges-173220
EDIT: I am now not at all sure than dansmith's idea cannot work, it is technically difficult but if it can be made to work it solves the problem. Discussing it further with him at the above link.
(Earlier opinion:)
But I really doubt that this kind of approach can work, not least because banks would not consider this remotely acceptable behaviour, and no user will want to risk getting their bank account frozen for violation of TOS or something equivalent.
May 24, 2013, 06:50:14 AM
To amplify the above, for those interested:
Imagine you want to do a localbitcoins trade in your local cafe, but you are really paranoid and want to do it TOTALLY safely. Think about what you would have to do.
The simple "turn up at the cafe and exchange model" is not safe for the either party. As well as all kinds of ways each party can defraud each other, there's always the risk of violence, perhaps the most efficient kind of fraud.
So, again, let's be really paranoid. Let's have an escrow agent. There is a public list of escrow agents listed somewhere. The two counterparties roll a dice and choose one (so as to make sure neither of them are cooperating with the escrow..), then make a phone call together. The escrow agent comes to the cafe. All three have their laptops. As a group they perform a 2 of 3 type escrow transaction, so each one has a key to the address that the bitcoin seller deposits the BTC into. Then the USD seller hands over the USD to the bitcoin seller, who gets out his UV device or whatever and counts and triple checks that all the USD notes are legitimate, in full view of the escrow agent.
The escrow agent sees that the USD side is correct, and "gives" his key to the cash seller, who can now transfer the BTC to his own address.
This is watertight EXCEPT that there is still the violence problem, sometimes referred to as "rubber hose cryptanalysis". The cash seller's heavies are sitting at the next table. At any point in the proceedings they just put a knife to someone's throat and demand all the private keys, thus walking off with all the cash and all the bitcoins. I know that this scenario is unlikely in public places, but it's far from impossible.
Meanwhile we can see that going "online" for this process would be fantastic for all the reasons I've already detailed - but unless the fiat side of the transaction is *verifiable* in some way, I'm stumped on how to solve this.
Imagine you want to do a localbitcoins trade in your local cafe, but you are really paranoid and want to do it TOTALLY safely. Think about what you would have to do.
The simple "turn up at the cafe and exchange model" is not safe for the either party. As well as all kinds of ways each party can defraud each other, there's always the risk of violence, perhaps the most efficient kind of fraud.
So, again, let's be really paranoid. Let's have an escrow agent. There is a public list of escrow agents listed somewhere. The two counterparties roll a dice and choose one (so as to make sure neither of them are cooperating with the escrow..), then make a phone call together. The escrow agent comes to the cafe. All three have their laptops. As a group they perform a 2 of 3 type escrow transaction, so each one has a key to the address that the bitcoin seller deposits the BTC into. Then the USD seller hands over the USD to the bitcoin seller, who gets out his UV device or whatever and counts and triple checks that all the USD notes are legitimate, in full view of the escrow agent.
The escrow agent sees that the USD side is correct, and "gives" his key to the cash seller, who can now transfer the BTC to his own address.
This is watertight EXCEPT that there is still the violence problem, sometimes referred to as "rubber hose cryptanalysis". The cash seller's heavies are sitting at the next table. At any point in the proceedings they just put a knife to someone's throat and demand all the private keys, thus walking off with all the cash and all the bitcoins. I know that this scenario is unlikely in public places, but it's far from impossible.
Meanwhile we can see that going "online" for this process would be fantastic for all the reasons I've already detailed - but unless the fiat side of the transaction is *verifiable* in some way, I'm stumped on how to solve this.
May 24, 2013, 06:23:55 AM
When Bob receives the wire transfer in his own bank account, with the incentive fee added, he releases the funds from escrow via his client.
If the wire transfer info is already known, and supposing the bank can release online proof of the transaction being sent, why couldn't an oracle handle the escrow? In other words, the oracle is told where to look for the online proof (bank website, etc.), and it releases the BTC to Alice if the proof is posted in a certain time frame, or back to Bob if not. That way there is absolutely no way to screw anyone - unless the bank messes up. The bank is the trusted party, though it has no idea it's being used for that.
I appreciate the well thought out comment.
About an oracle - I had only vaguely heard about the idea. Indeed, if it's possible it should be much better, but whether it's possible is linked to the following comments.
Over the last several days I've been too busy to go further with this, but in odd moments I kept thinking about the central transaction process and it suddenly occurred to me there is, perhaps, a very big hole in the concept:
We have two sides: Bob send BTC. This transaction is BOTH irreversible AND verifiable - by the public, specifically in the blockchain, and therefore by any escrow agent.
Alice send USD. This is irreversible if, as designed, done by wire transfer (after completion), and verifiable by both Bob and Alice, but NOT by the public and therefore NOT by any escrow agent.
Bank transactions are very much designed to be private, that would not be something easy to "hack". Whether the transaction is via SWIFT or ACH or whatever, it is known to "trusted" banking parties and each client but not anyone else.
This fundamental asymmetry creates an opportunity for a bad actor. If Bob wishes to keep his BTC he simply denies the wire, even though he knows it went through. The escrow has no way of performing arbitration here, because any "record" that Alice shows would have to be a copy (no one will give the agent a login to their bank account to check it - and a screen grab has, ahem, certain limitations..).
The only solution I can currently see (and maybe I'm missing something) is if it is possible to get confirmation of a wire transfer externally. Something like, I give the ID number of the wire transfer transaction, and the bank or other agency sends back confirmation of the transaction and its amount. This seems like it can't happen, as it violates customer confidentiality. Or another way would be if a message which Alice passes to the escrow agent is somehow "signed" by the bank and therefore verifiable. As far as I know, banks don't use PGP signatures unfortunately...
May 23, 2013, 12:48:53 PM
When Bob receives the wire transfer in his own bank account, with the incentive fee added, he releases the funds from escrow via his client.
If the wire transfer info is already known, and supposing the bank can release online proof of the transaction being sent, why couldn't an oracle handle the escrow? In other words, the oracle is told where to look for the online proof (bank website, etc.), and it releases the BTC to Alice if the proof is posted in a certain time frame, or back to Bob if not. That way there is absolutely no way to screw anyone - unless the bank messes up. The bank is the trusted party, though it has no idea it's being used for that.
May 23, 2013, 12:39:25 PM
It sounds like we're completely agreed on every part of our solution except one critical difference:
The part of your solution that imports fiat is just too slow... You could never have a real-time trading graph with this method.
This goes against my Criterias #3 & #6.
I didn't want to ignore your post entirely though because at least your head is in the right place and you see the real problem we face. Keep at it!
The part of your solution that imports fiat is just too slow... You could never have a real-time trading graph with this method.
This goes against my Criterias #3 & #6.
I didn't want to ignore your post entirely though because at least your head is in the right place and you see the real problem we face. Keep at it!
I feel like you're wanting the total solution to just pop into place. Doing a meeting-less, trustless localbitcoins.com-type of thing would be a giant step, nothing to sneeze at. Progress is not always all-or-nothing.
May 23, 2013, 06:51:40 AM
It sounds like we're completely agreed on every part of our solution except one critical difference:
The part of your solution that imports fiat is just too slow... You could never have a real-time trading graph with this method.
This goes against my Criterias #3 & #6.
I didn't want to ignore your post entirely though because at least your head is in the right place and you see the real problem we face. Keep at it!
The part of your solution that imports fiat is just too slow... You could never have a real-time trading graph with this method.
This goes against my Criterias #3 & #6.
I didn't want to ignore your post entirely though because at least your head is in the right place and you see the real problem we face. Keep at it!
Yes, this project description is focused entirely on how to get fiat into BTC and BTC into fiat because that is the only way Bitcoin can really be attacked, and also that is the part that new adopters find difficult (of course the two things are linked). I believe this is the problem people are currently worried about.
Once your fiat is converted to BTC, a more real time system could be used for trades, along the lines of what you're describing.
May 22, 2013, 05:02:43 PM
It sounds like we're completely agreed on every part of our solution except one critical difference:
The part of your solution that imports fiat is just too slow... You could never have a real-time trading graph with this method.
This goes against my Criterias #3 & #6.
I didn't want to ignore your post entirely though because at least your head is in the right place and you see the real problem we face. Keep at it!
The part of your solution that imports fiat is just too slow... You could never have a real-time trading graph with this method.
This goes against my Criterias #3 & #6.
I didn't want to ignore your post entirely though because at least your head is in the right place and you see the real problem we face. Keep at it!
May 20, 2013, 08:00:11 AM
Think localbitcoins but electronic and with P2P overlay.
https://github.com/AdamISZ/P2PBits/blob/master/README.md
First, name is terrible, can't think of a good one yet!
Second, canvassing opinion and ideas about it. The use cases in particular might give some good food for thought about details.
Any opinions on dev. language? I'm tempted to start with C++ as I feel more comfortable with it, but that might not be the best choice here. Still, not a critical issue in the early stage.
I will be very busy moving (home, country, continent..) over the next few weeks but after that will have a lot of free time. If others are not interested, I might just go ahead myself.
Branching off from a discussion starting here: https://bitcointalksearch.org/topic/m.2197907
https://github.com/AdamISZ/P2PBits/blob/master/README.md
First, name is terrible, can't think of a good one yet!
Second, canvassing opinion and ideas about it. The use cases in particular might give some good food for thought about details.
Any opinions on dev. language? I'm tempted to start with C++ as I feel more comfortable with it, but that might not be the best choice here. Still, not a critical issue in the early stage.
I will be very busy moving (home, country, continent..) over the next few weeks but after that will have a lot of free time. If others are not interested, I might just go ahead myself.
Branching off from a discussion starting here: https://bitcointalksearch.org/topic/m.2197907
Jump to: