1

Newb, apologies if this is a dumb question. If a bitcoin is sent to my wallet is there a way the sender can use any part of the blockchain/transaction as a unique identifier so they can claim a credit in the future for the amount sent, that is, without assigning them any additional identifying information to them? (e.g. You send me a bitcoin, I treat it as a credit. You can claim the credit by using some combination of the numbers used in the transaction, so I can credit you the amount sent, without assigning any additional information to you, and no one else could be privy to that identifying information. Thank you for the help!

1

This is possible, but your customers will have to use a wallet that supports the functionality of signing messages using the wallet’s private keys. For example, bitcoind has the signmessage command. The user could input a message such as ”todays date is ____, and I control bitcoin address ____, which sent coins to ____ service” in order to prove their identity.

Using any identifying info from the transaction itself will not be a good way to prove user identity, since all transaction details are a matter of public record.

Note: By utilizing this functionality, you will be restricting your potential user-base to only more knowledgeable users. Not all wallets have this functionality, in fact most do not. If a user happens to sends bitcoin from a wallet that cannot sign messages, they can prove their identities by importing the private key into some other software that is capable and then using it to sign a message— but again this is a more ‘advanced user’ sort of operation.

Another note: DO NOT build a service which requires users to communicate their private key to you. This would be an irresponsible thing to do.

  • Thank you very helpful. We are a business that wants to be able to take bitcoin payments on account for future orders. It works well with our model. Perhaps, we need to communicate a unique customer number to them independently of their deposit? – baynard Aug 20 '18 at 20:41
  • @baynard I think that could work, so long as the identifying number is generated, communicated, and stored securely. It does open up some additional considerations though: You wouldn’t want an employee with access to your backend able to falsely claim a large deposit, you wouldn’t want the algorithm that generates identifying numbers to be game-able, etc – chytrik Aug 20 '18 at 22:41
  • I wanted to ask you too about a more old school variation on TEV's idea (forgive me if I'm missing something fundamental, my business is trying to accept bitcoin but I have very limited knowledge re. bitcoin, (i) customer sends bitcoins (ii) customer texts using Signal/other encrypted messaging app a unique number THEY generate (iii) customer makes payments from their deposit using their unique number. If approach works I can build better flow and ux into our platform. Do you see any issues/security, etc with this less artful approach? Matching customer with deposit? Thxs again! – baynard Aug 21 '18 at 0:37
  • @baynard I replied to this on JBaczuk’s answer. As another option that is more straightforward: if your customers can create any sort of account on your site, you could simply generate a unique deposit address for each account. This would remove the need to prove ownership of an address that made a deposit, users would instead simply need to maintain ownership of an account. This is a pretty standard model for a custodial service/site. – chytrik Aug 21 '18 at 0:50
0

is there a way the sender can use any part of the blockchain/transaction as a unique identifier so they can claim a credit in the future

The only secure unique identifier is a private key used to send the funds (or a digital signature proving ownership of that key).

If I understand you correctly, you want to give someone credit for sending bitcoin. The only way to be sure that a specific person sent you bitcoin is for them to provide proof that they own the private key that sent it. This could mean either showing you the private key (usually not preferred, because now its exposed), or digitally signing a message (that you provide) with the same key that was used to pay you. And even this doesn't prove that they sent it, it just proves they have access to the key that was able to send it.

The problem is the entire blockchain is public so anyone can look up the transaction and provide data about it like the txid or the block it was in, even an exact amount, and pretend they sent it.

Note: By the way there is an RPC method signmessage in bitcoin core that could be used to do this, see https://bitcoincore.org/en/doc/0.16.2/rpc/wallet/signmessage/

Update: As mentioned in the comments, generating a new Bitcoin address for each customer, which you only need to share with them, would be a decent (and common) way of tracking payments. If someone else found out about the address and sent funds, only the customer you assigned that address to would get credit. This would best be implemented as a Hierarchical Deterministic wallet so your keys can all be generated from a master key.

  • Thank you. Your answer is a helpful elaboration. We are a business that wants to be able to take bitcoin payments on account for future orders. It works well with our model. Perhaps we need to communicate a unique customer number to them independently of their deposit, or is their some other secure way of doing this without using the signmessage method, as per other other answer, this might limit customers? – baynard Aug 20 '18 at 20:46
  • You could develop wallet software that will handle the signing so there is a good UX. However, as @chytrik noted, you don't want to require users to expose public keys (for ECDLP attack prevention). I guess you could warn them so that they can create a single address just for this tx. – JBaczuk Aug 20 '18 at 21:03
  • A minor variation on the theme of signing is as follows. (i) Customer sends you bitcoins. (ii) You encrypt an arbitrary text using customer's Bitcoin address (you know their address since it's visible in your wallet as the source of the incoming bitcoins). (iii) You email the encrypted text to the customer, with instructions on how they can decrypt it in their wallet. (iv) Customer emails you back with the decrypted text, thus proving that they own the address. But, this will work only if the customer uses a non-custodial wallet (custodial wallet = no access to private keys!) – user58807 Aug 20 '18 at 21:58
  • @TEV what about a more old school variation on your theme (forgive me if I'm missing something fundamental, my business is trying to accept bitcoin as a payment method but I have very limited knowledge when it comes to bitcoin, (i) customer sends bitcoins (ii) customer texts using Signal or other encrypted messaging app a unique number THEY generate (iii) customer makes payments from deposit using their unique number. If the approach works we can build a better flow and ux into our platform. Do you see any issues/security, etc with this less artful approach? Thank you again! – baynard Aug 20 '18 at 23:56
  • @baynard anyone watching the blockchain for payments to your service could also send a message claiming they own that deposit, so this doesn’t solve the issue of proving ownership of a deposit. The method @ TEV suggested would work, but I don’t know of any wallet that will decrypt messages encrypted with a bitcoin public key. Importing a private key into some other cryptographic software to deal with the decryption creates risks for your customer, so I think using the message signing functionality is a better solution – chytrik Aug 21 '18 at 0:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.