Actualización automática de filtro BIP 37 sin insertar salidas

Tengo un problema con los filtros de floración cuando uso el mensaje getdata .

Según entiendo BIP 37, establecer el filtro de floración en una conexión usando el mensaje de filtro de carga con el indicador BLOOM_UPDATE_P2PUBKEY_ONLY establecido, el cliente que responde inserta automáticamente todos los puntos de salida (TXID e índice de salida) en el filtro de floración de las transacciones que coinciden con el filtro. Sin embargo, cuando intento hacer exactamente esto, el nodo solo envía transacciones que contienen salidas A la dirección que estoy filtrando, nunca transacciones que contienen salidas DE la dirección que estoy filtrando.

Mi enfoque es el siguiente:

  1. Agregue la siguiente clave pública al filtro de floración: 1JbFvyaMyHHmvvjc54h4YARq3uoX2ZZ4Qj (elegido al azar)
  2. Envíe el mensaje filterload que contiene el filtro (como se ve en el fragmento de código de wireshark a continuación).

    Bitcoin protocol
    Packet magic: 0xf9beb4d9
    Command name: filterload
    Payload Length: 261
    Payload checksum: 0x2bb02c45
    Filterload message
        Filter
            Count: 251
            Data: 000000040004010000000100000000000000020000400000...
        nHashFunc: 13
        nTweak: 0x1a689ff4
        nFlags: BLOOM_UPDATE_P2PUBKEY_ONLY (0x02)
    
  3. Envíe el mensaje getdata con el hash de todos los bloques que contienen transacciones hacia y desde la billetera (que identifiqué en un explorador de bloques con el fin de probar esto). Los inventarios se escriben MSG_FILTERED_BLOCK .

El nodo responde con los siguientes mensajes en orden:

MerkleBlock: 000000000000000001201ab2679db7c87a432967c060596bad0ac093dac94111
Tx:......... 187b00588e8d7844c405da9a15d78dbd7ebb9b2887fb5aace6651719fede923e
Tx:......... dbbca0d839435ac77db65378a9607d17b0aa965f3027d84dcf0ee5115dc8d32f
Tx:......... 17c12f45956082a913c0c862d573cf067fa5ee96ba5b954914371da6bef51f7f
Tx:......... 36cce25d34a5da0f7d69253743eae7bb7c576e5543d0eb16db0f72967edb4bc6
Tx:......... 6ea48c6286b1691cd1ecec271a3f52a3fe099467bb6c926b41ba8942e21d4aa6
MerkleBlock: 0000000000000000049ee67931f6d4970a7d06b14b8aadd406223ab65efe5025
MerkleBlock: 0000000000000000019f3fc2c8da43e8a81373ae189ace4caec6c59969f46ff6
MerkleBlock: 000000000000000000f67dad206798db2e6c5dffec84d213397784be894e66fa

Las 5 transacciones en la lista son correctas, ya que contienen salidas dirigidas a dicha billetera. Sin embargo, el bloque 0000000000000000019f3... contiene transacciones con entradas de dicha billetera, pero el mensaje merkleblock de este bloque no es seguido por estas transacciones. ¿No debería el nodo agregar las salidas de estas 5 transacciones al filtro de floración y, por lo tanto, hacer coincidir las transacciones posteriores que contienen entradas que apuntan a ellas?

He confirmado que el nodo está en posesión de las transacciones relevantes. Si cargo el filtro manualmente, agregando las salidas yo mismo, esto funciona según lo previsto.

¿Estoy malinterpretando cómo se usa BIP 37?

Respuestas (1)

BLOOM_UPDATE_P2PUBKEY_ONLY significa solo actualizar el filtro con puntos de salida cuando la transacción coincidente es pay-to-pubkey o bare multisig, no p2pkh u otros. Sin embargo, no sé por qué, ya que lo que intentas hacer es muy común.

También puede estar interesado en este trabajo en Bitcoin XT que permite actualizar un filtro con cualquier ancestro no confirmado de una transacción coincidente (para evaluar mejor sus posibilidades de confirmación).

Muchas gracias. No me di cuenta de que decía P2PUBKEY y no P2PUBKEYHASH. Tonto de mi.