Solution for ZMQ connectivity of the Bitcoin nodes

bobinson commented

2022-02-04 06:37:10 +00:00

(Migrated from gitlab.com)

We have 7 active sons on the mainnet and the HIVE / HBD deposits are working fine. However the Bitcoin deposit address creation is failing due to possible issues with the ZMQ node. The same error is seen in IRONA TESTNET as well. (@sivayavvari has further details, logs etc).

We need to provide a method to the SON operators and end users to identify the health of the Bitcoin node and also for end users. This can be perhaps achieved by adding queries / handshakes to the ZMQ node or using third party tools if any.

The first step must be providing this additional tool or instructions and as the second step we must explore ways to use additional Bitcoin nodes from a pool of nodes.

Deliverables: cli_wallet commands, other instructions required to inspect the health of the ZMQ node. The same must be possible via UI too. ie, we must provide PeerplaysJS and Python Support eventfully.

We have 7 active sons on the mainnet and the HIVE / HBD deposits are working fine. However the Bitcoin deposit address creation is failing due to possible issues with the ZMQ node. The same error is seen in IRONA TESTNET as well. (@sivayavvari has further details, logs etc). We need to provide a method to the SON operators and end users to identify the health of the Bitcoin node and also for end users. This can be perhaps achieved by adding queries / handshakes to the ZMQ node or using third party tools if any. The first step must be providing this additional tool or instructions and as the second step we must explore ways to use additional Bitcoin nodes from a pool of nodes. Deliverables: cli_wallet commands, other instructions required to inspect the health of the ZMQ node. The same must be possible via UI too. ie, we must provide PeerplaysJS and Python Support eventfully.

bobinson commented

2022-02-04 06:37:10 +00:00

(Migrated from gitlab.com)

assigned to @sierra19XX

bobinson commented

2022-02-04 06:37:41 +00:00

(Migrated from gitlab.com)

@serkixenos @Hiltos1 - Please share your thoughts if any.

serkixenos commented

2022-02-04 15:31:09 +00:00

(Migrated from gitlab.com)

From core dev side, QA environment is a reference when it comes to problems like this. Does the ZMQ works in QA env or not? If it works in QA, then @sivayavvari should double and triple check his configuration. If it works in QA, but later stops working, we want to look into this, but we should get at least some info on the local setup and actions performed when it stopped working. However, working in QA and not working in some local setup sounds like local configuration problem.

@sivayavvari can you share the output of your tests with the tool we recommended (https://github.com/flyte/zmcat) and forwarded instructions from @Hiltos1 on how to fix the tool?

From core dev side, QA environment is a reference when it comes to problems like this. Does the ZMQ works in QA env or not? If it works in QA, then @sivayavvari should double and triple check his configuration. If it works in QA, but later stops working, we want to look into this, but we should get at least some info on the local setup and actions performed when it stopped working. However, working in QA and not working in some local setup sounds like local configuration problem. @sivayavvari can you share the output of your tests with the tool we recommended (https://github.com/flyte/zmcat) and forwarded instructions from @Hiltos1 on how to fix the tool?

Hiltos1 commented

2022-02-04 15:49:19 +00:00

(Migrated from gitlab.com)

I recently set up a quick zmq subscriber on my SON server using node.js to see if I could receive the zmq messages. It worked! I am able to view a stream of decoded raw transactions as they come into the chain. Note that I'm running my own bitcoin node on the same server. Here's what I did:

I created a directory (cd ~ && mkdir ./bitcoin-zmq/ && cd ./bitcoin-zmq/) and put the following file there:

# In a file named ./sub.js
const zmq = require("zeromq")
const RpcClient = require('bitcoind-rpc')
const rpcConfig = {
    protocol: 'http',
    user: '******', # my username went here
    pass: '******', # my password went here
    host: '127.0.0.1',
    port: '8332',
}
async function run() {
  const sock = new zmq.Subscriber
  const rpc = new RpcClient(rpcConfig)
  sock.connect("tcp://127.0.0.1:11111")
  sock.subscribe("rawtx")
  console.log("Subscriber connected to port 11111")

  for await (const [topic, msg] of sock) {
    rpc.decodeRawTransaction(msg.toString('hex'), function(err, resp) {
        console.log(JSON.stringify(resp, null, 4))
    })
  }
}

run()

I installed some dependencies:

# I already had libzmq3-dev from the earlier installs.
npm install zeromq@6.0.0-beta.6
npm install bitcoind-rpc

With the bitcoin node and SON node running, I started this app:

node ./sub.js

Now I can see all the incoming raw transactions. They look like this:

{
    "result": {
        "txid": "b7f208f0245c3cb82affc9bd8d1a8143d6478e40d880608c960e0fa1cd04e23d",
        "hash": "3738cddeba78409fb0c0a368a63cc738507d77ef96bd925eea7333eb801f49a4",
        "version": 2,
        "size": 787,
        "vsize": 542,
        "weight": 2167,
        "locktime": 0,
        "vin": [
            {
                "txid": "165b2b97a25480993ad828ac8c3ba2c064748d4ccdfee758e56c84a14c9211a4",
                "vout": 0,
                "scriptSig": {
                    "asm": "3045022100c546b3598d652fc204e6f0ea7beb87e622afe84b5465f06bf14414241d6b90890220773c9c3dd9d482a1e6248038df0e58f98c542464feb23e4d4f44fefb0df5d408[ALL] 020e08d8591af27c8b08acbf2869f1b679715d3ca2dcd3b13e71860543e2e5f97e",
                    "hex": "483045022100c546b3598d652fc204e6f0ea7beb87e622afe84b5465f06bf14414241d6b90890220773c9c3dd9d482a1e6248038df0e58f98c542464feb23e4d4f44fefb0df5d4080121020e08d8591af27c8b08acbf2869f1b679715d3ca2dcd3b13e71860543e2e5f97e"
                },
                "sequence": 4294967295
            },
            {
                "txid": "30646baa5f1b6cfb9863971da85b201e6bfcf5d2631684d2107f8081fb5aa867",
                "vout": 1,
                "scriptSig": {
                    "asm": "",
                    "hex": ""
                },
                "txinwitness": [
                    "30440220640350809fa11d68ae822ca5f35b8f1aa351e6caa1b15cc04de8494bd8d6fc3202201a7da195a8ddbac9e1deb7a96160a02be627bf74dc3273dffc2568e9d2574e9b01",
                    "039576986d03fdf11a7c5bbd63c86b62ec6f798a76115dbbe981e8e5d7d78ecce7"
                ],
                "sequence": 4294967295
            },
            {
                "txid": "a499b24afe8ff68ec080cdcbbe8d0e8a71956ca7cc4242181f0b32a9f5926374",
                "vout": 0,
                "scriptSig": {
                    "asm": "304402203f12eccc32e6b02db836083f02120fd779f5f3cbefe65dbb953cd75f1ea4bad60220726edfc8913805adeaea16ade4e39934482b6d36f237343dd137183018ce3abc[ALL] 020e08d8591af27c8b08acbf2869f1b679715d3ca2dcd3b13e71860543e2e5f97e",
                    "hex": "47304402203f12eccc32e6b02db836083f02120fd779f5f3cbefe65dbb953cd75f1ea4bad60220726edfc8913805adeaea16ade4e39934482b6d36f237343dd137183018ce3abc0121020e08d8591af27c8b08acbf2869f1b679715d3ca2dcd3b13e71860543e2e5f97e"
                },
                "sequence": 4294967295
            },
            {
                "txid": "c75513725246da708318d6f4de23357d74f45e7d613239c1ed0c29d735ddee91",
                "vout": 1,
                "scriptSig": {
                    "asm": "",
                    "hex": ""
                },
                "txinwitness": [
                    "304502210098d0e28b27b0bcb0915ef4ea75a4cb68a711c1190d2afcd5f942f044c2b3620802204a34ef2db3fd4e5b2b940fadc11c197dbaa8df78d10975e0da59f0c2d42b6d3701",
                    "0386bc6838a190647144c4db6f3cc0d1b7bc4f2876761d2f8233d21771ea53af06"
                ],
                "sequence": 4294967295
            },
            {
                "txid": "ebd2572982d4cc9bd8c6297fac75cf8cd342b558c87631465f6b6591a3d929a2",
                "vout": 1,
                "scriptSig": {
                    "asm": "",
                    "hex": ""
                },
                "txinwitness": [
                    "3045022100f17ea70bcd8da0c83b3046601cbda80888920675c3f3f95fb7775851aab6f1ec022057279423ae4394bc8bcfec252653481653c5e8a447b464679d79d36494e265b801",
                    "03c63b4a035b409d9017724a14c9ba457b4a4ab993b9894484ee5e94624baf9dde"
                ],
                "sequence": 4294967295
            }
        ],
        "vout": [
            {
                "value": 0.05704911,
                "n": 0,
                "scriptPubKey": {
                    "asm": "OP_HASH160 80ab07fb420178ba34f33dd0bc5768a0863ba5e5 OP_EQUAL",
                    "hex": "a91480ab07fb420178ba34f33dd0bc5768a0863ba5e587",
                    "address": "3DRMJZ1CjEjHqT6aJ9S9eeWPN1JuBkpAZv",
                    "type": "scripthash"
                }
            }
        ]
    },
    "error": null,
    "id": 50342
}

I recently set up a quick zmq subscriber on my SON server using node.js to see if I could receive the zmq messages. It worked! I am able to view a stream of decoded raw transactions as they come into the chain. Note that I'm running my own bitcoin node on the same server. Here's what I did: 1. I created a directory (`cd ~ && mkdir ./bitcoin-zmq/ && cd ./bitcoin-zmq/`) and put the following file there: ```bash # In a file named ./sub.js const zmq = require("zeromq") const RpcClient = require('bitcoind-rpc') const rpcConfig = { protocol: 'http', user: '******', # my username went here pass: '******', # my password went here host: '127.0.0.1', port: '8332', } async function run() { const sock = new zmq.Subscriber const rpc = new RpcClient(rpcConfig) sock.connect("tcp://127.0.0.1:11111") sock.subscribe("rawtx") console.log("Subscriber connected to port 11111") for await (const [topic, msg] of sock) { rpc.decodeRawTransaction(msg.toString('hex'), function(err, resp) { console.log(JSON.stringify(resp, null, 4)) }) } } run() ``` 2. I installed some dependencies: ```bash # I already had libzmq3-dev from the earlier installs. npm install zeromq@6.0.0-beta.6 npm install bitcoind-rpc ``` 3. With the bitcoin node and SON node running, I started this app: ```bash node ./sub.js ``` Now I can see all the incoming raw transactions. They look like this: ```bash { "result": { "txid": "b7f208f0245c3cb82affc9bd8d1a8143d6478e40d880608c960e0fa1cd04e23d", "hash": "3738cddeba78409fb0c0a368a63cc738507d77ef96bd925eea7333eb801f49a4", "version": 2, "size": 787, "vsize": 542, "weight": 2167, "locktime": 0, "vin": [ { "txid": "165b2b97a25480993ad828ac8c3ba2c064748d4ccdfee758e56c84a14c9211a4", "vout": 0, "scriptSig": { "asm": "3045022100c546b3598d652fc204e6f0ea7beb87e622afe84b5465f06bf14414241d6b90890220773c9c3dd9d482a1e6248038df0e58f98c542464feb23e4d4f44fefb0df5d408[ALL] 020e08d8591af27c8b08acbf2869f1b679715d3ca2dcd3b13e71860543e2e5f97e", "hex": "483045022100c546b3598d652fc204e6f0ea7beb87e622afe84b5465f06bf14414241d6b90890220773c9c3dd9d482a1e6248038df0e58f98c542464feb23e4d4f44fefb0df5d4080121020e08d8591af27c8b08acbf2869f1b679715d3ca2dcd3b13e71860543e2e5f97e" }, "sequence": 4294967295 }, { "txid": "30646baa5f1b6cfb9863971da85b201e6bfcf5d2631684d2107f8081fb5aa867", "vout": 1, "scriptSig": { "asm": "", "hex": "" }, "txinwitness": [ "30440220640350809fa11d68ae822ca5f35b8f1aa351e6caa1b15cc04de8494bd8d6fc3202201a7da195a8ddbac9e1deb7a96160a02be627bf74dc3273dffc2568e9d2574e9b01", "039576986d03fdf11a7c5bbd63c86b62ec6f798a76115dbbe981e8e5d7d78ecce7" ], "sequence": 4294967295 }, { "txid": "a499b24afe8ff68ec080cdcbbe8d0e8a71956ca7cc4242181f0b32a9f5926374", "vout": 0, "scriptSig": { "asm": "304402203f12eccc32e6b02db836083f02120fd779f5f3cbefe65dbb953cd75f1ea4bad60220726edfc8913805adeaea16ade4e39934482b6d36f237343dd137183018ce3abc[ALL] 020e08d8591af27c8b08acbf2869f1b679715d3ca2dcd3b13e71860543e2e5f97e", "hex": "47304402203f12eccc32e6b02db836083f02120fd779f5f3cbefe65dbb953cd75f1ea4bad60220726edfc8913805adeaea16ade4e39934482b6d36f237343dd137183018ce3abc0121020e08d8591af27c8b08acbf2869f1b679715d3ca2dcd3b13e71860543e2e5f97e" }, "sequence": 4294967295 }, { "txid": "c75513725246da708318d6f4de23357d74f45e7d613239c1ed0c29d735ddee91", "vout": 1, "scriptSig": { "asm": "", "hex": "" }, "txinwitness": [ "304502210098d0e28b27b0bcb0915ef4ea75a4cb68a711c1190d2afcd5f942f044c2b3620802204a34ef2db3fd4e5b2b940fadc11c197dbaa8df78d10975e0da59f0c2d42b6d3701", "0386bc6838a190647144c4db6f3cc0d1b7bc4f2876761d2f8233d21771ea53af06" ], "sequence": 4294967295 }, { "txid": "ebd2572982d4cc9bd8c6297fac75cf8cd342b558c87631465f6b6591a3d929a2", "vout": 1, "scriptSig": { "asm": "", "hex": "" }, "txinwitness": [ "3045022100f17ea70bcd8da0c83b3046601cbda80888920675c3f3f95fb7775851aab6f1ec022057279423ae4394bc8bcfec252653481653c5e8a447b464679d79d36494e265b801", "03c63b4a035b409d9017724a14c9ba457b4a4ab993b9894484ee5e94624baf9dde" ], "sequence": 4294967295 } ], "vout": [ { "value": 0.05704911, "n": 0, "scriptPubKey": { "asm": "OP_HASH160 80ab07fb420178ba34f33dd0bc5768a0863ba5e5 OP_EQUAL", "hex": "a91480ab07fb420178ba34f33dd0bc5768a0863ba5e587", "address": "3DRMJZ1CjEjHqT6aJ9S9eeWPN1JuBkpAZv", "type": "scripthash" } } ] }, "error": null, "id": 50342 } ```

Hiltos1 commented

2022-02-04 17:04:12 +00:00

(Migrated from gitlab.com)

This can also be simplified to subscribe to another server running zmq:

const zmq = require("zeromq")
async function run() {
  const sock = new zmq.Subscriber
  sock.connect("tcp://**Put the IP here**:11111")
  sock.subscribe("rawtx")
  console.log("Subscriber connected to port 11111")

  for await (const [topic, msg] of sock) {
    console.log("TOPIC: %s\nMESSAGE: %s", topic.toString(), msg.toString("hex"))
  }
}

run()

Here are my observations so far. I've installed these test subscribers on three different servers (2x AWS EC2 instances and 1x Hetzner server).

Hetzner server (pub) -> Hetzner server (sub) = Messages received (to itself)
EC2 server 1 (pub) -> EC2 server 1 (sub) = Messages received (to itself)
EC2 server 1 (pub) -> Hetzner server (sub) = Messages not received
Hetzner server (pub) -> EC2 server 1 (sub) = Messages not received
EC2 server 1 (pub) -> EC2 server 2 (sub) = Messages not received

The only scenario I haven't tested is going from a non-AWS server to another non-AWS server mostly due to lack of having another non-AWS server.

This can also be simplified to subscribe to another server running zmq: ```bash const zmq = require("zeromq") async function run() { const sock = new zmq.Subscriber sock.connect("tcp://**Put the IP here**:11111") sock.subscribe("rawtx") console.log("Subscriber connected to port 11111") for await (const [topic, msg] of sock) { console.log("TOPIC: %s\nMESSAGE: %s", topic.toString(), msg.toString("hex")) } } run() ``` Here are my observations so far. I've installed these test subscribers on three different servers (2x AWS EC2 instances and 1x Hetzner server). - Hetzner server (pub) -> Hetzner server (sub) = Messages received (to itself) - EC2 server 1 (pub) -> EC2 server 1 (sub) = Messages received (to itself) - EC2 server 1 (pub) -> Hetzner server (sub) = Messages **not** received - Hetzner server (pub) -> EC2 server 1 (sub) = Messages **not** received - EC2 server 1 (pub) -> EC2 server 2 (sub) = Messages **not** received The only scenario I haven't tested is going from a non-AWS server to another non-AWS server mostly due to lack of having another non-AWS server.

Hiltos1 commented

2022-02-04 19:34:23 +00:00

(Migrated from gitlab.com)

I figured it out... In my ./bitcoin/bitcoin.conf file, I was only publishing to the localhost like this:

# [zeromq]
# Enable publishing of block hashes to <address>.
zmqpubhashblock=tcp://127.0.0.1:11111
# Enable publishing of transaction hashes to <address>.
zmqpubhashtx=tcp://127.0.0.1:11111
# Enable publishing of raw block hex to <address>.
zmqpubrawblock=tcp://127.0.0.1:11111
# Enable publishing of raw transaction hex to <address>.
zmqpubrawtx=tcp://127.0.0.1:11111
# Set publish hash block outbound message high water mark.
zmqpubhashblockhwm=5000
# Set publish hash transaction outbound message high water mark.
zmqpubhashtxhwm=5000
# Set publish raw block outbound message high water mark.
zmqpubrawblockhwm=5000
# Set publish raw transaction outbound message high water mark.
zmqpubrawtxhwm=5000
# Enable publish hash block and tx sequence in <address>.
zmqpubsequence=tcp://127.0.0.1:11111
# Set publish hash sequence message high water mark.
zmqpubsequencehwm=5000

So, of course, it was only available on the same machine. All I had to do was to update the config to publish to any IP:

# [zeromq]
# Enable publishing of block hashes to <address>.
zmqpubhashblock=tcp://0.0.0.0:11111
# Enable publishing of transaction hashes to <address>.
zmqpubhashtx=tcp://0.0.0.0:11111
# Enable publishing of raw block hex to <address>.
zmqpubrawblock=tcp://0.0.0.0:11111
# Enable publishing of raw transaction hex to <address>.
zmqpubrawtx=tcp://0.0.0.0:11111
# Set publish hash block outbound message high water mark.
zmqpubhashblockhwm=5000
# Set publish hash transaction outbound message high water mark.
zmqpubhashtxhwm=5000
# Set publish raw block outbound message high water mark.
zmqpubrawblockhwm=5000
# Set publish raw transaction outbound message high water mark.
zmqpubrawtxhwm=5000
# Enable publish hash block and tx sequence in <address>.
zmqpubsequence=tcp://0.0.0.0:11111
# Set publish hash sequence message high water mark.
zmqpubsequencehwm=5000

And now I've got ZMQ messaging working 😄

I figured it out... In my `./bitcoin/bitcoin.conf` file, I was only publishing to the localhost like this: ```bash # [zeromq] # Enable publishing of block hashes to <address>. zmqpubhashblock=tcp://127.0.0.1:11111 # Enable publishing of transaction hashes to <address>. zmqpubhashtx=tcp://127.0.0.1:11111 # Enable publishing of raw block hex to <address>. zmqpubrawblock=tcp://127.0.0.1:11111 # Enable publishing of raw transaction hex to <address>. zmqpubrawtx=tcp://127.0.0.1:11111 # Set publish hash block outbound message high water mark. zmqpubhashblockhwm=5000 # Set publish hash transaction outbound message high water mark. zmqpubhashtxhwm=5000 # Set publish raw block outbound message high water mark. zmqpubrawblockhwm=5000 # Set publish raw transaction outbound message high water mark. zmqpubrawtxhwm=5000 # Enable publish hash block and tx sequence in <address>. zmqpubsequence=tcp://127.0.0.1:11111 # Set publish hash sequence message high water mark. zmqpubsequencehwm=5000 ``` So, of course, it was only available on the same machine. All I had to do was to update the config to publish to any IP: ```bash # [zeromq] # Enable publishing of block hashes to <address>. zmqpubhashblock=tcp://0.0.0.0:11111 # Enable publishing of transaction hashes to <address>. zmqpubhashtx=tcp://0.0.0.0:11111 # Enable publishing of raw block hex to <address>. zmqpubrawblock=tcp://0.0.0.0:11111 # Enable publishing of raw transaction hex to <address>. zmqpubrawtx=tcp://0.0.0.0:11111 # Set publish hash block outbound message high water mark. zmqpubhashblockhwm=5000 # Set publish hash transaction outbound message high water mark. zmqpubhashtxhwm=5000 # Set publish raw block outbound message high water mark. zmqpubrawblockhwm=5000 # Set publish raw transaction outbound message high water mark. zmqpubrawtxhwm=5000 # Enable publish hash block and tx sequence in <address>. zmqpubsequence=tcp://0.0.0.0:11111 # Set publish hash sequence message high water mark. zmqpubsequencehwm=5000 ``` And now I've got ZMQ messaging working :smile:

serkixenos commented

2022-02-04 20:48:09 +00:00

(Migrated from gitlab.com)

@sivayavvari Any feedback???

sivayavvari commented

2022-02-05 17:57:11 +00:00

(Migrated from gitlab.com)

I have SON node running on the server 96.46.48.114

And bitcoin node running on the 96.46.48.225

The bitcoin.conf file has

regtest=1
  
[regtest]

rest=1

txindex=1

fallbackfee=0.0002

bind=0.0.0.0

listen=1

port=18444

server=1

rpcbind=0.0.0.0

rpcuser=1

rpcpassword=1

rpcallowip=0.0.0.0/32
rpcallowip=96.46.48.114

rpcport=8332

#zmqpubhashblock=tcp://0.0.0.0:11111
#zmqpubhashtx=tcp://0.0.0.0:11111
#zmqpubrawblock=tcp://0.0.0.0:11111
#zmqpubrawtx=tcp://0.0.0.0:11111

# [zeromq]
# Enable publishing of block hashes to <address>.
zmqpubhashblock=tcp://0.0.0.0:11111
# Enable publishing of transaction hashes to <address>.
zmqpubhashtx=tcp://0.0.0.0:11111
# Enable publishing of raw block hex to <address>.
zmqpubrawblock=tcp://0.0.0.0:11111
# Enable publishing of raw transaction hex to <address>.
zmqpubrawtx=tcp://0.0.0.0:11111
# Set publish hash block outbound message high water mark.
zmqpubhashblockhwm=5000
# Set publish hash transaction outbound message high water mark.
zmqpubhashtxhwm=5000
# Set publish raw block outbound message high water mark.
zmqpubrawblockhwm=5000
# Set publish raw transaction outbound message high water mark.
zmqpubrawtxhwm=5000
# Enable publish hash block and tx sequence in <address>.
zmqpubsequence=tcp://0.0.0.0:11111
# Set publish hash sequence message high water mark.
zmqpubsequencehwm=5000

The config.iniconfig.ini file on the SON node

Tried the below command on the bitcoin node


bunker@siva-pbsa:~/.bitcoin$ bitcoin-cli -rpcuser=1 -rpcpassword=1 -rpcwallet=default generatetoaddress 2  bcrt1qmhayus3qgndla4amxth2pvnvfkeaa4pl6h5h3ts0tdllsmqhl8fsd4wzfv
[
  "3d90f4f6a6245c879ddf0b0ce01f64f41ded44d8f029a379771bcccbf097bad9",
  "7728ef2ed08f833da1d1b83a401f434d869489cf657e199933fd328201958297"
]

Received this on SON node where the script https://gitlab.com/PBSA/peerplays/-/issues/269#note_832438317 is running

bunker@bitcoin-son-irona:~/bitcoin-zmq$ node ./sub.js
Subscriber connected to port 11111
TOPIC: rawtx
MESSAGE: 020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff0502cb030101ffffffff02c817a80400000000220020ddfa4e422044dbfed7bb32eea0b26c4db3ded43fd5e978ae0f5b7ff86c17f9d30000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
TOPIC: rawtx
MESSAGE: 020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff0502cc030101ffffffff02c817a80400000000220020ddfa4e422044dbfed7bb32eea0b26c4db3ded43fd5e978ae0f5b7ff86c17f9d30000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000

I have SON node running on the server 96.46.48.114 ![image](/uploads/b050a9b8a35e10193403f9e14f254c48/image.png) And bitcoin node running on the 96.46.48.225 ![image](/uploads/af728ce12aab54e7941799675c7a4600/image.png) The bitcoin.conf file has ``` regtest=1 [regtest] rest=1 txindex=1 fallbackfee=0.0002 bind=0.0.0.0 listen=1 port=18444 server=1 rpcbind=0.0.0.0 rpcuser=1 rpcpassword=1 rpcallowip=0.0.0.0/32 rpcallowip=96.46.48.114 rpcport=8332 #zmqpubhashblock=tcp://0.0.0.0:11111 #zmqpubhashtx=tcp://0.0.0.0:11111 #zmqpubrawblock=tcp://0.0.0.0:11111 #zmqpubrawtx=tcp://0.0.0.0:11111 # [zeromq] # Enable publishing of block hashes to <address>. zmqpubhashblock=tcp://0.0.0.0:11111 # Enable publishing of transaction hashes to <address>. zmqpubhashtx=tcp://0.0.0.0:11111 # Enable publishing of raw block hex to <address>. zmqpubrawblock=tcp://0.0.0.0:11111 # Enable publishing of raw transaction hex to <address>. zmqpubrawtx=tcp://0.0.0.0:11111 # Set publish hash block outbound message high water mark. zmqpubhashblockhwm=5000 # Set publish hash transaction outbound message high water mark. zmqpubhashtxhwm=5000 # Set publish raw block outbound message high water mark. zmqpubrawblockhwm=5000 # Set publish raw transaction outbound message high water mark. zmqpubrawtxhwm=5000 # Enable publish hash block and tx sequence in <address>. zmqpubsequence=tcp://0.0.0.0:11111 # Set publish hash sequence message high water mark. zmqpubsequencehwm=5000 ``` The config.ini[config.ini](/uploads/10129244dfd45ae637d2b2ea8d9fbbf5/config.ini) file on the SON node Tried the below command on the bitcoin node ``` bunker@siva-pbsa:~/.bitcoin$ bitcoin-cli -rpcuser=1 -rpcpassword=1 -rpcwallet=default generatetoaddress 2 bcrt1qmhayus3qgndla4amxth2pvnvfkeaa4pl6h5h3ts0tdllsmqhl8fsd4wzfv [ "3d90f4f6a6245c879ddf0b0ce01f64f41ded44d8f029a379771bcccbf097bad9", "7728ef2ed08f833da1d1b83a401f434d869489cf657e199933fd328201958297" ] ``` Received this on SON node where the script https://gitlab.com/PBSA/peerplays/-/issues/269#note_832438317 is running ``` bunker@bitcoin-son-irona:~/bitcoin-zmq$ node ./sub.js Subscriber connected to port 11111 TOPIC: rawtx MESSAGE: 020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff0502cb030101ffffffff02c817a80400000000220020ddfa4e422044dbfed7bb32eea0b26c4db3ded43fd5e978ae0f5b7ff86c17f9d30000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000 TOPIC: rawtx MESSAGE: 020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff0502cc030101ffffffff02c817a80400000000220020ddfa4e422044dbfed7bb32eea0b26c4db3ded43fd5e978ae0f5b7ff86c17f9d30000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000 ```

pavel.baykov commented

2022-02-15 13:46:12 +00:00

(Migrated from gitlab.com)

please check ticket 276, i think it’s about the same
i posted what i found there

please check ticket 276, i think it’s about the same i posted what i found there

Hiltos1 commented

2022-02-15 14:49:36 +00:00

(Migrated from gitlab.com)

I've created a small ZMQ Utility for us located here: https://gitlab.com/PBSA/tools-libs/zmq-for-btc-sons

serkixenos commented

2022-02-16 15:27:16 +00:00

(Migrated from gitlab.com)

https://gitlab.com/PBSA/tools-libs/zmq-for-btc-sons/-/merge_requests/1

serkixenos commented

2022-02-16 15:37:51 +00:00

(Migrated from gitlab.com)

@sivayavvari dockerized @Hiltos1 tool. This is a good first step.

Now, I do not think that adding zmq check capabilities into cli_wallet is a way to go, because its just not the right place, and cli_wallet does not have access to witness config file, and therefore, is not able to get btc node address and zmq port.

We can eventually add api to witness node to return last btc tx hash received.

Bookie plugin can be used as a reference, on how to implement API in plugin.

@sivayavvari dockerized @Hiltos1 tool. This is a good first step. Now, I do not think that adding zmq check capabilities into cli_wallet is a way to go, because its just not the right place, and cli_wallet does not have access to witness config file, and therefore, is not able to get btc node address and zmq port. We can eventually add api to witness node to return last btc tx hash received. Bookie plugin can be used as a reference, on how to implement API in plugin.

serkixenos commented

2022-03-28 14:20:50 +00:00

(Migrated from gitlab.com)

unassigned @sierra19XX

serkixenos commented

2022-03-30 14:52:43 +00:00

(Migrated from gitlab.com)

assigned to @serkixenos

serkixenos commented

2022-04-05 03:37:53 +00:00

(Migrated from gitlab.com)

https://gitlab.com/PBSA/peerplays/-/merge_requests/94

In this MR. we introduce sidechain API. Sidechain API is accessible through cli wallet, and provides endpoint to retrieve SON listener logs. Son listener log will show a list of last blocks retrieved and transaction processed.

New cli wallet command

get_son_listener_log

Output will be similar to the one bellow. It will show last few block hashes/numbers and transaction ids processed.

locked >>> get_son_listener_log
get_son_listener_log
[[
    "bitcoin",[
      "BLOCK   : 2EF37C8C0A4C72B255F76A7390FC0507D3F61F1F81C8F6A8FCD3F09E6AD529C7",
      "BLOCK   : 1C9B5C7E38C125E671765472804D03CE202DFCA3198BDAC84962A2FE6171417E",
      "TRX     : f2eb7ce6a2e53f3a5ac368142c26341e137a0d57cb72a04194d5b3e24abda5c9",
      "TRX     : 5482a0f30a65e3e2c39843358942efcb6d9313a017cacedce109b74fef1c889f",
      "BLOCK   : 32D423F5577A1F6C3441E3222805779580E018754759EFB37114DE9EE049AF4F",
      "BLOCK   : 593AD784671AAE4B19F3CCA8F8EBBCC21E48C32334716283ABABE610689CF536",
      "TRX     : 1c5879ad3f8aca121a54fd44e35f8264d6c535377eb1c4942dbb827fa652cb45",
      "BLOCK   : 6D05579A7CA9BB9624C0983FBA82E2B6D779BE9F241EBD0C07866365295C1329"
    ]
  ],[
    "hive",[
      "BLOCK   : 4394",
      "BLOCK   : 4393",
      "BLOCK   : 4392",
      "TRX     : 398cfd09b9eb1858711af11b68254788dfb0af00",
      "BLOCK   : 4391",
      "TRX     : 00b58079478ab6407fba9c4d06a04257493b968d",
      "BLOCK   : 4390",
      "BLOCK   : 4389",
      "BLOCK   : 4388",
      "BLOCK   : 4387",
      "BLOCK   : 4386",
      "TRX     : bfaf7f67868a84e590030fca3e26e06ea4d34170",
      "BLOCK   : 4385",
      "BLOCK   : 4384",
      "BLOCK   : 4383",
      "BLOCK   : 4382",
      "BLOCK   : 4381",
      "BLOCK   : 4380"
    ]
  ]
]

Block hash/number will be added to the log regardless of whether it contain deposit/withdrawal operation or not. Transaction id will be added only if the transaction contains withdrawal/deposit operation.

NOTE: SON listener log is local to a SON node. This means that user is not able to investigate a log of a SON not running on a node he is connected to. This information is not shared on chain.

https://gitlab.com/PBSA/peerplays/-/merge_requests/94 In this MR. we introduce sidechain API. Sidechain API is accessible through cli wallet, and provides endpoint to retrieve SON listener logs. Son listener log will show a list of last blocks retrieved and transaction processed. New cli wallet command ``` get_son_listener_log ``` Output will be similar to the one bellow. It will show last few block hashes/numbers and transaction ids processed. ``` locked >>> get_son_listener_log get_son_listener_log [[ "bitcoin",[ "BLOCK : 2EF37C8C0A4C72B255F76A7390FC0507D3F61F1F81C8F6A8FCD3F09E6AD529C7", "BLOCK : 1C9B5C7E38C125E671765472804D03CE202DFCA3198BDAC84962A2FE6171417E", "TRX : f2eb7ce6a2e53f3a5ac368142c26341e137a0d57cb72a04194d5b3e24abda5c9", "TRX : 5482a0f30a65e3e2c39843358942efcb6d9313a017cacedce109b74fef1c889f", "BLOCK : 32D423F5577A1F6C3441E3222805779580E018754759EFB37114DE9EE049AF4F", "BLOCK : 593AD784671AAE4B19F3CCA8F8EBBCC21E48C32334716283ABABE610689CF536", "TRX : 1c5879ad3f8aca121a54fd44e35f8264d6c535377eb1c4942dbb827fa652cb45", "BLOCK : 6D05579A7CA9BB9624C0983FBA82E2B6D779BE9F241EBD0C07866365295C1329" ] ],[ "hive",[ "BLOCK : 4394", "BLOCK : 4393", "BLOCK : 4392", "TRX : 398cfd09b9eb1858711af11b68254788dfb0af00", "BLOCK : 4391", "TRX : 00b58079478ab6407fba9c4d06a04257493b968d", "BLOCK : 4390", "BLOCK : 4389", "BLOCK : 4388", "BLOCK : 4387", "BLOCK : 4386", "TRX : bfaf7f67868a84e590030fca3e26e06ea4d34170", "BLOCK : 4385", "BLOCK : 4384", "BLOCK : 4383", "BLOCK : 4382", "BLOCK : 4381", "BLOCK : 4380" ] ] ] ``` Block hash/number will be added to the log regardless of whether it contain deposit/withdrawal operation or not. Transaction id will be added only if the transaction contains withdrawal/deposit operation. NOTE: SON listener log is local to a SON node. This means that user is not able to investigate a log of a SON not running on a node he is connected to. This information is not shared on chain.

serkixenos commented

2022-04-05 03:38:31 +00:00

(Migrated from gitlab.com)

assigned to @prandnum

serkixenos commented

2022-04-05 03:57:52 +00:00

(Migrated from gitlab.com)

Test steps:

Execute deposits on Bitcoin and Hive networks, make notes about block and transaction ids.
Use get_son_listner_log command, to retrieve listener log, and make sure that block and transaction ids from step 1. are showing in listener log. EVERY block id processed should show up in logs. ONLY transactions with deposit operations should show up in logs.

Test steps: 1. Execute deposits on Bitcoin and Hive networks, make notes about block and transaction ids. 2. Use get_son_listner_log command, to retrieve listener log, and make sure that block and transaction ids from step 1. are showing in listener log. EVERY block id processed should show up in logs. ONLY transactions with deposit operations should show up in logs.

pavel.baykov commented

2022-04-06 12:32:49 +00:00

(Migrated from gitlab.com)

assigned to @pavel.baykov

pavel.baykov commented

2022-04-06 14:08:22 +00:00

(Migrated from gitlab.com)

10 assert_exception: Assert Exception
itr != _by_name.end(): no method with name 'get_son_listner_log'

10 assert_exception: Assert Exception itr != _by_name.end(): no method with name 'get_son_listner_log'

pavel.baykov commented

2022-04-06 14:12:05 +00:00

(Migrated from gitlab.com)

get_son_listener_log that’s correct name

pavel.baykov commented

2022-04-06 15:02:43 +00:00

(Migrated from gitlab.com)

Btc and Hive networks were initialized with init scripts

get_son_listner_log before deposits, looks weird for HIVE

get_son_listener_log
[[
    "bitcoin",[]
  ],[
    "hive",[
      "BLOCK   : 725",
      "BLOCK   : 724",
      "BLOCK   : 723",
      "BLOCK   : 722",
      "BLOCK   : 721",
      "BLOCK   : 720",
      "BLOCK   : 719",
      "BLOCK   : 718",
      "BLOCK   : 717",
      "BLOCK   : 716",
      "BLOCK   : 715",
      "BLOCK   : 714",
      "BLOCK   : 713",
      "BLOCK   : 712",
      "BLOCK   : 711",
      "BLOCK   : 710",
      "BLOCK   : 709",
      "BLOCK   : 708",
      "BLOCK   : 707",
      "BLOCK   : 706",
      "BLOCK   : 705",
      "BLOCK   : 704",
      "BLOCK   : 703",
      "BLOCK   : 702",
      "BLOCK   : 701",
      "BLOCK   : 700",
      "BLOCK   : 699",
      "BLOCK   : 698",
      "BLOCK   : 697",
      "BLOCK   : 696",
      "BLOCK   : 695",
      "BLOCK   : 694",
      "BLOCK   : 693"
    ]
  ]
]

Btc and Hive networks were initialized with init scripts get_son_listner_log before deposits, looks weird for HIVE ``` get_son_listener_log [[ "bitcoin",[] ],[ "hive",[ "BLOCK : 725", "BLOCK : 724", "BLOCK : 723", "BLOCK : 722", "BLOCK : 721", "BLOCK : 720", "BLOCK : 719", "BLOCK : 718", "BLOCK : 717", "BLOCK : 716", "BLOCK : 715", "BLOCK : 714", "BLOCK : 713", "BLOCK : 712", "BLOCK : 711", "BLOCK : 710", "BLOCK : 709", "BLOCK : 708", "BLOCK : 707", "BLOCK : 706", "BLOCK : 705", "BLOCK : 704", "BLOCK : 703", "BLOCK : 702", "BLOCK : 701", "BLOCK : 700", "BLOCK : 699", "BLOCK : 698", "BLOCK : 697", "BLOCK : 696", "BLOCK : 695", "BLOCK : 694", "BLOCK : 693" ] ] ] ```

pavel.baykov commented

2022-04-06 15:37:35 +00:00

(Migrated from gitlab.com)

Made 2 deposit of BTC, i see correct block numbers, and correct TRX numbers , however in json TRX twice more than expected, is it internal transfer ?

get_son_listener_log
[[
"bitcoin",[
"TRX : e737d717d433995cee2f81ee397e5c025add2927d9fb63e4eb3a976bfdf2bb9f",
"TRX : c24e402200db33f25954fe40fbc88b023dd121f879b9decce28498ded92eca4f",
"BLOCK : 4EDC5D671AAE6CF300AF1337A72C02DE821733DD3C5C7396944ECB76EC4380FD",
"TRX : 18bf8e0ba69f0051ec70b65ddf1af23a853bf6656e04d921151661a251c2e510",
"TRX : d32bd6d6bbdcdeaa9c734ff7f40bd1c3e5e9b0f598dffd326d5e519c7221abcb",
"BLOCK : 4B42BE4F8086F8B3903FE4CF185B277190E2058D01878A8A1C037425B42A3ABC"
]
],[
"hive",[
"BLOCK : 1593",
"BLOCK : 1592",
"BLOCK : 1591",
"BLOCK : 1590",
"BLOCK : 1589",
"BLOCK : 1588",
"BLOCK : 1587",
"BLOCK : 1586",
"BLOCK : 1585",
"BLOCK : 1584",
"BLOCK : 1583",
"BLOCK : 1582",
"BLOCK : 1581",
"BLOCK : 1580",
"BLOCK : 1579",
"BLOCK : 1578",
"BLOCK : 1577",
"BLOCK : 1576",
"BLOCK : 1575",
"BLOCK : 1574",
"BLOCK : 1573",
"BLOCK : 1572",
"BLOCK : 1571",
"BLOCK : 1570",
"BLOCK : 1569",
"BLOCK : 1568",
"BLOCK : 1567",
"BLOCK : 1566",
"BLOCK : 1565",
"BLOCK : 1564",
"BLOCK : 1563",
"BLOCK : 1562",
"BLOCK : 1561"
]
]
]

withdrawals does not show up as expected, however after 10 minutes son-account balance still have positive BTC/PBTC without bitcoin transactions

for HIVE it’s difficult to observe because BLOCKs are always rotating with new values

Made 2 deposit of BTC, i see correct block numbers, and correct TRX numbers , however in json TRX twice more than expected, is it internal transfer ? get_son_listener_log [[ "bitcoin",[ "TRX : e737d717d433995cee2f81ee397e5c025add2927d9fb63e4eb3a976bfdf2bb9f", "TRX : c24e402200db33f25954fe40fbc88b023dd121f879b9decce28498ded92eca4f", "BLOCK : 4EDC5D671AAE6CF300AF1337A72C02DE821733DD3C5C7396944ECB76EC4380FD", "TRX : 18bf8e0ba69f0051ec70b65ddf1af23a853bf6656e04d921151661a251c2e510", "TRX : d32bd6d6bbdcdeaa9c734ff7f40bd1c3e5e9b0f598dffd326d5e519c7221abcb", "BLOCK : 4B42BE4F8086F8B3903FE4CF185B277190E2058D01878A8A1C037425B42A3ABC" ] ],[ "hive",[ "BLOCK : 1593", "BLOCK : 1592", "BLOCK : 1591", "BLOCK : 1590", "BLOCK : 1589", "BLOCK : 1588", "BLOCK : 1587", "BLOCK : 1586", "BLOCK : 1585", "BLOCK : 1584", "BLOCK : 1583", "BLOCK : 1582", "BLOCK : 1581", "BLOCK : 1580", "BLOCK : 1579", "BLOCK : 1578", "BLOCK : 1577", "BLOCK : 1576", "BLOCK : 1575", "BLOCK : 1574", "BLOCK : 1573", "BLOCK : 1572", "BLOCK : 1571", "BLOCK : 1570", "BLOCK : 1569", "BLOCK : 1568", "BLOCK : 1567", "BLOCK : 1566", "BLOCK : 1565", "BLOCK : 1564", "BLOCK : 1563", "BLOCK : 1562", "BLOCK : 1561" ] ] ] withdrawals does not show up as expected, however after 10 minutes son-account balance still have positive BTC/PBTC without bitcoin transactions for HIVE it’s difficult to observe because BLOCKs are always rotating with new values

pavel.baykov commented

2022-04-06 15:38:33 +00:00

(Migrated from gitlab.com)

BTW 2nd BTC deposit lost, means Peerplays BTC balance did not adjust

serkixenos commented

2022-04-06 20:37:01 +00:00

(Migrated from gitlab.com)

No, it does not looks weird, it says that Hive listener follows Hive blocks as they are produced. In other words, it shows that Hive listener works properly.

"EVERY block id processed should show up in logs. ONLY transactions with deposit operations should show up in logs."

So, ideally, EVERY block produced by sidechain should be visible in this log, as it shows that sidechain listener did picked it up. For transactions, its different, as we will display ONLY transaction that contain the event of our interest, which is transfer to a deposit address

No, it does not looks weird, it says that Hive listener follows Hive blocks as they are produced. In other words, it shows that Hive listener works properly. "EVERY block id processed should show up in logs. ONLY transactions with deposit operations should show up in logs." So, ideally, EVERY block produced by sidechain should be visible in this log, as it shows that sidechain listener did picked it up. For transactions, its different, as we will display ONLY transaction that contain the event of our interest, which is transfer to a deposit address

serkixenos commented

2022-04-06 20:37:25 +00:00

(Migrated from gitlab.com)

Depending on what address you used for generatetoaddress, this might happen. If you mined (generatetoaddress) to deposit address, this is same as making another deposit, because mining to address pays block reward to that address.

serkixenos commented

2022-04-06 20:38:27 +00:00

(Migrated from gitlab.com)

Did you executed few generatetoblock after deposits. We need at least two (one to move funds from deposit address to primary wallet, and another to settle the transfer)?

pavel.baykov commented

2022-04-07 05:58:08 +00:00

(Migrated from gitlab.com)

i only executed one generatetoblock based on XLS description, looks like 2nd one actually made transfer

pavel.baykov commented

2022-04-07 06:06:09 +00:00

(Migrated from gitlab.com)

ok understood, do you want automation for this in endtoendtests ?

i think it’s worthwhile to make a stress volume test with random deposits / withdrawals and then match automatically

potentially BTC withdrawals does not work correctly in latest develop branch, unless i don’t know correct procedure..
i made transfer from mapped Peerplays account to son-acconnt waited 10 min, no actual withdraw and no son-account balance adjustment

ok understood, do you want automation for this in endtoendtests ? i think it’s worthwhile to make a stress volume test with random deposits / withdrawals and then match automatically potentially BTC withdrawals does not work correctly in latest develop branch, unless i don’t know correct procedure.. i made transfer from mapped Peerplays account to son-acconnt waited 10 min, no actual withdraw and no son-account balance adjustment

pavel.baykov commented

2022-04-07 06:08:19 +00:00

(Migrated from gitlab.com)

is it possible to have number of TRX in BTC the same as number of deposits ?

serkixenos (Migrated from gitlab.com) closed this issue

2022-04-08 12:47:56 +00:00

Solution for ZMQ connectivity of the Bitcoin nodes #269