Regarding that Bitcoin Core switched to bech32 as the default format for addresses recently (with release 0.19.0.1), this should also be reflected in the RPC help texts. The change was already done for the RPCs getaddressinfo (commit bitcoin/bitcoin@2ee0cb3 by jonatack, PR bitcoin/bitcoin#17283) and `validateaddre

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

see: dvf/blockchain#50

The underlying exploit to tamper with a blockchain is described there

props to: @TimelessP

The fix should be fairly simple:
affected file: blockchain/blockchain.py

https://github.com/dvf/blockchain/blob/4010cf3273e19146a9cd7b37cf355cb751ffef88/blockchain.py#L82

A noted, currently it reads:

if length > max_length and self.valid

Clients that are built around the API need some additional information to work effectively. This is the following:

1. Peer list API: show more information about connected peers including the block height / cumulative difficulty of the peer. Basically, so the API provides at least as much information as the server TUI does.

2. Status information: Similarly, the minimum amount of info the stat

As is, it is challenging to account for push amounts in LND. This money should be accounted for in some way.

Changes required:

• Persist push amount on open channel
• Expose push amounts on ListChannels

Related to #4019

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

Actual docs (https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_transfer_by_txid) tells us what get_transfer_by_txid return only transfer object, and did not mention what it return a transfers array too.

example (testnet):

• `curl -X POST http://localhost:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_transfer_by_txid","params":{"txid":"a5447204b

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

I would love to add some new exchanges in there for you (and me) and would be happy to do so with just a little guidance as to which objects you're using for it without me doing a full code dig.

Assuming this is easily extensible. If not, I guess that would be my feature request... lol. Extensible exchange objects with documentation.

For a university school project I will be making some edits to your documentation which will aim to make writing more technical

Please add edits if you would like :)

There are lots of configurable settings in the config.json file.

https://github.com/xmrig/xmrig/blob/master/src/config.json

Where can I find detailed documentation on what the settings do?

Bug Report

Problem

The amount is the first field in a transaction. When you fill this out, and then add recipient by scanning their QR code, the amount is reset.

Expected behavior

Amount is maintained unless user cancels the Tx.

Actual behavior

Set Tx amount.
Scan recipient QR code.
Amount is cleared and must be re-entered.

Is there a way to cancel an order before the unfilledtimeout expires, in a way that the local sqlite database remains consistent with the exchage?
Please note that the RPC command /forcesell or /forcebuy do not help with this. In the case of a SELL, one would like to cancel the SELL order in Order Book before the sale is actually executed. It seems a bit different from forcing a SELL with the RPC

A user asked me on slack if estimatefee returns BTC per Byte or BTC per Kilobyte... honestly I don't know and it's a bit hard to tell. I compared mainnet full nodes bcoin vs Bitcoin Core and observed a wild divergence (outputs below).

From Bitcoin Core help:

Estimates the approximate fee per kilobyte needed for a transaction to begin
confirmation within conf_target blocks if possible

It look like some currencies have more precision in the mouseover display on the plot than others. For example, EOS shows many digits past the decimal while ETH only shows two. Adding a few more digits would make interpreting the charts much easier. The left plot shows the rounding I'm describing and the right shows the higher precision that EOS displays.

![rounding](https://user-images.githubu

Hi,

I the documentation here it says: "Support for accessing multiple exchanges per algorithm, which opens the door to cross-exchange arbitrage opportunities."

Does catalyst really support multiple exchanges using the same algorithm? If so - how this can be done? (no documentation for it)

Thanks!

Client.get_historical_klines returns a list of 12 elements,. What do all of them represent and where is this documented?

Documentation only mentions the 5 OHLCV values, unless I am missing something.