Bitcoin full node and query server
January 2020
Archive of the libbitcoin Slack #general channel.
Thursday, January 9, 2020
vdeurzen12:19
Any tried the litecoin config with libbitcoin recently? I'm trying to see if it works but I'm running into either stale or wrong peers and a header sync doesn't really start 😕
6 replies · neillm, vdeurzen · last Jan 09, 2020
neillm12:46
I had tried it not too long ago and completed a full sync. Can probably look at the config and revisit this weekend.
neillm12:49
Assumes a localhost sync'd litecoin peer.
bs.cfg.litecoin
# Libbitcoin Server configuration file [log] # The debug log file path, defaults to 'debug.log'. debug_file = debug.log # The error log file path, defaults to 'error.log'. error_file = error.log # The log archive directory, defaults to 'archive'. archive_directory = archive.litecoin # The size at which a log is archived, defaults to 10000000 (0 disables). rotation_size = 10000000 # The minimum free space required in the archive directory, defaults to 0. minimum_free_space = 0 # The maximum combined size of archived logs, defaults to 0 (maximum). maximum_archive_size = 0 # The maximum number of logs to archive, defaults to 0 (maximum). maximum_archive_files = 10 # The address of the statistics collection server, defaults to none. statistics_server = 0.0.0.0:0 # Enable verbose logging, defaults to false. verbose = false [bitcoin] # The activation time for bip16 in unix time, defaults to 1333238400. bip16_activation_time = 1333238400 # The hash:height checkpoint for bip34 activation, defaults to 000000000000024b89b42a942fe0d9fea3bb44ab7bd1b19115dd6a759c0808b8:227931. bip34_active_checkpoint = fa09d204a83a768ed5a7c8d441fa62f2043abf420cff1226c7b4329aeb9d51cf:710000 # The block height to freeze the bip34 softfork as in bip90, defaults to 227931. bip34_freeze = 710000 # The block height to freeze the bip65 softfork as in bip90, defaults to 388381. bip65_freeze = 1201535 # The block height to freeze the bip66 softfork as in bip90, defaults to 363725. bip66_freeze = 1201535 # The hash:height checkpoint for bip9 bit0 activation, defaults to 000000000000000004a1b34462cb8aeebd5799177f7a29cf28f2d1961716b5b5:419328. bip9_bit0_active_checkpoint = 2985cdced60b267cf1c78ff009d4ae037300ecc2d751a4b01a9f2705bbe05db7:21111 # The hash:height checkpoint for bip9 bit1 activation, defaults to 0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893:481824. bip9_bit1_active_checkpoint = b50ce9202c152e481ca509156028af954654ed13e4b0656eb497554aa753db0b:1201535 # The target block period in seconds, defaults to 600. block_spacing_seconds = 150 # The genesis block.full file
also feathercoin 😄
Now I'm wondering if I can get it to work for bch / bsv, any guidance on how I should go about configuring that?
Including Testnet and regtest.
vdeurzen16:03
Ok, I'm guessing some of the more significant changes aren't in there, or is it fairly minor (i.e. I'm happy to help get implement it, if I can find the time)
Tuesday, January 14, 2020
jungly09:19
With Schnorr signatures and the proposed batch verification of signatures do any efforts to parallelise script verification in a single block kind of become a moot point? It’ll all come down to the choice of EC multiplication algorithm used, as discussed in the schnorr-bip.
Am I getting this right?
evoskuil09:25
Transactions are still signed independent of each other, so this doesn’t change. This is a distinction issue from static legacy script verification (ie without previous outputs as required by segwit txs).
jungly09:29
That makes sense. So transactions with more than 100 or so signature verifications would make good candidates for batch verification. Most of the other “normal” transactions not so much. Right?
evoskuil13:17
You batch inputs within an unconfirmed tx and inputs within a block (across txs), not just for signatures, the entire script. There is no reason to isolate the signature portion.
Just another strange Core optimization, along with signature caching.
Wednesday, January 15, 2020
D
Dominik10:09
Hi, we're trying to sync a libbitcoin-server instance, the machine has 32 GB RAM and more than enough SSD disk space. We've used the default sync settings. After block approx. 450'000, the server stalls and doesn't make any progress. Restarting doesn't help. Does anyone have a hint for where to go digging?
2 replies · neillm · last Jan 17, 2020
neillm02:17
Enable verbose logging and see if anything useful shows up. Something is odd if the node is running and not doing anything (as opposed to just taking a while to process). For an initial sync, I recommend using the
peer = localhost:8333 option if possible where you're running a sync'd bitcoind, so that you don't have to rely on random peers. Also, as you do sync higher and higher, making snapshots of progress may help in case of an unclean shutdown at some point in the future.neillm02:18
During sync, if you have a local peer to sync from, you can change outbound to 0 also (isolating your network to just the single local peer).
The master branches are WIP and not released yet.
the
debug.log contains lots of Failure connecting outbound: resolving hostname failed.I don't understand yet why because the network configuration didn't change
jungly12:09
Seems like your network connection is acting up. What is your inbound_connections and outbound_connections set to? Could you try and reduce those numbers and see if that helps?
1 reply · jungly · last Jan 15, 2020
jungly13:23
0 and 2? That seems different from the sample bn.cfg included in the repo
https://github.com/libbitcoin/libbitcoin-node/blob/5fd70e3951a17a7ac9312179ffb67467d087b93c/data/bn.cfg#L79
Fil13:16
What's the
bx command to get the list of connected peers? I checked the wiki but cannot really find the correct command.1 reply · jungly · last Jan 15, 2020
Fil13:54
connected to other bitcoin nodes. I'm looking for a command similar to
bitcoin-cli's getpeerinfo.Do you mean to query bs?
What would a client do with a list of peers?
Ie wallet
jungly14:01
i wonder if clever use of netstat could help figure out how many connections are open etc
Fil14:02
yes, I know that the peer connections are spit out to the console but then I need to parse the thing to be able to count the number of current peers. That's why I was wondering if there's a faster way 😉
But thanks for the quick response. We'll try to tune the params @jungly suggested above.
evoskuil14:05
You need to be able to parse the console to determine anything it says, but it’s debugging, not automation.
(edited)Thursday, January 30, 2020
I think for the public testnets its currently set far too high
bitcoinfees.earn.com
Predicting bitcoin fees for transactions. Fees are displayed in Satoshis/byte of data. Miners usually include transactions with the highest fees first.
Friday, January 31, 2020
lclc08:28
Hey guys, at inacta AG we’ve setup a new libbitcoin-server we use for a clients new product we are developing. Unfortunately it’s syncing now since 1 month but by now we are only at height 510074.
Our machine has 8 Cores, 32 GB of RAM and 2 TB SSD (the HUGE instance from Exoscale listed here: https://www.exoscale.com/pricing/#storage-optimized-instances), running Ubuntu 18.04 LTS.
The hardware is not at the limit at all, so it can’t be that.
We are running the latest release (v3.6.0 - looking forward to 4.0! ;))
We have been using the default config at first, then I tweaked it a bit like this:
inbound_connections = 10
outbound_connections = 10
Added a bunch of peers from the Bitcoin Core seed file:
peer=2.24.141.73:8333
peer=5.8.18.29:8333
peer=5.43.228.99:8333
peer=5.145.10.122:8333
peer=5.166.35.47:8333
peer=5.188.187.130:8333
peer=108.15.243.207:8333
peer=108.58.252.82:8333
peer=108.160.202.208:8333
peer=108.213.205.103:8333
peer=109.72.83.127:8333
peer=109.99.63.159:8333
peer=194.71.225.55:8333
peer=194.135.135.69:8333
peer=194.158.92.150:8333
peer=195.13.220.165:8333
Yesterday I’ve also added a checkpoint from ~16h ago, but that doesn’t help either.
checkpoint = 000000000000000000047fa625a4b78638edb31ef2a9bd641b44765596adcca3:615220
It seems the problem is that we just don’t get many blocks from our peers. Any ideas what to try next?
Thanks.
(edited)exoscale.com
Simple and predictable, no surprises cloud pricing. No long-term commitments or complicated usage discounts. Cloud hosting that's simple and fair.
The server is running on 194.182.165.121
e.g. bx fetch-height tcp://194.182.165.121:9091 etc
Latest output:
08:29:10.035267 INFO [blockchain] Block [510098] 1 txs 1 ins 117 wms 0 vms 70 vµs 33 rµs 20 cµs 9 pµs 2 aµs 4 sµs 3538 dµs 0.000000 08:29:10.039090 WARNING [network] Invalid version payload from [144.217.240.89:44620] trailing bytes. 08:29:10.053009 INFO [network] Connected inbound channel [46.101.246.115:43364] (21) 08:29:10.084738 INFO [network] Connected manual channel [194.158.92.150:8333] as [194.158.92.150:8333] (20) 08:29:10.138439 INFO [network] Connected inbound channel [162.218.65.198:53203] (21) 08:29:48.869217 INFO [blockchain] Block [510099] 1438 txs 5755 ins 32 wms 27 vms 5 vµs 3 rµs 1 cµs 0 pµs 0 aµs 0 sµs 6734 dµs 0.000000 08:29:48.907367 WARNING [network] Failure connecting [108.15.243.207:8333] manually: connection timed out 08:29:48.910335 WARNING [network] Failure connecting [5.166.35.47:8333] manually: connection timed out 08:29:48.910391 WARNING [network] Failure connecting [108.160.202.208:8333] manually: connection timed out 08:29:48.910414 WARNING [network] Failure connecting [2.24.141.73:8333] manually: connection timed out 08:29:48.911704 INFO [network] Manual channel failed to start [109.72.83.127:8333] connection timed out 08:29:48.978173 WARNING [network] Failure connecting [195.13.220.165:8333] manually: operation failed 08:29:49.004487 INFO [network] Connected manual channel [5.43.228.99:8333] as [5.43.228.99:8333] (14) 08:29:49.005072 INFO [network] Connected manual channel [109.72.83.127:8333] as [109.72.83.127:8333] (15) 08:29:49.046005 INFO [network] Connected manual channel [194.71.225.55:8333] as [194.71.225.55:8333] (16) 08:29:49.051943 INFO [network] Connected manual channel [5.188.187.130:8333] as [5.188.187.130:8333] (17) 08:30:21.766613 INFO [blockchain] Block [510100] 754 txs 6258 ins 82 wms 26 vms 4 vµs 3 rµs 1 cµs 0 pµs 0 aµs 0 sµs 5219 dµs 0.000000 08:30:21.768874 WARNING [network] Failure connecting [108.15.243.207:8333] manually: connection timed out 08:30:21.768927 WARNING [network] Failure connecting [5.166.35.47:8333] manually: connection timed out 08:30:21.768950 WARNING [network] Failure connecting [108.160.202.208:8333] manually: connection timed out 08:30:21.768978 WARNING [network] Failure connecting [2.24.141.73:8333] manually: connection timed out 08:30:21.844320 WARNING [network] Failure connecting [195.13.220.165:8333] manually: operation failed 08:30:21.865926 INFO [network] Connected manual channel [5.145.10.122:8333] as [5.145.10.122:8333] (15) 08:30:21.872746 INFO [network] Connected inbound channel [51.15.60.194:47702] (16) 08:30:21.930558 INFO [network] Connected manual channel [194.135.135.69:8333] as [194.135.135.69:8333] (16) 08:30:21.958438 INFO [network] Connected manual channel [109.72.83.127:8333] as [109.72.83.127:8333] (17) 08:30:21.959490 INFO [network] Connected inbound channel [23.92.36.2:26783] (18) 08:30:22.032276 INFO [network] Connected manual channel [108.58.252.82:8333] as [108.58.252.82:8333] (19)
(same problem / server @Dominik and @Fil were talking about earlier - we run out of ideas)
neillm12:33
@lclc Try removing all inbound/outbound peers and setting
peer = <localhost or something on same subnet:8333 where that endpoint is an already sync'd bitcoind. I tend to do that for initial sync because it's quicker/more reliable than syncing from internet peers.lclc15:38
I’m sure that would improve things but only 1 block every few minutes - there must be something else wrong too?
Currently there is no Core node running on the same localhost or subnet
1 reply · neillm · last Feb 08, 2020
neillm02:20
I wonder if your node is getting banned from peers, and struggling to find new ones that sends blocks on occasion before banning again. I don't know much about the ban policies of popular nodes out there.
(edited)