Merge pull request #29 from marcofleon/main

cleaning up

TestGuides/27.0-Release-Candidate-Testing-Guide.md

@@ -1322,10 +1322,11 @@ There are a bunch of cases that we haven't tested above. Like mixing v3 with con
 
 Bitcoin Core 27.0 includes a new coin selection algorithm called CoinGrinder. The goal of this algorithm is to minimize the total weight of the inputs when constructing a transaction with change in a high feerate environment. Previously, there have been issues where [a ton of small inputs were used in a transaction even when there was a single UTXO that would have sufficed](https://bitcoin.stackexchange.com/questions/100437/bitcoin-cli-0-19-1-wallet-not-sending-from-addresses-with-closest-amount), resulting in an unnecessarily high transaction fee. Currently, CoinGrinder is only used when the feerate is greater than `3*long_term_feerate` (3 x 10 sats/vb by default).
 
-For this test, we will simulate the situation described in the link above, configuring a wallet to contain many small utxos and one larger utxo and then seeing whether input set weight is minimized when a transaction is contructed in a high fee environment.
+For this test, we will simulate the situation described in the link above, configuring a wallet to contain many small utxos and one larger utxo and then seeing whether input set weight is minimized when a transaction is constructed in a high fee environment.
 
-First, make sure the data directory used for regtest is empty. Then start your node.
+First, make sure your data directories are clean. Then start up a v27 node on regtest.
 ```bash
+echo "regtest=1" > $DATA_DIR_27/bitcoin.conf
 bitcoind-test -daemon
 ```
 Create two wallets. One will be used to receive block rewards and to fund the other one, which will be configured with a certain set of UTXOs (bunch of small, one big).
@@ -1369,7 +1370,7 @@ Use this command to confirm that there is an unspent transaction worth 0.5 tBTC
 bcli -rpcwallet=testwallet listunspent | jq '.[] | select(.amount == 0.5)'
 ```
 The output should look something like this:
-```bash
+```json
 {
  "txid": "2254455264eb3e6e02471594f4eebe9c140de9c09074e6a52485f4de4fa0936d",
  "vout": 1,
@@ -1397,7 +1398,7 @@ To check that only the 0.5 UTXO was used in the transaction, run
 bcli getrawtransaction 7bb3bfceadce62cbe5da379975bca01e26675e576883773333a2f1baaf0e3206 true
 ```
 using the hash you got from the test transaction. The output should look something like this:
-```bash
+```json
 {
  "txid": "7bb3bfceadce62cbe5da379975bca01e26675e576883773333a2f1baaf0e3206",
  "hash": "99dfd8043440914cdcf9d39dfd43309de692a2204dd1cf8f15afae5faebdf72d",
@@ -1452,6 +1453,17 @@ Notice in the `vin` section that there is only one input used and that the `txid
 
 If we were to run these same steps but set the test transaction fee rate to 30 sats/vb or less, we'd notice that a lot more inputs are selected from the test wallet to send 0.47 tBTC. The raw transaction will be a lot larger (therefore paying a lot higher of a transaction fee) than the one created above when CoinGrinder was activated in the high fee environment (>30 sats/vb).
 
+This test is by no means comprehensive, but it should provide a baseline for further testing on regtest with the CoinGrinder algorithm.
+
+Once finished with CoinGrinder testing, stop the node
+```bash
+bcli stop
+```
+and clean up the data directories.
+```bash
+datadir-cleanup
+```
+
 
 ## `migratewallet` RPC is no longer experimental