Hi, I download the latest source code and successfully compiled using make && make install. However, there is no binary file generated in the test directory, is it expected or I missed something? Thanks.

When connecting to a peer in order to relay a transaction is is useful to know that the connection allows tx relay. Currently there is no way to configure the session such that its connections require the peer to allow relay. This would not guarantee that the peer would accept the tx but it improves the probability.

The comparison must be port-independent.

Complete in #161

04:53:51.217711 INFO [network] Connected to outbound channel [45.33.50.84:8333]
04:53:51.248229 WARNING [network] Invalid encinit payload from [45.33.50.84:8333] object does not exist

See comments on 2017-02-12 here:
https://github.com/bitcoin/bips/wiki/Comments:BIP-0151

Police Terror:

I'm using the current master branch to sync with testnet, but I'm
getting this error:

...
14:15:56.657549 WARNING [server] Failed to connect secure notification
worker: operation failed
14:15:56.756083 WARNING [server] Failed to connect secure notification
worker: operation failed
terminate called after throwing an instance of 'std::runtime_error'
what(): random_device::random_device(const std::string&)
14:15:57.415901 INFO [server] Stop signal detected (code: 6).
Aborted (core dumped)

Here's what debug.log is showing:

14:15:57.415478 DEBUG [network] Failure connecting outbound: operation
failed
14:15:57.415501 DEBUG [network] Failure connecting outbound: operation
failed
14:15:57.415570 DEBUG [node] Redundant block
[0000000057bd296621bc2f314e3594c412a0cd9e94f1083554c3184160612450] from
[177.189.250.198:18333]
14:15:57.415605 DEBUG [network] Connecting to [121.40.72.188:18333]
14:15:57.415703 DEBUG [network] Valid block payload from
[177.189.250.198:18333](207 bytes)
14:15:57.415757 DEBUG [network] Connecting to [212.93.226.185:18333]
14:15:57.415816 DEBUG [network] Connecting to [2.55.186.124:18333]
14:15:57.415901 INFO [server] Stop signal detected (code: 6).
14:15:57.415937 DEBUG [node] Redundant block
[000000008a675b534ea86b312f29c9fdcce7b7b07ca1879c144b8e20215ac201] from
[177.189.250.198:18333]
14:15:57.416008 DEBUG [network] Valid block payload from
[177.189.250.198:18333](207 bytes)
g

I've attached the .cfg file I'm using.

Looking at libbitcoin/src/utility/random.cpp, I see that
nonzero_pseudo_random() is throwing. Why isn't that an assert instead?

https://github.com/libbitcoin/libbitcoin/blob/master/src/utility/random.cpp#L46

Here is the backtrace:

9 libbitcoin::pseudo_random () at src/utility/random.cpp:39

10 0x00007ffff5a3d48d in libbitcoin::network::hosts::fetch

(this=this@entry=0x657310,
out=...) at src/collections/hosts.cpp:76

11 0x00007ffff5a27e7a in

libbitcoin::network::p2p::fetch_address(std::function<void
(std::error_code const&, libbitcoin::message::network_address const&)>)
const (this=0x656ad0,
handler=...) at src/p2p.cpp:430

12 0x00007ffff5a5ae5f in

libbitcoin::network::session::fetch_address(std::function<void
(std::error_code const&, libbitcoin::config::authority const&)>) const (
this=this@entry=0x7fff280d6330, handler=...) at
src/sessions/session.cpp:83

13 0x00007ffff5a6064e in

libbitcoin::network::session_batch::new_connect(std::shared_ptrlibbitcoin::network::connector,
std::function<void (std::error_code const&,
std::shared_ptrlibbitcoin::network::channel)>)
(this=this@entry=0x7fff280d6330,
connect=std::shared_ptr (count 115, weak 1) 0x7ffef03f5760, handler=...)
at src/sessions/session_batch.cpp:70

14 0x00007ffff5a60b53 in

libbitcoin::network::session_batch::connect(std::shared_ptrlibbitcoin::network::connector,
std::function<void (std::error_code const&,
std::shared_ptrlibbitcoin::network::channel)>) (this=0x7fff280d6330,
connect=std::shared_ptr (count 115, weak 1) 0x7ffef03f5760, handler=...)
at src/sessions/session_batch.cpp:56

15 0x00007ffff5a6f335 in

libbitcoin::network::session_outbound::new_connection (
this=this@entry=0x7fff280d6330,
connect=std::shared_ptr (count 115, weak 1) 0x7ffef03f5760)
at src/sessions/session_outbound.cpp:87

16 0x00007ffff5a6f7d1 in

libbitcoin::network::session_outbound::handle_connect (
this=0x7fff280d6330, ec=..., channel=...,
connect=std::shared_ptr (count 115, weak 1) 0x7ffef03f5760)
at src/sessions/session_outbound.cpp:97

Incoming blocks block the receiver during processing (of the second block waiting on the first). However outgoing blocks are processed sequentially but buffered on the send call. So all queried blocks will accumulate in the send buffer (dispatch sequencer via dispathc.lock/unlock). This can produce a low memory state for the sender.

This results under heavy load or short heartbeat times because the pending_ member is not protected by mutex. A simple protection will resolve the issue and result in a proper drop of the channel due to high latency vs. invalid pong nonce).

This is currently stubbed in with channels registered for stop subscription. Initially fulfill as address broadcaster.

This result in crashes during connection.

This resulted in ever-increasing connection count, though not leaked as they were properly released at shutdown.

Incoming message checksum can simply be disabled, which is the default configuration, but outgoing cannot, so:

Use the existing tx hash to obtain for the message checksum. This is the only message object that would have a precomputed bitcoin hash, but is is also the most common larger object.

Cache checksums on message objects and parameterize in send so that they are not recreated for each send of the same instance.

If checksum validation is enabled, cache the block value onto the message object for storage without the need for re-computation.

This can prevent operation due to cycling through a small list of of likely dysfunctional addresses or nodes.

The previous network payload maximum is below the new ~4,000,000 block/tx size max.

With 500+ connections and a large address pool capacity we encounter an exception on the upgrade lock within the hosts class. This lock is too granular and serves only to support thread safe merge of addresses from multiple channels. This can be resolved by reducing the lock granularity when handling the merge of a address list.

Connections may be high frequency, disrupting the console.

Currently we can receive an invalid pong nonce for one of three reasons. Either the peer has sent the wrong nonce, traffic has been modified/faulted, or we have sent a second before receiving the first - resetting our own expectation. The former two problems should result in drop of the peer. However we are retaining such peers because the last problem is common. This problem breaks our DOS assumption that we only allow traffic that is expected.

To resolve this we should drop the peer at the point when we are configured to send the next nonce if the previously-expected pong has not yet arrived and cleared it. This results in the configured heartbeat time becoming a maximum channel latency. Given the very high latency we've seen with some peers this would be beneficial (for both ends of the connection). We don't see this warning too often, but when we do it implies that either our own node or the peer is bogged down.

Close does occur upon process close and when self drops (for expiration).

I cloned master, and did standard build steps:

./autogen.sh
./configure
make 

Got this:

  CXX      src/libbitcoin_network_la-acceptor.lo
  CXX      src/libbitcoin_network_la-channel.lo
  CXX      src/libbitcoin_network_la-hosts.lo
  CXX      src/libbitcoin_network_la-connector.lo
  CXX      src/libbitcoin_network_la-message_subscriber.lo
  CXX      src/libbitcoin_network_la-p2p.lo
  CXX      src/libbitcoin_network_la-proxy.lo
  CXX      src/libbitcoin_network_la-settings.lo
In file included from src/settings.cpp:19:
./include/bitcoin/network/settings.hpp:24:10: fatal error: bitcoin/system.hpp: No such file or directory
   24 | #include <bitcoin/system.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:1053: src/libbitcoin_network_la-settings.lo] Error 1
make: *** Waiting for unfinished jobs....
In file included from src/acceptor.cpp:19:
./include/bitcoin/network/acceptor.hpp:26:10: fatal error: bitcoin/system.hpp: No such file or directory
   26 | #include <bitcoin/system.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:1004: src/libbitcoin_network_la-acceptor.lo] Error 1
In file included from src/connector.cpp:19:
./include/bitcoin/network/connector.hpp:26:10: fatal error: bitcoin/system.hpp: No such file or directory
   26 | #include <bitcoin/system.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:1018: src/libbitcoin_network_la-connector.lo] Error 1
In file included from src/proxy.cpp:19:
./include/bitcoin/network/proxy.hpp:29:10: fatal error: bitcoin/system.hpp: No such file or directory
   29 | #include <bitcoin/system.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:1046: src/libbitcoin_network_la-proxy.lo] Error 1
In file included from src/channel.cpp:19:
./include/bitcoin/network/channel.hpp:28:10: fatal error: bitcoin/system.hpp: No such file or directory
   28 | #include <bitcoin/system.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
In file included from src/p2p.cpp:19:
./include/bitcoin/network/p2p.hpp:29:10: fatal error: bitcoin/system.hpp: No such file or directory
   29 | #include <bitcoin/system.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
In file included from src/message_subscriber.cpp:19:
./include/bitcoin/network/message_subscriber.hpp:28:10: fatal error: bitcoin/system.hpp: No such file or directory
   28 | #include <bitcoin/system.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:1011: src/libbitcoin_network_la-channel.lo] Error 1
make: *** [Makefile:1039: src/libbitcoin_network_la-p2p.lo] Error 1
make: *** [Makefile:1032: src/libbitcoin_network_la-message_subscriber.lo] Error 1
In file included from src/hosts.cpp:19:
./include/bitcoin/network/hosts.hpp:27:10: fatal error: bitcoin/system.hpp: No such file or directory
   27 | #include <bitcoin/system.hpp>

I noticed that this library uses boost, but no boost headers included. Am I supposed to copy boost headers to /usr/local/include/bitcoin?

hello, share the working code for subscribe transactions to display the bitcoin address

libbitcoin/libbitcoin-server#339

Given the current design:

• Protocols should register for all message types that the session will solicit or that may be sent by peers unsolicited.
• The start handler should block until initial protocols are registered (see related issue).
• Any post-handshake solicitation should register subscription prior to sending the solicitation and deregister if and when the solicitation is expired.

any message that is received without a registered handler is in violation of the session's intended protocol and should result in channel stop. Otherwise DOS based on sending large unhandled messages is unchecked.

A session could devise other DOS protections, such as channel lifetime or byte limits so this feature should be enabled at proxy construct.

Do we support upnp ?

This may be related to: #56

Currently we send only our own address.

Also capture the peer's address in our address pool when protocol_address_31402 starts up.

Currently messages cannot be unsubscribed without dropping channel. This can be resolved by changing the message subscribers in the message pump to unsubscribers.

Add dynamic configuration using std:cin (start with close and log verbosity cycle).
Has threadpool, is a loop over cin (line = std::getline(std::cin) or std::cin >> ch).
Start, stop (restartable), configured events (key words and/or key strokes).
Upon registered event fires notification with event type (stop is well known type).
Handlers are invoked on a strand of the input class threadpool.

The dispatcher's sequencer maintains the send queue, however it only clears via a process of unwinding all locks. By incorporating a stop check in do_send this unwinding will be accelerated by avoiding the call to async_write.

The following shutdown sequence failed to close all sessions:

23:30:00.194140 INFO [node] Stop signal detected (code: 2).
23:30:00.201173 INFO [node] Please wait while the node is stopping...
23:30:00.243209 DEBUG [network] Failure in handshake with [73.229.104.201:8333] channel stopped
23:30:00.244203 DEBUG [network] Outbound channel stopped [73.229.104.201:8333] channel stopped
23:30:00.244203 DEBUG [network] Outbound channel stopped [2.126.21.192:8333] success
23:30:00.244203 DEBUG [network] Suspended outbound connection.
23:30:00.244203 DEBUG [network] Suspended outbound connection.
23:30:00.244203 DEBUG [network] Outbound channel failed to start [73.229.104.201:8333] channel stopped
23:30:00.244203 DEBUG [network] Stopped block_in protocol for [2.126.21.192:8333].
23:30:00.244203 DEBUG [network] Stopped block_out protocol for [2.126.21.192:8333].
23:30:00.244203 DEBUG [network] Stopped transaction_in protocol for [2.126.21.192:8333].
23:30:00.244203 DEBUG [network] Stopped transaction_out protocol for [2.126.21.192:8333].
23:30:00.244203 DEBUG [network] Outbound channel stopped [217.23.14.74:8333] success
23:30:00.244203 DEBUG [network] Suspended outbound connection.
23:30:00.244203 DEBUG [network] Stopped block_in protocol for [217.23.14.74:8333].
23:30:00.244203 DEBUG [network] Outbound channel stopped [213.136.71.143:8333] success
23:30:00.244203 DEBUG [network] Suspended outbound connection.
23:30:00.244203 DEBUG [network] Outbound channel stopped [47.89.179.113:8333] success
23:30:00.244203 DEBUG [network] Stopped block_in protocol for [213.136.71.143:8333].
23:30:00.244203 DEBUG [network] Suspended outbound connection.
23:30:00.244203 DEBUG [network] Outbound channel stopped [73.133.87.6:8333] success
23:30:00.244203 DEBUG [network] Stopped block_in protocol for [47.89.179.113:8333].
23:30:00.244203 DEBUG [network] Suspended outbound connection.
23:30:00.244203 DEBUG [network] Stopped block_in protocol for [73.133.87.6:8333].
23:30:25.488952 DEBUG [network] Fired protocol_block_in timer on [62.210.6.26:8333] success
23:31:25.489304 DEBUG [network] Fired protocol_block_in timer on [62.210.6.26:8333] success
23:32:25.489596 DEBUG [network] Fired protocol_block_in timer on [62.210.6.26:8333] success
23:33:23.545067 DEBUG [network] Fired protocol_ping timer on [[2601:645:8300:e5f0:e8ef:c2c5:5955:4797]:8333] success
23:33:23.545568 DEBUG [network] Failure sending ping to [[2601:645:8300:e5f0:e8ef:c2c5:5955:4797]:8333] unknown error
23:33:25.489967 DEBUG [network] Fired protocol_block_in timer on [62.210.6.26:8333] success

Create log levels with independent macros, parameterize and/or compiled out. LOG_FAULT (unexpected) < LOG_PROGRESS (chain) < LOG_INFO (messages) < LOG_VERBOSE (debug)
Logs are cumulative, redundant, and independently directable to any stream, including rotable files. File names are hard-wired into a configurable directory, like database. Console logs at an independently-specified level. Add performance timers logging to logger.

Running tests...
/usr/local/bin/ctest --force-new-ctest-process 
Test project /home/runner/work/libbitcoin-network/libbitcoin-network/obj/nix-gnu-debug-shared
    Start 1: libbitcoin-network-test
1/1 Test #1: libbitcoin-network-test ..........***Failed    0.26 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.33 sec

The following tests FAILED:
	  1 - libbitcoin-network-test (Failed)
Errors while running CTest
Output from these tests are in: /home/runner/work/libbitcoin-network/libbitcoin-network/obj/nix-gnu-debug-shared/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
make: *** [Makefile:71: test] Error 8

Run cat /home/runner/work/libbitcoin-network/libbitcoin-network/Testing/Temporary/LastTest.log
cat: /home/runner/work/libbitcoin-network/libbitcoin-network/Testing/Temporary/LastTest.log: No such file or directory

https://github.com/libbitcoin/libbitcoin-network/actions/runs/9195550780/job/25291624293?pr=406

This results in an invalid message deserialization since the reject message is not defined until protocol version 70002. BIP61 states:

The reject message is backwards-compatible; older peers that do not recognize the reject message will ignore it.

This is an incorrect assumption as peers of older versions could (and should) validate the protocol against invalid messages. Otherwise the peer is subject to DOS attack by ignoring all unknown messages (as opposed to dropping the connection).

[network]
# The services exposed by network connections, defaults to 1 (full node).
services = 1
# The advertised services that cause a peer to be dropped, defaults to 0 (none).
invalid_services = 0
...

Rationale: bitcoin/bitcoin#10982

At startup, following handshake completion, there is a race between the attachment of protocols and handling of messages. Messages are handled asynchronously by placement onto a queue, freeing up the reader. If protocols are not attached the messages are dropped due to lack of registered handlers. This can be problematic given that there are control messages that arrive immediately following the handshake.

The race is typically won by the registration and is therefore more prominent in a debugging environment, especially when breakpoints are set.

I'm attempting to build the latest version3 (commit #336d7c59be5a543a3ce7291ad1743f25032eeede) using the install script, invoked like so PARALLEL=12 ./install.sh --prefix=/home/$(whoami)/libbitcoin --build-boost --build-zmq

I get the following error:

Since the libbitcoin-network README does not mention the install script I tried the following

$ ./autogen.sh
$ ./configure
$ make

... and got the same error. Any ideas what my problem is?

On a more general note - is there a slack or a discord that would be more appropriate to post questions like this that are likely mistakes I'm making and not actual problems with the library? Thanks

libbitcoin/libbitcoin-system#1005

This allows crawlers like bitnodes to get version info and verify up time, and does not materially increase DOS risk or performance.

Hi all! I've made Homebrew formulae out of most of the libbitcoin repos, but there are still a few more to go, including this one. To get dependent repos to build (e.g. libbitcoin-node), I have to define libbitcoin-network as a "resource", which makes the build process a little bit more complicated. If I can define other Homebrew formulae as dependencies, it's easier.

In order to make a formula, Homebrew requires a repo to be "canonical," which means it needs either 20 watchers, 25 stars, or 20 forks. libbitcoin-network needs just one more fork! If any followers of this repo haven't forked it (or starred it), I would greatly appreciate it if you did! Or if you already have, please pass on the word!

Thanks in advance!

These are late-excluded due to error::address_in_use conflict, but should be excluded from entering pool in the first place.

unspecified applies to all interfaces. collapse duplicates in config. Update inbound session to manage an acceptor for each binding. Integrate enable_ipv6 in acceptor setup as applicable. expand inbound.self to a set as well, allowing the caller to advertise multiple addresses.

Hi! I'm proposing some changes to addr handling in Bitcoin Core, and trying to ensure there will not be negative consequences for other clients on the network. For more information about the changes, please see my mailing list post. The crux is that, if the changes are accepted, bitcoin core would stop sending addr messages to peers who don't "indicate interest" aka initiate an addr-related message (addr, addrv2, getaddr, or sendaddrv2).

I'd like to ensure that libbitcoin clients will initiate an addr related message to outbound peers. I've looked in the code and believe the software plays nice, and am looking for a +1 from someone more familiar with this project.

This is my understanding: in session_outbound.cpp, attach_protocols is called as part of the process of starting up a new outbound connection (link). This function invokes protocol_address_31402::start, which sends a getaddr message (link). And it seems this is also the case for manual connections (link).

I also found that the starting sequence of session_seed.cpp invokes protocol_seed_31402::start (link), which looks like it sends a getaddr and self advertises its own address (link).

Although my understanding is incomplete (does the node self announce to seeds, but not to normal outbound / manual connections?), if my claims above are accurate, there should be no compatibility issues with my proposed changes.

tldr; I'm proposing a change to Bitcoin Core and want to make sure it does not break libbitcoin clients, can someone confirm my understanding of the code?

Thanks in advance!
Amiti