How to prove that the sender for a payment was truly me?

[Stephen Gornick]

Let's say there is a scenario where I am one of two different people who claim to be responsible for sending bitcoins for a purchase.  How could I prove to the merchant that those bitcoins came from my wallet and nobody else's?

I was considering that I could sign a message using the address' private key, as described here,
http://bitcointalk.org/index.php?topic=2373.40
however in my scenario, I assume the merchant is non-technical and that this purchase isn't significant enough to warrant climbing the PKI learning curve.

I then considered the ability to send another amount, say a token 0.01 BTC, from the same address that my earlier payment originated from.  Even if I were able to force bitcoin to use a specific address for the input for the transaction, that transaction would then be recognized as an attempt to double spend and thus wouldn't be honored or relayed by any nodes.

Are there any other options for this?

[1713486608]

1713486608

[1713486608]

1713486608

[1713486608]

1713486608

[1713486608]

1713486608

[1713486608]

1713486608

[dirtyfilthy]

It'd be pretty sweet to be able to include a short message with your transaction. While I guess this message would be pubically readable (i.e. in the blockchain) it'd be good for reference numbers and the like. There's no reason why this technically couldn't happen right?

[casascius]

I then considered the ability to send another amount, say a token 0.01 BTC, from the same address that my earlier payment originated from.  Even if I were able to force bitcoin to use a specific address for the input for the transaction, that transaction would then be recognized as an attempt to double spend and thus wouldn't be honored or relayed by any nodes.

If you were able to force Bitcoin to spend from a specific address, and the person asking for proof first sent 0.01 BTC to that address to send back, then it wouldn't need to be a double spend.

[Raulo]

The best way for the merchant is to specify a different address for each transaction known to one person only.

[theymos]

You could create a new address, give that to the merchant, and tell them an exact time at which you will transfer from the address in question to the new address. You can cause Bitcoin to send using a particular address like this:
- Send some unusual amount (like 54.37) to the address in question.
- Wait for 6 confirmations.
- Send that same unusual amount to the new address.
(You might have to do this a few times before Bitcoin chooses the right coin, though I think it will usually pick the right one.)

[Gavin Andresen]

Let's say there is a scenario where I am one of two different people who claim to be responsible for sending bitcoins for a purchase.  How could I prove to the merchant that those bitcoins came from my wallet and nobody else's?

Something like this is possible (I've been thinking about doing it, although I have higher priority things on my TODO list):

• Sophisticated user runs a tool on her computer that, giving the bitcoin address payment was sent to and "here's a description of me or what I paid for" string.  Tool looks in the wallet.dat and figure out which keypair(s) were used to pay.  Then it does some openssl magic and exports a file that contains the string, the public keys and ECDSA signatures using the private keys of the "description of me or what I paid for" string.
• Sophisticated user uploads that file to a "Prove I Paid" website, which checks the signatures and adds info to the database.
• Unsophisticated user goes to website and pastes the receiving address.  The public key corresponding to that address is looked up, and all the "here's a description of me or what I paid for" strings for that public key are shown.

bitcointools+openssl (see grondilu's thread about "a shell-script implementation of bitcoin) are enough to do all all the public/private key, file-creation, and signature generation/checking stuff.

[JollyGreen]

Let's say there is a scenario where I am one of two different people who claim to be responsible for sending bitcoins for a purchase.  How could I prove to the merchant that those bitcoins came from my wallet and nobody else's?

Something like this is possible (I've been thinking about doing it, although I have higher priority things on my TODO list):

• Sophisticated user runs a tool on her computer that, giving the bitcoin address payment was sent to and "here's a description of me or what I paid for" string.  Tool looks in the wallet.dat and figure out which keypair(s) were used to pay.  Then it does some openssl magic and exports a file that contains the string, the public keys and ECDSA signatures using the private keys of the "description of me or what I paid for" string.
• Sophisticated user uploads that file to a "Prove I Paid" website, which checks the signatures and adds info to the database.
• Unsophisticated user goes to website and pastes the receiving address.  The public key corresponding to that address is looked up, and all the "here's a description of me or what I paid for" strings for that public key are shown.

bitcointools+openssl (see grondilu's thread about "a shell-script implementation of bitcoin) are enough to do all all the public/private key, file-creation, and signature generation/checking stuff.

Awesome idea, I've been thinking of different ways to do this, because it seems the thing holding bitcoin back the most is no ability to build up a web of trust without having +20 to nerd skills.  I think all of this could be made very easy for anyone to do thru the proper GUI, but it seems the easiest place to start would be to build a few basic commands into bitcoind so we don't have to have random tools looking thru peoples' wallets.  Does that sound good?

I would be interested in integrating these message signing commands into bitcoind, if you don't have time.

[Stephen Gornick]

You could create a new address, give that to the merchant, and tell them an exact time at which you will transfer from the address in question to the new address. You can cause Bitcoin to send using a particular address like this:
- Send some unusual amount (like 54.37) to the address in question.
- Wait for 6 confirmations.
- Send that same unusual amount to the new address.
(You might have to do this a few times before Bitcoin chooses the right coin, though I think it will usually pick the right one.)

Ah ... got it.

I suppose the amount could be any amount (e.g., just 0.01 BTC) as long as I've emptied my wallet (down to 0 BTC) first.

[theymos]

I suppose the amount could be any amount (e.g., just 0.01 BTC) as long as I've emptied my wallet (down to 0 BTC) first.

Emptying your wallet would also work, but if you create an output with the exact value that you will use for an input, Bitcoin will choose that specific output to use for the input, and it'll use the correct address without having to send everything.

[casascius]

The best way for the merchant is to specify a different address for each transaction known to one person only.

This is an excellent and preferable idea before the payment is made.

Once the payment has been made, the address is part of the block chain and is no longer private.  If the amount, and/or especially the time of the transaction is known, then identifying the address is trivial.

[casascius]

I would be interested in integrating these message signing commands into bitcoind, if you don't have time.

A simple function that merely exposed a "Sign this hash with this address" capability would be more than sufficient for many purposes.

the return value would either be "here is the signature", or "I don't have a private key for that address"...

perhaps there's room in the signature for a "This is a message, not a transaction" flag, so one couldn't abuse the feature to entice people into unknowingly signing transactions.  perhaps this would be unnecessary or infeasible.

[we6jbo]

I've argued something similar to this before and I'll start by admitting that there were holes in my argument. What I would like to see is a way to show upon transaction that the sender was me and to also allow a 3rd party to see that the payment was from me. When I say me I don't necessary mean that me should be validated by a government ID rather it should be something that some people would accept as identity. In addition, the reason why I would want this in the transaction is so that it will be difficult to show that the transaction was not made by me. For example, I could have stolen someone elses bitcoin wallet and said that I made the transaction when I didn't. I'm not necessary saying that this is the approach that should be taken. I could be completely wrong again in my argument, however I do know through a previous thread that it is possible to send data along the side of a transaction without changing the bitcoin protocol and one of the ideas that I was thinking of at the time which would support my argument was that a transaction could also include your GPG key which would then be your identity and you could prove to the receiver of the bitcoin and to any 3rd party that it was your transaction simply by signing that it was you.

Edit: Here's the topic that I was referencing
Development & Technical Discussion: Topic: How do I know who paid me?  (March 06, 2011) http://bitcointalk.org/index.php?topic=4220.0

[TiagoTiago]

Can't you send a piece of text with every transaction? Just write "I sent this" and PGP sign it.

[da2ce7]

It'd be pretty sweet to be able to include a short message with your transaction. While I guess this message would be pubically readable (i.e. in the blockchain) it'd be good for reference numbers and the like. There's no reason why this technically couldn't happen right?

It would be pretty cool if the client could sign a message with your payment, an the client could verity that signature.   Don't include the message in the block chain, just send it over whatever medium you normally communicate with.

[bencoder]

You could "prove" it's you after the fact by looking at the transaction in block explorer and seeing which addresses/inputs the coins were sent from or the output the change was returned to(The address in the outputs that isn't the one you sent coins to).

You could then send a large (significant enough that the other party would be satisfied that you're not just sending the coins to somebody else in order to "prove" that the address is yours) but unusual amount to one of those addresses after telling the other person how much it will be.

[Stephen Gornick]

To provide a bookend to this thread, v0.5 of the Bitcoin client has as one of the features: "sign/verify a message with a wallet public/private keypair"
 - http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00262.html

[cbeast]

To provide a bookend to this thread, v0.5 of the Bitcoin client has as one of the features: "sign/verify a message with a wallet public/private keypair"
 - http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg00262.html

This would be like a postage stamp with a value in bitcoin?

[DeathAndTaxes]

It'd be pretty sweet to be able to include a short message with your transaction. While I guess this message would be pubically readable (i.e. in the blockchain) it'd be good for reference numbers and the like. There's no reason why this technically couldn't happen right?

It would be pretty cool if the client could sign a message with your payment, an the client could verity that signature.   Don't include the message in the block chain, just send it over whatever medium you normally communicate with.

Better yet just encrypt it with the receiver's public key.  The message is in the block chain and only the person receiving the funds can see it.

[Stephen Gornick]

This would be like a postage stamp with a value in bitcoin?

Not quite.  Simply gives the ability to "sign a message" on one side and to "verify the signature" on the other.
 - http://github.com/bitcoin/bitcoin/pull/524

[hashcoin]

Easy hack: write up a "receipt" containing whatever info you want (payer, payee, what payment is for, etc).  Hash it, turn that hash into a bitcoin address, and add that as a tiny 0.001 BTC output to the TX.

In retrospect it would have been wise for TX structure to contain a memo field, to bridge from the world where smart-contracts are possible to the rest of the world where some kind of human/out-of-band parsing is needed.