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!

baynard
  • 11
  • 1

2 Answers2

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.

chytrik
  • 18,170
  • 3
  • 19
  • 48
  • 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 00: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 00: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.

JBaczuk
  • 7,388
  • 1
  • 13
  • 34
  • 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!) –  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 00:45
  • @chytrik Electrum has a point-&-click interface for decrypting messages that have been encrypted with a Bitcoin address (obviously, only if the corresponding private key is in the wallet!). It doesn't need the internet to do this, so the technique works for cold-storage wallets as well as for “hot" wallets. –  Aug 21 '18 at 11:15
  • @bayard I think you mean embedding a payment ID in a Bitcoin transaction. Technically possible, but not commonly done (so perhaps tricky for customers). Other cryptocurrencies (XRP, Monero) do have this feature, and it's used a lot by businesses that accept deposits of these currencies. But for Bitcoin, the convention seem to be that the business does not publicly declare a receiving address: rather, it assigns a different address (from its own wallet) to each customer, and instructs each customer accordingly. Perhaps that's what you really want (rather than formal cryptographic proof!). –  Aug 21 '18 at 11:28
  • @TEV thanks this is super helpful. I want to go with bitcoin so I think assigning a different address to each customer will be the most secure and easiest ux solution – baynard Aug 21 '18 at 13:28
  • A hierarchical deterministic wallet could be what you want. It gives you thousands of addresses in your wallet, so you can label a spare address with customer's name every time you acquire a new customer. The hierarchical deterministic thing simplifies your backup system since you just have one seed-phrase (on paper in a safe?) to back up all those addresses. For fraud-resistant storage of the seed phrase, check out Shamir's Secret Sharing Scheme (the digital version of having several people each knowing only part of a combination lock). –  Aug 21 '18 at 14:33
  • @TEV I didn’t know electrum has that functionality! My mistake, thanks for clarifying. – chytrik Aug 21 '18 at 15:37
  • @chytrik I'm not quite right (at least, not for BTC, so I may have been thinking of XRP). As explained here you can't get the public key from the address alone. On the other hand, it doesn't do any harm for the owner of the address to disclose the public key to people from whom they want to receive encrypted messages. The Electrum message-encryption box asks for a public key. Bottom line: the idea is valid but actually using it is slightly convoluted. –  Aug 21 '18 at 16:24
  • Hit a hurdles with unique addresses for customers integrating into our app without a lot of reinvention of the wheel....what about a slight variation on above...i) customer messages id# (x = id) ii) we message back y id# (x + y = PIN) iii) customer makes deposit and messages deposit amount and their PIN iv) Customer can only access account if they have PIN. Since PIN is generated before deposit anyone following block chain will only see deposit amount but not have PIN to use. Practical issues, logic flaws, other flaws in approach...THXS! – baynard Aug 21 '18 at 18:24