<p>You should use a new address for each transaction, likely generated from an BIP32 extended public key (your #2).</p>

<blockquote>
  <p>I don't think this could be technically possible, as it is neccessary to derivate child key from master private key.</p>
</blockquote>

<p>Extended public keys can be derived from a parent public key if the Chain Code (256 bits) for that parent extended public key is known. Merchants should give you an extended public key and chain code, and then you can generate a new address for them each time. Note that your system wouldn't have any risk of exposing private keys, as you would only be using BIP32 extended public keys.</p>

<p>For technical information on BIP32, visit <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki" rel="nofollow">https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki</a>.</p>

CC BY-SA 3.0
2015-08-04T16:32:14.670Z
2015-08-04T16:32:14.670Z
morsecoder
<p>Lets have a scenario where POS software wants to support bitcoin payments with zero risk. Ideal is to store Merchant's Bitcoin address in POS settings.</p>

<p>The intention here is to uniquelly bind receipt in local POS Database with transaction hash on Blockchain, in order to know whether the receipt was already paid or not. </p>

<p>This is the scenario where Merchant generates QR Payment request with BTC price and recipient address. Some applications also pass a message but that is stored in internal memory and does not go to Blockchain.</p>

<p>I have came up with two possible algorithms.</p>

<ol>
<li><p>Reserve last several satoshis for temporary ID. e.g. 0.000000<strong>65</strong></p>

<ul>
<li><p>As most of direct (F2F) payments takes less then 2 minutes. It would be possible to generate shorterm ID and then check the Merchant's address for latest transaction, once the temp ID was found POS would mark the receipt as paid and remember the tx hash. This would prevent </p></li>
<li><p>Possibility to handle the case where the payment comes from multiple inputs by adding together the inputs for merchant address.</p></li>
<li>1 BTC would have to be atleast $100000 in order to break this.</li>
<li>Tipping would break this.</li>
</ul></li>
<li><p>HD wallet Generating from Bitcoin address</p>

<ul>
<li>Generate new address for each Receipt paid in bitcoin.</li>
<li>I don't think this could be technically possible, as it is neccessary to derivate child key from master private key. </li>
<li>How to achieve this with knowing only the Bitcoin address of merchant?</li>
</ul></li>
<li><p>Encode some message in ScriptPubKey OPRETURN </p>

<ul>
<li>customer side (depends on wallet they run).</li>
</ul></li>
</ol>

<p>Is there any other - better possibility that is still unknown for me?</p>

<transactions><blockchain><payment><point-of-sale>
POS Receipt payment identification
Marek
# POS Receipt payment identification

(Asked by: username_0 on 2015-08-04)

Lets have a scenario where POS software wants to support bitcoin payments with zero risk. Ideal is to store Merchant's Bitcoin address in POS settings.

The intention here is to uniquelly bind receipt in local POS Database with transaction hash on Blockchain, in order to know whether the receipt was already paid or not.

This is the scenario where Merchant generates QR Payment request with BTC price and recipient address. Some applications also pass a message but that is stored in internal memory and does not go to Blockchain.

I have came up with two possible algorithms.

1. Reserve last several satoshis for temporary ID. e.g. 0.000000**65**

   * As most of direct (F2F) payments takes less then 2 minutes. It would be possible to generate shorterm ID and then check the Merchant's address for latest transaction, once the temp ID was found POS would mark the receipt as paid and remember the tx hash. This would prevent
   * Possibility to handle the case where the payment comes from multiple inputs by adding together the inputs for merchant address.
   * 1 BTC would have to be atleast $100000 in order to break this.
   * Tipping would break this.
2. HD wallet Generating from Bitcoin address

   * Generate new address for each Receipt paid in bitcoin.
   * I don't think this could be technically possible, as it is neccessary to derivate child key from master private key.
   * How to achieve this with knowing only the Bitcoin address of merchant?
3. Encode some message in ScriptPubKey OPRETURN

   * customer side (depends on wallet they run).

Is there any other - better possibility that is still unknown for me?

**Tags:** transactions, blockchain, payment, point-of-sale


---

## 1 answers

### Answer by username_1 on 2015-08-04. Score: 2

You should use a new address for each transaction, likely generated from an BIP32 extended public key (your #2).

> I don't think this could be technically possible, as it is neccessary to derivate child key from master private key.

Extended public keys can be derived from a parent public key if the Chain Code (256 bits) for that parent extended public key is known. Merchants should give you an extended public key and chain code, and then you can generate a new address for them each time. Note that your system wouldn't have any risk of exposing private keys, as you would only be using BIP32 extended public keys.

For technical information on BIP32, visit <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>.


---

