Pages:
Author

Topic: How to prove that the sender for a payment was truly me? (Read 4488 times)

hero member
Activity: 955
Merit: 1002
A third party website 'claimaddress.com' could allow anyone to claim any address -  by the claimant sending bitcoins to the 3rd party and and the 3rd party returning those bitcoins back to the claimed address. The biggest claimant would 'own' the address, and the real owner would receive all the btc back if other people wanted to claim it and could use those bitcoins again to up the claim. If it was associated with a user id, you could have a reasonable system of proving ownership of any address - even before you use it.
hero member
Activity: 518
Merit: 500
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?

Can't wait for this. Yet more blockchain bloatware. It is almost 1GB now and that is HUGE for some people like me. People in LEDCs where the net is limited will not be able to afford to download this big a blockchain and yet you propose even more data in it Huh Does not make sense to me.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Far easier and user friendly for merchant to just use a one time payment address per order.
member
Activity: 80
Merit: 10
Maybe I'm misunderstanding the exact nature of the problem, but couldn't you just have a stop-gap by displaying the send address(es) in a confirmation dialog of the client?

Like when you send coins and click 'send', a dialog pops up that says:
You are about to send 15 BTC from address:
[mySendAddress(es)]
to:
[recipientAddress]

Ok    Cancel

(I'm not sure if there is a confirmation dialog already.)

Then you would just stop at the dialog, send your addresses to the recipient, and some time later click "Ok".
donator
Activity: 1218
Merit: 1079
Gerald Davis
Oops. Still, a unique address for the recipient for each transaction could work as has been suggested.

Yeah that is the easiest method however it doesn't give the buyer proof he paid.  He must trust the seller.  If he then came to Bitcoin forum it would be a he said / she said.  If buyer could include proof of payment in block stream via a hash or signed message then it would provide evidence of payment.  I like hash better because it has no meaning unless you know what the plain text is and that keeps anonymity.
member
Activity: 84
Merit: 10
Oops. Still, a unique address for the recipient for each transaction could work as has been suggested.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Could just have the shopping cart ask which address you will use on check out. Merchant sees the address on the receipt, sees the same address with the transaction, and knows it came from you. That and unique addresses as suggested seems like it would work pretty well.

The mainline client doesn't let you pick which address you will send from.
member
Activity: 84
Merit: 10
Could just have the shopping cart ask which address you will use on check out. Merchant sees the address on the receipt, sees the same address with the transaction, and knows it came from you. That and unique addresses as suggested seems like it would work pretty well.
donator
Activity: 1218
Merit: 1079
Gerald Davis
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.

Hash functions are irreversible by definition.

Yes however if your provided the seller or a third party the same information they could recreate the hash

For example if a transaction to your Bitcoin address includes an hash that can be produced by hashing the following mesage:
"This is a payment from DeathAndTaxes to notme" then it is kinda hard for (or someone else) to lie and say that transaction was from someone else.
legendary
Activity: 1904
Merit: 1002
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.

Hash functions are irreversible by definition.
full member
Activity: 372
Merit: 114
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.
legendary
Activity: 2506
Merit: 1010
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
donator
Activity: 1218
Merit: 1079
Gerald Davis
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. Smiley  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.
donator
Activity: 1736
Merit: 1014
Let's talk governance, lipstick, and pigs.
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/[email protected]/msg00262.html

This would be like a postage stamp with a value in bitcoin?
legendary
Activity: 2506
Merit: 1010
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/[email protected]/msg00262.html
member
Activity: 90
Merit: 10
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.
legendary
Activity: 1222
Merit: 1016
Live and Let Live
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. Smiley  Don't include the message in the block chain, just send it over whatever medium you normally communicate with.
hero member
Activity: 616
Merit: 500
Firstbits.com/1fg4i :)
Can't you send a piece of text with every transaction? Just write "I sent this" and PGP sign it.
newbie
Activity: 42
Merit: 0
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) https://bitcointalksearch.org/topic/how-do-i-know-who-paid-me-4220
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
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.
Pages:
Jump to: