Private transaction call failing

[quevas13]

• Parity Ethereum version: Parity-Ethereum/v2.3.0-unstable-23d25a0-20181207/x86_64-linux-gnu/rustc1.31.0
• Operating system: Linux VM on HyperV
• Installation: built from source (master branch)
• Fully synchronized: yes
• Network: private
• Restarted: yes

I'm following the Private Transactions tutorial and everything worked fine until part 3.
Here, when calling private_composeDeploymentTransaction the curl get stuck and hangs without timeout.

Here is the sequence of curls as per tutorial

`curl --data '{"method":"parity_composeTransaction","params":[{"from":"0xf587f027cb03b10d699f33a153b9e746bff11644", "data":"0x608060405234801561001057600080fd5b5060e38061001f6000396000f3fe6080604052600436106043576000357c0100000000000000000000000000000000000000000000000000000000900480630c55699c146048578063bc64b76d146070575b600080fd5b348015605357600080fd5b50605a60a7565b6040518082815260200191505060405180910390f35b348015607b57600080fd5b5060a560048036036020811015609057600080fd5b810190808035906020019092919050505060ad565b005b60005481565b806000819055505056fea165627a7a7230582045049e9cda70e48aa7e46b780070b1e2f3e28ccadb9e592691472e485845ce2b0029"}],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

curl --data '{"method":"personal_signTransaction","params":[{"condition":null,"data":"0x608060405234801561001057600080fd5b5060e38061001f6000396000f3fe6080604052600436106043576000357c0100000000000000000000000000000000000000000000000000000000900480630c55699c146048578063bc64b76d146070575b600080fd5b348015605357600080fd5b50605a60a7565b6040518082815260200191505060405180910390f35b348015607b57600080fd5b5060a560048036036020811015609057600080fd5b810190808035906020019092919050505060ad565b005b60005481565b806000819055505056fea165627a7a7230582045049e9cda70e48aa7e46b780070b1e2f3e28ccadb9e592691472e485845ce2b0029","from":"0xf587f027cb03b10d699f33a153b9e746bff11644","gas":"0x186a00","gasPrice":"0x0","nonce":"0x1","to":null,"value":"0x0"},"alicepwd"],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545

curl --data '{"method":"private_composeDeploymentTransaction","params":["latest", "0xf90150018083186a008080b90102608060405234801561001057600080fd5b5060e38061001f6000396000f3fe6080604052600436106043576000357c0100000000000000000000000000000000000000000000000000000000900480630c55699c146048578063bc64b76d146070575b600080fd5b348015605357600080fd5b50605a60a7565b6040518082815260200191505060405180910390f35b348015607b57600080fd5b5060a560048036036020811015609057600080fd5b810190808035906020019092919050505060ad565b005b60005481565b806000819055505056fea165627a7a7230582045049e9cda70e48aa7e46b780070b1e2f3e28ccadb9e592691472e485845ce2b002945a05f4d4cad8818f87caade0d9f02325abcd0beb28896f6b3e3043af0456a7d1ea9a058f3da474c05644d43d7a816ce282a2264bcf270ddd1a89f9cbd3ddd55a5a529", ["0xece0d92767aae90921e5299610abc101b75e63cb"], "0x0"],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545`

Sniffing the HTTP traffic I noticed that Alice node do a GET call to the SS1 secret store (I think to get the encryption key) and receive no response, so it's the SS1 node that get stuck (maybe it's a problem with a child process?)

The call from Alice to SS1 is the following

GET /000000000000000000000000310bf0bf58b40a2f1f9efc320c56813236e6f6c8/76ee8d3b7cf11e7d71044b774b93812ed01af9728ca69a2fe5b0f3d020545ca075f0f90d6249c361e87bf752ffef66bf933494a1b88308904020b9df4510192d01

[quevas13]

I must add that after the GET call the SS1 node can't be reached anymore by other secret store nodes.

[jam10o-new]

Do you have access to logs from the SS1 node?

[quevas13]

This is the output from the SS1 node

Loading config file from conf/ss1.toml
Option '--no-dapps' has been removed and is no longer supported.
2018-12-14 11:48:26  Starting Parity-Ethereum/v2.3.0-unstable-23d25a0-20181207/x86_64-linux-gnu/rustc1.31.0
2018-12-14 11:48:26  Keys path db.ss1/keys/DevelopmentChain
2018-12-14 11:48:26  DB path db.ss1/chains/DevelopmentChain/db/1484bce8c021f2ca
2018-12-14 11:48:26  State DB configuration: fast
2018-12-14 11:48:26  Operating mode: active
2018-12-14 11:48:28  Configured for DevelopmentChain using InstantSeal engine
2018-12-14 11:48:28  Starting SecretStore node: 0xbe24d7d474aef75a64caa8bbc4c25075d613d8cf3229323c97b4b3831c34ed7acff3d5b2852b7acdb498f62400c077ee6456838c93a242bd68daf14cae8c989d
2018-12-14 11:48:28  0xbe24…989d: network error 'Connection refused (os error 111)' when establishing outbound connection with 127.0.0.1:8012
2018-12-14 11:48:28  0xbe24…989d: network error 'Connection refused (os error 111)' when establishing outbound connection with 127.0.0.1:8013
2018-12-14 11:48:33  Public node URL: enode://dc47f29c22821e3cfc718029d7b7d717af06a0fbede241448466a47f6901ad25e31eca118d890d688b24bdad6f8bc301a9831312a7bb081739d8dee2dc83e13a@192.168.137.169:30301
2018-12-14 11:48:38  0xbe24…989d: network error 'Connection refused (os error 111)' when establishing outbound connection with 127.0.0.1:8012
2018-12-14 11:48:38  0xbe24…989d: network error 'Connection refused (os error 111)' when establishing outbound connection with 127.0.0.1:8013
2018-12-14 11:48:48  0xbe24…989d: network error 'Connection refused (os error 111)' when establishing outbound connection with 127.0.0.1:8013
2018-12-14 11:48:58  0xbe24…989d: network error 'Connection refused (os error 111)' when establishing outbound connection with 127.0.0.1:8013
2018-12-14 11:48:59     1/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
2018-12-14 11:49:08  0xbe24…989d: network error 'Connection refused (os error 111)' when establishing outbound connection with 127.0.0.1:8013
2018-12-14 11:49:29     2/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
2018-12-14 11:49:59     3/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
2018-12-14 11:50:29     4/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
2018-12-14 11:51:03     4/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
2018-12-14 11:51:33     4/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
2018-12-14 11:52:03     4/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
2018-12-14 11:52:33     4/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
^C2018-12-14 11:52:53  Finishing work, please wait...```

[jam10o-new]

I would check if you have any networking restrictions (ie, a firewall, security group, etc) on your node, also, it looks like it was only running for two minutes before being killed.

[quevas13]

I've no restriction, the previous tutorial worked fine.
I've killed the process after the curl call to get the node output.

[quevas13]

After the call the other secret store nodes logs the following error

0x53ea…2c53: network error 'Connection refused (os error 111)' when establishing outbound connection with 127.0.0.1:8011

Then I have to restart the SS1 node to get rid from the error

[jam10o-new]

Could you run with -l jsonrpc,secretstore_net=trace (and additionally, can you also consider building beta or stable instead of master?)

[quevas13]

Ok, here is the new output

Loading config file from conf/ss1.toml
Option '--no-dapps' has been removed and is no longer supported.
2018-12-14 12:16:27  main INFO parity_ethereum::run  Starting Parity-Ethereum/v2.3.0-unstable-23d25a0-20181207/x86_64-linux-gnu/rustc1.31.0
2018-12-14 12:16:27  main INFO parity_ethereum::run  Keys path db.ss1/keys/DevelopmentChain
2018-12-14 12:16:27  main INFO parity_ethereum::run  DB path db.ss1/chains/DevelopmentChain/db/1484bce8c021f2ca
2018-12-14 12:16:27  main INFO parity_ethereum::run  State DB configuration: fast
2018-12-14 12:16:27  main INFO parity_ethereum::run  Operating mode: active
2018-12-14 12:16:28  main INFO ethcore_service::service  Configured for DevelopmentChain using InstantSeal engine
2018-12-14 12:16:28  main INFO parity_ethereum::secretstore::server  Starting SecretStore node: 0xbe24d7d474aef75a64caa8bbc4c25075d613d8cf3229323c97b4b3831c34ed7acff3d5b2852b7acdb498f62400c077ee6456838c93a242bd68daf14cae8c989d
2018-12-14 12:16:28  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: inserting connection to 0x53ea…2c53 at 127.0.0.1:8013. Connected to 1 of 2 nodes
2018-12-14 12:16:28  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: inserting connection to 0x3193…fdca at 127.0.0.1:8012. Connected to 2 of 2 nodes
2018-12-14 12:16:34  IO Worker #0 INFO network  Public node URL: enode://dc47f29c22821e3cfc718029d7b7d717af06a0fbede241448466a47f6901ad25e31eca118d890d688b24bdad6f8bc301a9831312a7bb081739d8dee2dc83e13a@192.168.137.169:30301
2018-12-14 12:16:38  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: executing maintain procedures
2018-12-14 12:16:48  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: executing maintain procedures
2018-12-14 12:16:58  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: executing maintain procedures
2018-12-14 12:16:58  IO Worker #0 INFO import     4/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
2018-12-14 12:17:05  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: received message Cluster.KeepAlive from 0x53ea…2c53
2018-12-14 12:17:08  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: received message Cluster.KeepAlive from 0x3193…fdca
2018-12-14 12:17:08  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: executing maintain procedures
2018-12-14 12:17:17  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: sent message KeyVersionNegotiation.RequestKeyVersions to 0x3193…fdca
2018-12-14 12:17:17  tokio-runtime-worker-0 TRACE secretstore_net  0xbe24…989d: sent message KeyVersionNegotiation.RequestKeyVersions to 0x53ea…2c53
2018-12-14 12:17:28  IO Worker #0 INFO import     4/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs
2018-12-14 12:17:58  IO Worker #3 INFO import     4/25 peers   9 KiB chain 22 KiB db 0 bytes queue 10 KiB sync  RPC:  0 conn,    0 req/s,    0 µs```

[quevas13]

I was building with master as requested by tutorial. Today I will try building with different branches...

[quevas13]

I've built using beta brach and now after the call I get this response

{"jsonrpc":"2.0","error":{"code":-32024,"message":"Private transactions call failed.","data":"Error(Encrypt("Forbidden"), State { next_error: None, backtrace: InternalBacktrace { backtrace: None } })"},"id":1}

[quevas13]

Ok, now that I can read the error I've found the problem. I've configured the ssx.toml with the wrong permissioning contract address (it wasn't a permissioning contract at all).
Now I've configured the right contract address and everything is working fine.

Thank you for your support.

[quevas13]

The beta version I'm using is
Parity Ethereum
version Parity-Ethereum/v2.2.4-unstable-f44d885-20181205/x86_64-linux-gnu/rustc1.31.0

I think this could be still an open issue for the 2.3 version because the curl called using the master branch hangs instead of returning an error.

[jam10o-new]

@grbIzl do you think this is related to #9641?

[grbIzl]

@joshua-mir most probably the described problem was fixed in #9979 But in order to make sure, we need to trace it with logging target privatetx=trace enabled