jl777 / libnspv Goto Github PK

Tests show that requests via libnspv might perform with delay of several seconds.
Libnspv uses libevent2 library to send/receive messages over net. It looks like libevent2 does buffering internally before actual sending.
I search or something like a flush feature but according to this it is not possible yet:

Currently (as of Libevent 2.0.5-beta), bufferevent_flush() is only implemented for some bufferevent types. In particular, socket-based bufferevents don’t have it. http://www.wangafu.net/~nickm/libevent-book/Ref6_bufferevent.html

Maybe we need to contact libevent2 devs to get more info.

it might make sense to force having a prevtxid field so that the entire set of (related) opreturns can be retrieved

hex: 0400008085202f89013d8fc1f09d8a24b215296e12d434ca31e106871bdb77ff45f8cecdc9979ee26c000000006a473044022047f9f02739528df5196560003db99af1c2e3b9f82bdb2dcad0aa0fb0c9cabe8c022057e27b6fc499007bcadaa8cda7dad6a990bbfc0b7de096ab9b7acd6de78f8588012103ab871db1d39d3f3894df53bc1d3018a243b6768dffdb2a4c038fd92213854b99feffffff01d0e89600000000001976a914fc46abe3748209db896e25faf39090679f17475588acc1ee8d5d000000000000000000000000000000

curl --data-binary '{"jsonrpc": "2.0", "id":"curltest", "method": "broadcast", "params": ["0400008085202f89013d8fc1f09d8a24b215296e12d434ca31e106871bdb77ff45f8cecdc9979ee26c000000006a473044022047f9f02739528df5196560003db99af1c2e3b9f82bdb2dcad0aa0fb0c9cabe8c022057e27b6fc499007bcadaa8cda7dad6a990bbfc0b7de096ab9b7acd6de78f8588012103ab871db1d39d3f3894df53bc1d3018a243b6768dffdb2a4c038fd92213854b99feffffff01d0e89600000000001976a914fc46abe3748209db896e25faf39090679f17475588acc1ee8d5d000000000000000000000000000000"] }' -H 'content-type: text/plain;' http://127.0.0.1:7771/
{"result":"success","expected":"71ddf2b213fdc7efc60ed1ece6329578858e2c9609da783adabd7baa53fc1128","broadcast":"0000000000000000000000000000000000000000000000000000000000000000","retcode":-2,"type":"timeout","lastpeer":"78.47.196.146:7770"}

also have some standard set of locations to search, Desktop, Downloads, Pictures, current dir

'skipcount' parameter has currently no effect.

To reporduce:

• take address with X amount of utxos/transactions
• call listtransactions with skipcount = 0
• call listtransactions with skipcount = N, N > 0

result: calls have same output
expected: 2nd call should have N less transactions/utxos in output

Curls might be used to check (for KMD):

curl --data-binary '{"jsonrpc": "2.0", "id":"curltest", "method": "listtransactions", "params": ["RBCSvPzYtTZ51RYbsDLKkQ58Mj5TuRRNeh", 0, 0] }' -H 'content-type: text/plain;' http://127.0.0.1:7771/

curl --data-binary '{"jsonrpc": "2.0", "id":"curltest", "method": "listtransactions", "params": ["RBCSvPzYtTZ51RYbsDLKkQ58Mj5TuRRNeh", 0, 30] }' -H 'content-type: text/plain;' http://127.0.0.1:7771/

curl --data-binary '{"jsonrpc": "2.0", "id":"curltest", "method": "listunspent", "params": ["RBCSvPzYtTZ51RYbsDLKkQ58Mj5TuRRNeh", 0, 0] }' -H 'content-type: text/plain;' http://127.0.0.1:7771/

curl --data-binary '{"jsonrpc": "2.0", "id":"curltest", "method": "listunspent", "params": ["RBCSvPzYtTZ51RYbsDLKkQ58Mj5TuRRNeh", 0, 30] }' -H 'content-type: text/plain;' http://127.0.0.1:7771/

Hello,
First let me say thank you for this wallet. It is nicely done. I've installed the wallet. When I run ./nspv file I get "parse error of coins file." The ./bitcointool works perfect.

If nspv executable connected and disconnected from several nodes it might fail on shutdown when node array is freed.
Fixed by clearing node->event_bev on node disconnecting

Using OUR as an example. Found similar behavior for ILN, RICK
Using the conf:

{
    "coin": "OUR",
    "asset": "OUR",
    "fname": "OUR Crypto Union",
    "rpcport": 45672,
    "p2p": 45671,
    "nSPV": "51.255.195.65, 37.187.225.231",
    "magic": "b76686a7",
    "mm2": 1
  }

"51.255.195.65, 37.187.225.231" are seed nodes from launch parameters.
The client shuts down with the following output

Found (OUR) magic.b76686a7, p2p.45671 seeds.(51.255.195.65, 37.187.225.231)
027e3758c3a65b12aa1046462b486d0a63bfa1beae327897f56c5cfb7daaae71 genesisblockhash OUR
Start NSPV_rpcloop.45672
>>>>>>>>>> NSPV_rpcloop 127.0.0.1:45672 bind sock.3 API enabled at unixtime.1580745093 <<<<<<<<<
Discover OUR peers...Trying to connect to 1 51.255.195.65:45671
Trying to connect to 2 37.187.225.231:45671
Connected to node 1 51.255.195.65:45671
Connected to node 2 37.187.225.231:45671
end of client runloop

Launch parameters of OUR for reference:

./komodod -ac_name=OUR -ac_reward=1478310502 -ac_halving=525600 -ac_cc=42 -ac_supply=100000000 -ac_perc=77700 -ac_staked=93 -ac_pubkey=02652a3f3e00b3a1875a918314f0bac838d6dd189a346fa623f5efe9541ac0b98c -ac_public=1 -addnode=51.255.195.65 -addnode=217.182.129.38 -addnode=37.187.225.231

during spend rpc function, we can find out that a utxo has been spent via the txproof result. i think if we get such a failure, we can go into a secondary spend logic, which updates the list of utxo based on the already spent. maybe even issue a mempool search.

separately, it can be useful to be able to spend utxo in the mempool. so this issue is the sane handling of the mempool status of utxo

nSPV full nodes print this in debug log, likely due to nSPV enabled node without addressindex=1 trying to satisfy utxos/txids getnSPV messages

// @blackjok3r @dimxy @mihailo implement the CC tx creation functions here
// instead of a swissarmy knife finalizeCCtx, i think it is better to pass in the specific info needed into a CC signing function. this would eliminate the comparing to all the different possibilities
// since the CC rpc that creates the tx will know which vins are normal and which ones are CC, and most importantly what type of CC vin it is, it will be much simpler finalize function, though it will mean all the CC rpc calls will have to do more work. that was the rationale behind FinalizeCCtx, but i hear a lot of complaints about the complexity it has become.
// please make a new way of doing CC tx that wont lead to complaints later. let us start with faucetget

There are a handful of valgrind errors reported when valgrind ./tests is run. This issue is present in libbtc, too. [but has now been fixed. also fixed was a bug where when compiled in release mode, random bytes generation could rarely silently fail and make reproducible keys.]

Use "txfee" param from coins file to calculate max amount for send method.

./komodod -nSPV=1

komodo daemon may crash on nspv_spend call.

Script example to help with reproduction:

#!/bin/bash

./komodo-cli nspv_login  _wif_
sleep 1
while :
do
  ./komodo-cli nspv_logout
  sleep 1
  ./komodo-cli nspv_login  _wif_
  sleep 1
  ./komodo-cli nspv_spend  _spend_addr_  0.01
  sleep 1
done

After 2 to 6 iterations you should get segfault.

Note: komodod does not crash if you just do:
nspv_login
snpv_spend in loop
Issue happens only in case of successive log_in log_out log_in calls.

backtrace examples:
https://paste.ubuntu.com/p/9CzV52djhv/

Hi, I recently acquired merge access with libbtc. However, I have only a little capacity to maintain it.

Your fork seems more active nowadays. Do you have any thoughts on sharing work?