PSBT signing was changed to use SIGHASH_DEFAULT by default in #22514.
The signet miner script sets the sighash type of the created PSBT to
SIGHASH_ALL, hence this leads to a sighash mismatch when the
`walletprocesspsbt` RPC is called. Fix this by explicitly passing the
correct sighash type.
Note that the same change was needed in one of our functional tests,
see commit d3992669df.
Reported by gruve-p.
As the faucet will always ask for a captcha now, the current script is
no longer usable.
Change the script to print the captcha in dot-matrix to the terminal,
using unicode Braille characters.
42dbd9025a contrib: return non-zero status if getcoins.py errors (Sebastian Falbesoner)
8c203cf0e1 contrib: catch bitcoin-cli RPC call errors in getcoins.py (Sebastian Falbesoner)
0eca5ebace contrib: refactor: introduce bitcoin-cli RPC call helper in getcoins.py (Sebastian Falbesoner)
Pull request description:
This PR is based on #22565 ("[script] signet's getcoins.py improvements"), which should be reviewed first.
The signet faucet script `contrib/signet/getcoins.py` currently issues bitcoin-cli RPC calls without catching errors -- the only case tackled is if there is no `bitcoin-cli` file found. Instead of crashing with a stack-trace on a failed RPC call, the changes in this PR aim to produce a more user-friendly output (see also https://github.com/bitcoin/bitcoin/pull/22565#discussion_r683754875). Additionally, in case of any error, a non-zero status is now returned (instead of 0, indicating success), which could be useful for other scripts taking use of signet faucet script.
The most straight-forward way to test this is invoking the script without a `bitcoind` running on signet:
PR22565 branch:
```
$ ./contrib/signet/getcoins.py
error: Could not connect to the server 127.0.0.1:8332
Make sure the bitcoind server is running and that you are connecting to the correct RPC port.
Traceback (most recent call last):
File "./contrib/signet/getcoins.py", line 26, in <module>
curr_signet_hash = subprocess.check_output([args.cmd] + args.bitcoin_cli_args + ['getblockhash', '1']).strip().decode()
File "/usr/local/lib/python3.8/subprocess.py", line 415, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "/usr/local/lib/python3.8/subprocess.py", line 516, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['bitcoin-cli', 'getblockhash', '1']' returned non-zero exit status 1.
```
this PR branch:
```
$ ./contrib/signet/getcoins.py
error: Could not connect to the server 127.0.0.1:38332
Make sure the bitcoind server is running and that you are connecting to the correct RPC port.
-----
Error while calling "bitcoin-cli -signet getblockhash 1" (see output above).
```
ACKs for top commit:
kallewoof:
Code ACK 42dbd9025a
Zero-1729:
tACK 42dbd90🧪
Tree-SHA512: 912240a4ed03c87035e370602f4095c7ffe26806421bbbd6cf86588126f2310a01a6a61606e9e2918fb2c1a0debdd0ce768c69ba2e4b8e7750fa3474a56d01a0
b0c8246cac Add cleaner errors for unsuccessful faucet transactions (NikhilBartwal)
1c612b274b [script] Update signet getcoins.py for custom network (NikhilBartwal)
Pull request description:
Currently, using the getcoins.py with a custom signet executes successfully and shows the transfer of 0.001 testBTC as complete, however for obvious reasons, it should not. In fact, upon verification it does not actually execute the transaction, but rather gives the output that it did, as shown below which can be misleading:
```
[nikhilb@nikhil-PC bitcoin]$ echo $datadir
/home/nikhilb/signet-custom
[nikhilb@nikhil-PC bitcoin]$ contrib/signet/getcoins.py -- -datadir=$datadir
Payment of 0.00100000 BTC sent with txid dd22c7d996e95f3e5baf20f73140d517ff48f1b26d0e4fefd61e3c37991b8f86
[nikhilb@nikhil-PC bitcoin]$ bitcoin-cli -datadir=$datadir getrawtransaction dd22c7d996e95f3e5baf20f73140d517ff48f1b26d0e4fefd61e3c37991b8f86
error code: -5
error message:
No such mempool or blockchain transaction. Use gettransaction for wallet transactions.
[nikhilb@nikhil-PC bitcoin]$ bitcoin-cli -datadir=$datadir gettransaction dd22c7d996e95f3e5baf20f73140d517ff48f1b26d0e4fefd61e3c37991b8f86
error code: -5
error message:
Invalid or non-wallet transaction id
```
This PR adds a sanity check for custom signet by comparing the current network's first block hash (the block after the genesis block) with global signet's respective block hash (since all signet networks share the same genesis block) and if a custom network is detected, the user is prompted to either work on the global signet or setup their own faucet.
The PR was checked to be working successfully, giving the output as below:
```
[nikhilb@nikhil-PC bitcoin]$ git checkout update_signet_getcoins
Switched to branch 'update_signet_getcoins'
Your branch is ahead of 'upstream/master' by 1 commit.
(use "git push" to publish your local commits)
[nikhilb@nikhil-PC bitcoin]$ contrib/signet/getcoins.py -- -datadir=$datadir
The global faucet cannot be used with a custom Signet network. Please use the global signet or setup your custom faucet for the same.
You can have a look here for setting up your own faucet: https://en.bitcoin.it/wiki/Signet
```
ACKs for top commit:
prayank23:
utACK b0c8246cac
kallewoof:
ACK b0c8246cac
arnabsen1729:
utACK b0c8246
prakash1512:
utACK b0c8246
0xB10C:
Tested ACK b0c8246cac
theStack:
Tested ACK b0c8246cac
Zero-1729:
crACK b0c8246🧉
Tree-SHA512: 144b47a83008521a5cda13f4c1b12809a125a744f865a8e0f792132d52fdb88926d4f4f4d7230452c2e129b5879892cdbeda981b8af10b789e9fc0cda2905a5d
Currently, using the getcoins.py with a custom signet executes successfully and shows the transaction as complete, however for obvious reasons, it should not.
This PR adds a sanity check for custom signet by comparing the current network's first block hash with global signet's respective hash.
When mining the first block of a new signet chain, pick a timestamp for
the first block so that after mining 100 blocks the timestamp will be
back to the current time -- this prevents an unnecessary delay before
any miner rewards have matured enough to be spent. This takes into
account that the delta between blocks may be shorter than 10 minutes due
to attempting to increase the difficulty to match --nbits, but does not
take into account the time spent actually generating the 100 blocks.
