Added fetch-chainparams.py to fetch chainparam block values from a node using HTTP RPC
AbandonedPublic
Actions

Authored by jasonbcox on Jun 27 2019, 20:01.

Details

Reviewers

deadalnix

Group Reviewers

Restricted Project

Summary

First step towards automating releases (T663). This eliminates manually fetching chainparams from a node. This diff is based on D3193, but distills fetch-chainparams down to a single task (DOTADIW, see https://en.wikipedia.org/wiki/Unix_philosophy).

Prerequisite: You must have bitcoind running with --rest=1 set either as a CLI arg or in the config.
In the near future, we will have a dedicated node that can have these requests directed to (at that point,
the hostaddr default will change from localhost to that dedicated node).

Typical usage during a release is to fetch mainnet params (fetch-chainparams.py with no args set).
Occassionally, testnet params need to be fetched as well, and may be done with fetch-chainparams.py -t.
Both of these uses assume default node settings regarding rpcport, rpcusername, rpcpassword, etc.

fetch-chainparams.py returns JSON-formatted blockhash and chainwork in stdout. In the near future, it may be piped
to other scripts that enable automatic updating of the chainparams, smoke testing, etc.

Test Plan

# Shows help message
fetch-chainparams.py -h

# Test that the script can run from locations other than contrib/devtools
# from toplevel
contrib/devtools/fetch-chainparams.py

# Mainnet Tests
# ----------------
bitcoind --rest=1

# Default works as expected (mainnet chainparams replaced with best tip)
fetch-chainparams.py

# Trying testnet without the correct hostport gives an error
fetch-chainparams.py -t
fetch-chainparams.py -t -p 18332

# Specifying a blockhash replaces chainparams with that block and it's chainwork instead
fetch-chainparams.py -b <someblockhash>

# Testnet Tests
# ---------------
bitcoind --rest=1 --testnet

# Default throws an error because it expects mainnet
fetch-chainparams.py

# Testnet works as expected (testnet chainparams replaced with best tip)    
fetch-chainparams.py -t

# Specifying a blockhash replaces testnet chainparams with that block and it's chainwork instead
fetch-chainparams.py -t -b <someblockhash>

# Specifying an invalid blockhash errors as expected
fetch-chainparams.py -t -b 123

# Specifying a valid blockhash that doesn't exist errors as expected
fetch-chainparams.py -t -b <a valid but non-existent block hash>

fetch-chainparams-test.py
ninja check-devtools
ninja check-all

Diff Detail

Repository

rABC Bitcoin ABC

Branch

fetchchainparams

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 6515
Build 11077: Bitcoin ABC Buildbot (legacy)
Build 11076: arc lint + arc unit

Event Timeline

jasonbcox created this revision.Jun 27 2019, 20:01

Herald added a reviewer: deadalnix. · View Herald TranscriptJun 27 2019, 20:01

Build Bitcoin-ABC / Diffs / Bitcoin-ABC Diff Testing started.

Build Bitcoin-ABC / Diffs / Bitcoin-ABC Diff Testing passed.

Harbormaster completed remote builds in B6515: Diff 9728.Jun 27 2019, 20:08

bitcoin-cli clearly doesn't need the node to be started with custom parameters. So why is it required here?

contrib/devtools/fetch-chainparams.py
72	Generating a JSON is not useful. The RPC already provide all of this in JSON form, so this does exactly nothing useful. Simply shuffle around JSON fields.

The description of the diff has now gone completely off rail. It start by discussing philosophy and then goes on to explain what not to do. That's a good sign that you are not focused on what you should be doing but on abstract matter that do not matter. Case in point the script red a json and output a json with the same infos in it, but in a very complex and highly specialized manner - which goes completely against the UNIX philosophy, BTW. Either you want to do a tool that fetch things from the RPC and output them in JSON (hint, that's bitcoin-cli) or you do something that extract the relevant infos and put them in a form that's usable. You can even drop the pretense of being a UNIX philosopher and do a script that does both at once.

To quote from the grymoire:

Anyhow, sed is a marvelous utility. Unfortunately, most people never learn its real power. The language is very simple, but the documentation is terrible. The Solaris on-line manual pages for sed are five pages long, and two of those pages describe the 34 different errors you can get. A program that spends as much space documenting the errors as it does documenting the language has a serious learning curve.

That sounds like that diff description.

This revision now requires changes to proceed.Jun 30 2019, 00:36

jasonbcox abandoned this revision.Jul 10 2019, 18:38