|
|
@ -644,3 +644,16 @@ A few guidelines for introducing and reviewing new RPC interfaces: |
|
|
|
|
|
|
|
|
|
|
|
- *Rationale*: If a RPC response is not a JSON object then it is harder to avoid API breakage if |
|
|
|
- *Rationale*: If a RPC response is not a JSON object then it is harder to avoid API breakage if |
|
|
|
new data in the response is needed. |
|
|
|
new data in the response is needed. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Wallet RPCs call BlockUntilSyncedToCurrentChain to maintain consistency with |
|
|
|
|
|
|
|
`getblockchaininfo`'s state immediately prior to the call's execution. Wallet |
|
|
|
|
|
|
|
RPCs whose behavior does *not* depend on the current chainstate may omit this |
|
|
|
|
|
|
|
call. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *Rationale*: In previous versions of Bitcoin Core, the wallet was always |
|
|
|
|
|
|
|
in-sync with the chainstate (by virtue of them all being updated in the |
|
|
|
|
|
|
|
same cs_main lock). In order to maintain the behavior that wallet RPCs |
|
|
|
|
|
|
|
return results as of at least the highest best-known block an RPC |
|
|
|
|
|
|
|
client may be aware of prior to entering a wallet RPC call, we must block |
|
|
|
|
|
|
|
until the wallet is caught up to the chainstate as of the RPC call's entry. |
|
|
|
|
|
|
|
This also makes the API much easier for RPC clients to reason about. |
|
|
|