I entered the police station as a suspect. When I left the officer loved Bitcoin

[hugolp]

"Bitcoin. Because the government says it's neat."

Is this supposed to be good or bad?

[TangibleCryptography]

Good points Mike.  I wasn't trying to imply it is solved.  I still think Bitcoins is years (maybe a decade) from mainstream acceptance and the issues you outline are just some of the hudrles.  I am bullish though because Bitcoin CAN be improved or extended.  With traditional payment mechanisms since the cost of fraud is never felt by the intermediary there is no real reason to spend money on improving anything.  I mean bank wires (at least in the US) are roughly the same as they were in the 1940s.  Bitcoin can be extended to prevent MIM based attacks.  The only question is how do we monetize that development.  I am all ears.

On IDs.  I don't know how useful they are. ID are pretty easy to fake.  I could get a photoshopped ID that says Mike Hearn for a hundred bucks and would be willing to bet it would be accepted by MtGox as legit.   Note that isn't a slam on MtGox they have a nearly impossible task of trying to "verify" IDs submitted for hundreds of countries and other political subdivisions.  Worse they aren't verifying the actual ID in person they are verifying a copy of the ID (which is much easier to fake). Once again a monopoly (govt issuers) don't really care and are unlikely to ever improve them. 

On Switzerland.  I didn't know that but it does illustrate the point that since banking isn't uniform the idea of a "one exchange to rule them all" is probably not going to happen.  A US based exchange (in theory) can get very good at authenticating US customers,  a EU based one very good at dealing with EU based customers.  I think currency exchange will be more diverse in the future.  Those that attempt to be everything to everyone will likely fail.

[sebicas]

I thing it could be useful if you add a "SCAM WARNING" message to your site, so this type of scam can be reduced.

[hazek]

Mike has some good points but there is one fundamental difference with Bitcoin.  It can't be reversed, it can't be frozen, it can't be suspended.

Yes. That's great for the merchant. Less great for the gullible victim.

Gullible being the operative word.

Someone tell me what mechanism is in place so people don't get scammed in the street using cash? Oh that's right, THERE ISN'T ONE, besides common sense. The problem, Mike, is that this the issue of fraud can't be solved by making it impossible because you can't make it impossible, not even if you track everything and everyone. The only way to solve it is for people to LEARN FROM THEIR MISTAKES AND STOP REPEATING THEM.

Oh someone told you to send money to some place and expect and iPhone and you didn't check their credibility or used an escrow? Well too bad, lesson learned.


But naturally the nanny state tries to use this problem as an excuse to further oppress people under the pretense of providing tools(the use of violence) that make fraud impossible.  

[nybble41]

It sounds like what is really needed here is something OpenTransactions uses: a memo field. Human-readable names instead of addresses would help, but they're not foolproof; someone has to verify the owner's identity, which introduces centralization and (sometimes unwarranted) trust, and there are numerous issues with alternate and confusingly similar forms of names (amazon.com vs. arnazon.com vs. amazon-bitcoins.com). A freeform memo field in each transaction would allow the payer to indicate what the payment is for, greatly reducing the scope for these sorts of MitM attacks. The hypothetical diamond dealer would know better than to ship an order for diamonds when the memo field of the payment states that it was meant to cover an order for an iPhone.

(The other major missing piece, which would probably be harder to implement, is the ability to refuse payment. Transactions should require the recipients' signatures in addition to the senders' before being accepted into the block chain, similar to the requirement to endorse a check before it can be deposited. The current system where anyone can deposit funds, from any source, into anyone's account without their approval could get a lot of people into fairly serious trouble, accounting-wise.)

[SgtSpike]

Mike has some good points but there is one fundamental difference with Bitcoin.  It can't be reversed, it can't be frozen, it can't be suspended.

Yes. That's great for the merchant. Less great for the gullible victim.

This point is far too often missed in the Bitcoin world.  Everyone touts irreversibility as such a great thing, when in reality, it just shifts the risk of payment from the merchant to the customer.  As Mike mentioned, that's an improvement over the old system, but it's still not perfect. 

It most certainly requires a huge change of mindset, and this could be the greatest challenge Bitcoin will face with regards to mass adoption.  Customers are used to being able to order things online, and if they don't receive them, they can call up their CC company and cancel the order.  We need to make sure Bitcoin users are aware that sending Bitcoin to someone unknown is roughly equivalent to sending a package full of cash through the mail - you're not getting it back, so you better be sure whoever you are sending it to is trustworthy.

[BCB]

This is a great discussion and needs to be continued.

Obviously bitcoin is not a panacea for counter party risk.

Investment schemes and financial fraud are probably as old as (if not older then)  prostitution and will certainly continue along with the "bitcoin revolution"


@hazek I do agree that the nanny state is a HUGE apart of the problem.  In the US I say it started with the invention of t-ball.

Unfortunately scammers prey on our GREED and our innate TRUST.  Most individuals first choice is to trust another person to say what they are going to do and most of the time that actually happens.  Once we get scammed or defrauded most individuals learn from that and are on the lookout for it to be repeated.  Unfortunately like the three card monty players you see in the summer time in any major metropolitan area, there will always be easy victims.

@mike I would love to read more about the work you are doing on the payment systems.  Is there a link?

[Mike Hearn]

Good points Mike.  I wasn't trying to imply it is solved.  I still think Bitcoins is years (maybe a decade) from mainstream acceptance and the issues you outline are just some of the hurdles.  I am bullish though because Bitcoin CAN be improved or extended.  With traditional payment mechanisms since the cost of fraud is never felt by the intermediary there is no real reason to spend money on improving anything.  I mean bank wires (at least in the US) are roughly the same as they were in the 1940s.  Bitcoin can be extended to prevent MIM based attacks.  The only question is how do we monetize that development.  I am all ears.

Yes, I quite agree. The existing system is stagnant. Bitcoins greatest strength is anyone can innovate on top of it.

For funding of network improvements I believe assurance contracts are the way to go. We can crowdfund improvements from developers with good reputations.

On IDs.  I don't know how useful they are. ID are pretty easy to fake.  I could get a photoshopped ID that says Mike Hearn for a hundred bucks and would be willing to bet it would be accepted by MtGox as legit.

Quite possibly. The fact that governments don't issue citizens with asymmetric keypairs is an astonishing lack of imagination. Well, probably a few enlightened countries do, but it's not normal.

I think in future we may see companies, perhaps exchanges, issue personal certificates that contain identity information along with some information on how that identity was proven. Note that this doesn't prevent you from creating anonymous pseudonyms. The underlying assumption behind presenting ID documents is scarcity. You could just as easily spend 100 BTC to miner fees (over a long period of consecutive blocks to avoid you mining the fees back yourself) and then use that as proof that you aren't bulk creating pseudonyms. The "identity" then has some value and can be used to build reputation but isn't linkable to anyone in the real world.

For most users though, who don't want to make a big financial sacrifice, their personal liability backed by the justice system will be a more attractive way to gain trust. Having thorough verification of identity followed by the issuance of a personal cert stating who it belongs to and the level of verification that was performed would be a valuable service.

It sounds like what is really needed here is something OpenTransactions uses: a memo field ... The other major missing piece, which would probably be harder to implement, is the ability to refuse payment.

These needs have already been anticipated. The payment protocol I've been designing with Gavin and Pieter will provide these features. See here:

https://bitcointalk.org/index.php?topic=128442
https://gist.github.com/4120476

The current protocol allows merchants to send a message to payers at the same time as communicating addresses and proof of identity, and payers can provide a message when they upload transactions to the merchants. There's still a lot of design work to do, to ensure these facilities all get used correctly. If you upload a transaction to the recipient directly they can verify the message you provided makes sense, and only then broadcast the transactions and take the money.

The payment protocol also lays the foundation for building dispute mediation into the system.

[hazek]

It most certainly requires a huge change of mindset, and this could be the greatest challenge Bitcoin will face with regards to mass adoption. 

I call BS on this. People generally already know how to handle cash, there's no reason they couldn't quickly adopt all those same principles to handling bitcoins.

[hazek]

Unfortunately like the three card monty players you see in the summer time in any major metropolitan area, there will always be easy victims.

Not necessarily, people can also learn from other people's mistakes.

[SgtSpike]

It most certainly requires a huge change of mindset, and this could be the greatest challenge Bitcoin will face with regards to mass adoption. 

I call BS on this. People generally already know how to handle cash, there's no reason they couldn't quickly adopt all those same principles to handling bitcoins.

I disagree.  How many more instances of people sending Bitcoin to scammers do we need to see before people "quickly adopt" to it?

Handling cash is a different animal.  You get to see the person you are doing business with.  In almost all cases with Bitcoin, you do not.  It is much harder to be scammed using cash, unless you're sending it in the mail (a bad idea to start with) or paying drug dealers in a back alley (another bad idea).  But the purpose of Bitcoin is, effectively, to send cash in the mail!  There is no commonly-held precedent of understanding that can apply to this.

[fimp]

I've implemented a new policy where we require bank transfers to include the message "For buying Bitcoins".

[hazek]

I've implemented a new policy where we require bank transfers to include the message "For buying Bitcoins".

Smart.

[BCB]

Unfortunately like the three card monty players you see in the summer time in any major metropolitan area, there will always be easy victims.

Not necessarily, people can also learn from other people's mistakes.

Of course, but there are always the uninitiated who come along and make the same mistake.  That's why the game has persisted for so long.  And if you want further proof just idle in #bitcoin-otc and you can watch it happen on a daily basis.

[nybble41]

If you upload a transaction to the recipient directly they can verify the message you provided makes sense, and only then broadcast the transactions and take the money.

While that is a nice touch from a UI / accessibility point of view, it's not quite what I meant. The problem is in the underlying protocol: transactions are considered valid when signed only by the payer. Under the proposed system, there is still nothing to prevent someone from uploading a transaction on their own without involving the merchant. The cases I had in mind are those like the political campaign which was accepting Bitcoin contributions a while back; they had specific rules regarding which kinds of contributions they could accept, but no way to block transactions which failed to meet those rules, and no reliable way to know whether it was safe to simply return the funds to the originating address--which may belong to a wallet or payment service or exchange rather than the contributor.

What I had in mind was essentially P2SH with two scripts, one to send from an address and another to endorse receipts. To receive funds you would take the incomplete transaction and add the address's receive script, a signature for the amount received, the memo field, and (optionally) the originating address(es), and then broadcast the updated transaction. For multiple payees, partial transactions could be merged until all the signatures are present, at which point the completed transaction can enter the blockchain. The private key for receipts could be different from the key for payments, so "cold storage" is not affected.

[Mike Hearn]

While that is a nice touch from a UI / accessibility point of view, it's not quite what I meant. The problem is in the underlying protocol: transactions are considered valid when signed only by the payer. Under the proposed system, there is still nothing to prevent someone from uploading a transaction on their own without involving the merchant.

That's true, but remember we're talking about the case of somebody who was/is being scammed. Uploading directly to the merchant has multiple advantages for them and no disadvantages, so why not make it the default. As long as they know roughly what to expect and the UI is clear, it can help raise the bar for scamming.

The cases I had in mind are those like the political campaign which was accepting Bitcoin contributions a while back; they had specific rules regarding which kinds of contributions they could accept, but no way to block transactions which failed to meet those rules

They did have such a way, only generate an address once necessary checks have been done. Because they weren't taking Bitcoin very seriously they just threw a static address onto a web page without thinking through the consequences. It's not much harder to do it right though, and these days companies like BitPay make it easy.

[SgtSpike]

If you upload a transaction to the recipient directly they can verify the message you provided makes sense, and only then broadcast the transactions and take the money.

While that is a nice touch from a UI / accessibility point of view, it's not quite what I meant. The problem is in the underlying protocol: transactions are considered valid when signed only by the payer. Under the proposed system, there is still nothing to prevent someone from uploading a transaction on their own without involving the merchant. The cases I had in mind are those like the political campaign which was accepting Bitcoin contributions a while back; they had specific rules regarding which kinds of contributions they could accept, but no way to block transactions which failed to meet those rules, and no reliable way to know whether it was safe to simply return the funds to the originating address--which may belong to a wallet or payment service or exchange rather than the contributor.

What I had in mind was essentially P2SH with two scripts, one to send from an address and another to endorse receipts. To receive funds you would take the incomplete transaction and add the address's receive script, a signature for the amount received, the memo field, and (optionally) the originating address(es), and then broadcast the updated transaction. For multiple payees, partial transactions could be merged until all the signatures are present, at which point the completed transaction can enter the blockchain. The private key for receipts could be different from the key for payments, so "cold storage" is not affected.

I think it'd be good for both types of transactions to co-exist (I do not understand your plan enough to know whether that is the case).  I would not want to have to approve each transaction in which I was the receiver - I want the money there and ready to be spent next time I am at my computer.  Most individuals probably share the same viewpoint.  From a business perspective, it makes sense to accept transactions, from a personal standpoint, maybe not so much.

Also, how would this affect sendmany transactions?  Every receiver has to sign off on it prior to acceptance into the blockchain?

[Boussac]

The police officer sounds like a cool guy, but you have NOT solved the problem.

You need to start verifying the identities of depositors and people withdrawing money from your exchange like Mt Gox and other operations do. Not only is this your protection against being an exit from the fiat system for criminals, but the law may sometimes require it too (depending on thresholds, etc).

Whilst the police officer was obviously nice to you, don't take it personally if they come back and charge you with something. You clearly know there's abuse of your service and you will be expected to stamp it out. ID verification is the way to do that, so get on it.

This.

Simply because Bitcon is cash online, the scammers aren't even SEEN performing their art. People are generally naive about payment systems and it all boils down to: do not deal in cash (bitcoin) with an online merchant you don't know, typically an individual that has not bothered to register with any administration.

For example, on instawire.org, in light of these recent reports, we will soon add a warning like:

When copying a bitcoin address in your wire information, please make sure the bitcoin address belongs to YOUR bitcoin wallet.
Do NOT copy a bitcoin address supplied by an online seller (doing so would create an opportunity for the seller to defraud you).

[Binford 6100]

I've implemented a new policy where we require bank transfers to include the message "For buying Bitcoins".

... and will return/refuse to accept incoming payments that will not include this message?

how long does it take for your bank to process this metadata on bank transfer? ('my' bank credits the account on day 1 but full transaction info appears only on day 2)
and how easy is it for you to return a payment?

[nybble41]

The cases I had in mind are those like the political campaign which was accepting Bitcoin contributions a while back; they had specific rules regarding which kinds of contributions they could accept, but no way to block transactions which failed to meet those rules

They did have such a way, only generate an address once necessary checks have been done. Because they weren't taking Bitcoin very seriously they just threw a static address onto a web page without thinking through the consequences. It's not much harder to do it right though, and these days companies like BitPay make it easy.

That isn't a complete solution, because addresses are not one-time-use. Once an address becomes publicly known (for example, by being mentioned in a transaction in the block chain), anyone can send to it. Individual contribution addresses would have helped, but it's still only a voluntary protocol; someone inclined to cause mischief could still send them funds which they cannot accept, since they have no data on the source, and which they cannot reliably return.

I think it'd be good for both types of transactions to co-exist (I do not understand your plan enough to know whether that is the case).  I would not want to have to approve each transaction in which I was the receiver - I want the money there and ready to be spent next time I am at my computer.

The idea was that this would be a superset of the existing transaction protocol. The receive script would be optional (or a standard accept-all script could be used) such that those who prefer the current style could have addresses which accept all incoming transfers.

However, even for those who want to sign off on receipts, there is no reason why you couldn't do that (for single-payee transactions) and still spend the money right way. As long as the incoming transfer only lacks your endorsement, you should be able to broadcast it and the outgoing transaction spending the funds at the same time. OpenTransactions requires payees to sign off on all funds received before the account balance is updated, and it really doesn't add very much overhead. It just presents a list of outstanding balance transfers to your account, and you go through the list and check off those you approve of.

Also, how would this affect sendmany transactions?  Every receiver has to sign off on it prior to acceptance into the blockchain?

Yes, the scripts for each output would have to be satisfied before the transaction would be considered valid, just each input scripts must be satisfied now. Ideally, partial transactions would be broadcast through the network to collect signatures, and those with different subsets of the required signatures (input and output) could be merged until the transaction is eventually completed and accepted into the blockchain.