Topic: I entered the police station as a suspect. When I left the officer loved Bitcoin - page 2. (Read 12913 times)

P2SH already works that way. The sender of the funds makes an incomplete transaction which says "these inputs can now be spent if someone provides a valid script with this hash" If you want to receive those funds and send them somewhere else you take that incomplete transaction (called the first transaction on Bitcoin) and complete it with a second transaction to send the funds where you want.

I mean, seriously though you're arguing semantics. Ultimately Bitcoin allows you to put money in electronic lockboxes that can be opened by anyone with the correct key. Sure it looks like you're "sending" money on blockchain.info because it shows things in terms of account balances, but an equally valid way of looking at it is "I happen to have the correct key(s) to open these lockboxes" You can come up with window dressing to hide that fact, but fundamentally that is how Bitcoin works. We're better off it courts understand this - it's not much different than me calling you up and leaving a message on your voicemail with the secret account numbers of a swiss bank account.

For instance, I'm going to tell you right now that there is a unspent transaction on the blockchain that can be spent with the private key 0000000000000000000000000000000000000000000000000000000000000001 - I just sent you money, and you can't refuse it!

one problem with this is that real customers who are actually buying bitcoins, might not want such an explicit record of that fact in their bank statement.

While I do not think talking to police is usually a very good idea; in this case, you may want to even go and talk with the same police officer, let him know of the change you implemented and ask if he has any other suggestions that would make your system less prone to fraud.

Then he will know you are attempting to act in good faith and you will likely get a helpful tip or two since it sounds like he investigates a lot of credit card fraud and has likely seen all types of schemes.

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.


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.


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.

... 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?

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).

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?

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.


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.

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.

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.

Smart.

I've implemented a new policy where we require bank transfers to include the message "For buying 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.

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

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.

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.


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.


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

https://bitcointalksearch.org/topic/invoicespaymentsreceipts-proposal-discussion-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.

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?

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.

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.)

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.