Bitcoin he-said she-said, or, will digitally signed payment requests be needed?

[Stephen Gornick]

Bitcoin, being a digital currency that can be used anonymously, introduces challenges in numerous ways.

One area where using Bitcoin is a challenge is when there is a dispute regarding a payment.  Traditionally, payment records are used to support a customer's claim during a dispute.  If that payment was made using a credit card or bank transaction, that information can be verified from those external sources, if necessary.  If the payment was made using cash, usually the customer is provided a receipt for the transaction at the time of purchase.

If I pay using bitcoin and my trading partner wishes to defraud me, there are ways to do so.  For instance, I cannot prove the address that I sent my payment to was truly an address provided to me by my trading partner.

Another instance is where a counterparty claims to have sent funds to me where there's little I have available to prove that if funds were truly sent, they didn't end up at an address that I had provided.

So if in a dispute if the two parties aren't cooperating with each other, it essentially becomes a he-said she-said as to what actually happened.

This likely is a factor contributing to keeping merchants hesitant to start accepting bitcoins.  The last thing a merchant wants is some dishonest person (or a disgruntled customer) claiming the payment was sent and then the merchant has a hard time coming up with a rock-solid defense that the funds were never really sent.  The customer can't prove it was and the merchant can't prove it wasn't.

Will all payment requests need to be digitally signed? [Edit: i.e., using GPG or some other signing / certificate method?]

In the example above, if the customer requires the payment request to be digitally signed by the merchant then the blockchain gives evidence that that merchant's payment request was fulfilled.  If the merchant provides a payment request only after digitally signing it, then a dishonest customer claiming funds were sent would be harder pressed to explain where the address came from (i.e., can't simply photoshop a screenshot, for instance).

Or does the fact that cash has many of the same problems mean that this isn't different enough to warrant any change in procedure?

[sunnankar]

Another instance is where a counterparty claims to have sent funds and there's little I have available to prove that if funds were truly sent, they didn't end up at an address that I provided.

So if in a dispute if the two parties aren't cooperating with each other, it essentially becomes a he-said she-said as to what actually happened.

Isn't this what the signed message in the new client is all about? Thus, you get the cooperation before the transaction and then afterwards it obviates the need for a he said she said.

[grue]

>public GPG key is displayed merchant website
>payment address along with the terms of the transaction are signed by the merchant
that would work well.

[Stephen Gornick]

Isn't this what the signed message in the new client is all about? Thus, you get the cooperation before the transaction and then afterwards it obviates the need for a he said she said.

No, that just ensures that a message was signed by the owner of that bitcoin address.  

That doesn't help me to prove that the merchant truly requested payment to that address.   If addresses were static, then I could be reassured that since others were successfully using that address for payments that I could use it as well, but since Bitcoin only works when there is a different address for each payment then I see the situation where payment is made and then the merchant claims that the address isn't theirs and they aren't sure how or why the customer sent payment to that address.

[grue]

Isn't this what the signed message in the new client is all about? Thus, you get the cooperation before the transaction and then afterwards it obviates the need for a he said she said.

No, that just ensures that a message was signed by the owner of that bitcoin address. 

That doesn't help me to prove that the merchant truly requested payment to that address.   If addresses were static, then I could be reassured that since others were successfully using that address for payments that I could use it as well, but since Bitcoin only works when there is a different address for each payment then I see the situation where payment is made and then the merchant claims that the address isn't theirs and they aren't sure how or why the customer sent payment to that address.

hence why it's preferable to use GPG.

[Gavin Andresen]

We need a payment protocol with non-repudiation built in.

See https://gist.github.com/2217885 for a multisig version (the singlesig version is simpler, but the merchant <-> customer communication will be the same).

[muyuu]

I think GPG should be popularised whenever possible, it doesn't rely on something exclusive to Bitcoin.

[trentzb]

We need a payment protocol with non-refudiation built in.

See https://gist.github.com/2217885 for a multisig version (the singlesig version is simpler, but the merchant <-> customer communication will be the same).

FTFY

When Stephen posted this earlier I started banging my head trying to figure out a solution to the scenario he depicted. I failed, I visited this scenario a year ago and still didn't have an answer. I think he is teasing me to use my brain better as he likely understands Bitcoin scripting better than I or many of us. Give us the answer Stephen!!

Regardless, when he mentioned this again today and even when I thought about it a year ago...MultiSig or a derivative seemed like the only answer...it still does.

I am confident that there is a way to execute escrow solely between two parties for everyday common transactions.

Will keep banging my head on the desk to figure out how.

[Stephen Gornick]

Give us the answer Stephen!!

Ha, I have only questions.

Well, actually I have scenarios and have no solution to offer.

Take the current lawsuit against Bitcoinica.  How do the plaintiffs prove they sent even a single satoshi to Bitcoinica?  

The areas where a payment protocol might be used theoretically applies to nearly every transaction but practically that need doesn't arise very often.  It definitely isn't needed for buying a donut:
 - http://www.youtube.com/watch?v=X53ksjejmns

I probably don't need a digitally signed payment request from Amazon because if their payment page didn't acknowledged my payment my next action is to contact their support.  If their system is compromised where I get a fake payment acknowledgement they'll know about the problem long before I notice that nothing showed at my door.

But for transactions where where there is a time component, such as where the payment creates or extinguishes a debt, that's where in practice this protocol becomes more needed.  

If I send payment to be applied to my credit card balance, I want to be able to prove they got the payment.  That's when I'm going to want them to give me a signed message that not only says what Bitcoin address to send my payment to but the account number that the payment will be applied to as well.

With the blockchain providing the proof that payment was made, this signed payment request from before I pay is all I need then to later prove that I made the payment.

We need a payment protocol with non-repudiation built in.

See https://gist.github.com/2217885 for a multisig version (the singlesig version is simpler, but the merchant <-> customer communication will be the same).

From a cursory look into e-signatures it took just minutes to conclude one thing ... what a mess!  So even though you and I know that nobody other than the holder of the private key for a Bitcoin address could have produced a signed message, would having that even help the plaintiffs one iota in a lawsuit such as the one referenced above?

There are standards for e-signing that are enforceable but these standards aren't universal around the world, and they can vary state-to-state in the U.S. even.   So it is possible that even if Bitcoin supported this protocol, those needing e-signature would probably implement it outside of Bitcoin in the manner needed for the relevant jurisdiction(s).

That being said, if there were a protocol built in and it were to become generally adopted, it would probably find itself becoming a legally recognized method shorly after as well.

[thezerg]

Isn't this what the signed message in the new client is all about? Thus, you get the cooperation before the transaction and then afterwards it obviates the need for a he said she said.

No, that just ensures that a message was signed by the owner of that bitcoin address.  

That doesn't help me to prove that the merchant truly requested payment to that address.   If addresses were static, then I could be reassured that since others were successfully using that address for payments that I could use it as well, but since Bitcoin only works when there is a different address for each payment then I see the situation where payment is made and then the merchant claims that the address isn't theirs and they aren't sure how or why the customer sent payment to that address.

Maybe we should re-assess this assumption... it is certainly not intuitive.  Perhaps allow a transaction to contain an arbitrary 4 byte field that the payer can tell the payee to use... so a payment "address" with txn id could look something like: 16QUrEh1Tw8BFnzyCQn9jVtaYLHfUYWyZx-12345678

[sunnankar]

Well, actually I have scenarios and have no solution to offer.

....

That being said, if there were a protocol built in and it were to become generally adopted, it would probably find itself becoming a legally recognized method shorly after as well.

Oh, I think I understand your issue now. I have been helping a few people with some .... large transactions. With the real estate transaction the Seller of the property is providing the BTC address for payment in the documents to the escrow agent. Sure, this escrow agent handles unusual transactions, one involving like 10+ chimpanzees a few years ago, but that is one work around or possible solution.

I am sure the problem could be solved with an online solution but it may take a third party or network where a payor assets an address for payment and payees can check or verify that a wallet address belongs to the payor.

By analogy, the individual assets that X LLC exists with Y being the registered agent and the other party can verify via the Secretary of State website that X LLC exists and who the registered agent. A similar method could be implemented where X LLC provides a central location, whether a party or network, with a public key and then on X's website can assert they control a particular wallet for payment purposes and the payee can verify. I would think a protocol could be built to accomplish this.

[Serenata]

>public GPG key is displayed merchant website
>payment address along with the terms of the transaction are signed by the merchant
that would work well.

GPG sounds good (although not 100% safe - see below) and I'd go one step beyond. The merchant should email the client the GPG-signed payment request. An email message is enough of a proof in many countries and if the client did send the coins to the requested address (proof in blockchain), then the problem is with the merchant. Of course the client should verify the GPG signature before sending coins (supposing his device is compromised and displays another bitcoin address). 

But even this, will not work if the client's compromised system would:
fake the bitcoin address displayed in the browser AND fake the bitcoin address displayed in the email message AND fakely show the GPG-signed message as valid. In that case though, it would be the client's fault.