#16083 has been abandoned, so it would be a good first issue to take the branch (bitcoin/bitcoin#16083 (comment)) and submit it as a new pull request.

Useful skills:

Understanding of undo data, the RPC interface and the functional tests.

Want to work on this issue?

The purpose of the good first issue label is to highlight which issues ar

While ccxt does a great job unifying most functions / settings, not everything is or can be unified.
I think it would be good to provide a separate wiki/documentation page which documents exchange-specific properties.

The behavior is there now and all is working well - but to find it users need to search through issues (which are not easy to navigate) to find certain exchange-specifics - and o

To be done on lbrytech repo probably.
The wallet is currently configured as defined originally in ElectrumX, there are some docs for it already in there.

Keep in mind that we added new configuration keys and should clean up the unused ones at some point, so we need something easy

When given a wrong argument, some daemon commands fail with "unknown command" error, instead of a meaningful error message.

Examples of useless error messages:

hard_fork_info abc
unknown command: hard_fork_info abc
Monero 'Carbon Chamaeleon' (v0.15.0.0-57854a3e2)
Commands:
  ...

in_peers abcd
unknown command: in_peers abcd
Monero 'Carbon Chamaeleon' (v0.15.0.0-57854a3e2)
Comm

The blockchain v2 reactor utilizes concurrency to saturate the bottleneck of writing blocks to disk. This concurrency is internal to the reactor where the reactor itself will launch and manage internal state machines running as go-routines. This configuration makes testing difficult as we don't know when messages processed by internal state machines will be processed and when we can assert that th

Step 1: Have you search for this issue before posting it?

yes

If you have discovered a bug in the bot, please search our issue tracker.
If it hasn't been reported, please create a new issue.

Step 2: Describe your environment

• platform: Docker - latest build(Digest:sha256:3e8fe20bf6aaad9095e1ba0924ce2af3368cc55d1fe41ee

In order to better propagate only live blocks to peers, we need to be able to classify blocks as either "new"/"active" or "existing" from the perspective of the network, but from our node.

One way we could accomplish this is to have representatives periodically emit a signed message that gives a fuzzy view into their complete ledger.

One way to construct this fuzzy view is to XOR the hash of