Identificación de pago de recibo de POS

Tengamos un escenario en el que el software POS quiera admitir pagos de bitcoin sin riesgo. Lo ideal es almacenar la dirección de Bitcoin del Comerciante en la configuración de POS.

La intención aquí es vincular de forma única el recibo en la base de datos POS local con el hash de transacción en Blockchain, para saber si el recibo ya se pagó o no.

Este es el escenario en el que el comerciante genera una solicitud de pago QR con el precio BTC y la dirección del destinatario. Algunas aplicaciones también pasan un mensaje pero eso se almacena en la memoria interna y no va a Blockchain.

Se me han ocurrido dos posibles algoritmos.

  1. Reserve los últimos satoshis para una identificación temporal. por ejemplo, 0.000000 65

    • Como la mayoría de los pagos directos (F2F) tardan menos de 2 minutos. Sería posible generar una identificación más corta y luego verificar la dirección del comerciante para la última transacción, una vez que se encontró la identificación temporal, POS marcaría el recibo como pagado y recordaría el hash tx. Esto evitaría

    • Posibilidad de manejar el caso en el que el pago proviene de múltiples entradas sumando las entradas para la dirección del comerciante.

    • 1 BTC tendría que ser al menos $ 100000 para romper esto.
    • Las propinas romperían esto.
  2. Monedero HD Generado a partir de una dirección de Bitcoin

    • Generar nueva dirección por cada Recibo pagado en bitcoin.
    • No creo que esto sea técnicamente posible, ya que es necesario derivar la clave secundaria de la clave privada maestra.
    • ¿Cómo lograr esto conociendo solo la dirección de Bitcoin del comerciante?
  3. Codificar algún mensaje en ScriptPubKey OPRETURN

    • lado del cliente (depende de la billetera que ejecuten).

¿Hay alguna otra posibilidad mejor que aún me sea desconocida?

Respuestas (1)

Debe usar una nueva dirección para cada transacción, probablemente generada a partir de una clave pública extendida BIP32 (su #2).

No creo que esto sea técnicamente posible, ya que es necesario derivar la clave secundaria de la clave privada maestra.

Las claves públicas extendidas se pueden derivar de una clave pública principal si se conoce el código de cadena (256 bits) para esa clave pública extendida principal. Los comerciantes deben darle una clave pública extendida y un código de cadena, y luego puede generar una nueva dirección para ellos cada vez. Tenga en cuenta que su sistema no tendría ningún riesgo de exponer claves privadas, ya que solo estaría utilizando claves públicas extendidas BIP32.

Para obtener información técnica sobre BIP32, visite https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki .