This issue is to discuss the 28.0 Release Candidate Testing Guide. If you have any feedback on the document, please leave a comment here.
Note: This is for feedback on the document, not on Bitcoin Core or on the 28.0 changes.
Thank you for taking a look at the guide and leaving your feedback.
How about adding an instruction for testing assumeutxo mainnet parameters? Unless I am misremembering I think we left assumeutxo out of the testing guide previously because it was not available on mainnet so it would be good to include it now. For some people it may be taking too long or be too resource intensive so I would suggest to put it at the end as a bonus or something like that.
Here is a high-level description of what I think of for a full assumeutxo test: #28553 (comment) Some of the late bug fixes/improvements could give additional hints for what testers could look out for in particular while going through the steps: https://github.com/bitcoin/bitcoin/issues/29616
How about adding an instruction for testing assumeutxo mainnet parameters?
Not related to the testing guide, but it could also be mentioned in the release notes that assumeutxo mainnet params are available now.
How about adding an instruction for testing assumeutxo mainnet parameters?
Not related to the testing guide, but it could also be mentioned in the release notes that assumeutxo mainnet params are available now.
I have added it to the release notes draft.
The guide is looking great!
I dry ran it through the 2. V3 Transactions TRUC section so far. Love how the guide explains the “why” and “what” is being done before steps are executed.
Some minor suggestions below:
1. Testnet4 Support2. V3 Transactions TRUC, uses regtest. Could add a statement telling the user to stop the nodes and something in the beginning of the next section to start for regtest.2. V3 Transactions TRUCIn i:
bitcoind28 -daemonwait -mempoolfullrbf=0 seems to have the user start on mainnet instead of regtest (later steps assume regtest). Would similarly need to add -regtest to each of the bcli28 commands.In ii:
listunspent in iii will have limited UTXOs to use.In iii:
getaddressinfo to provide the pubkey needed for the witness script of the transaction provided on CLI to sign txWithUncle
great job putting this guide together rkrux! found it easy to follow, thank you!
couple things about this section.
at the end of the section it says:
Execute the
gettransactionRPC for the new transaction and check themempoolconflictsfield - it contains the previous transaction!
but the new transaction will only have walletconflicts populated and not mempoolconflicts. its the old/original transaction that now has both walletconflicts and mempoolconflicts populated (and in fact in your example showing mempoolconflicts populated is actually using the old/original transaction). this is shown correctly in section 5 as well.
then it says:
List the unspent and note that the unspent that was used in the first transaction is available now.
however since the new transaction is spending the same unspent, this unspent should still not be available. this aligns with your example (and my testing), where created transactions are spending the unspent output with address bcrt1qwqpxdvp3utduz9zstqx4zca5wpkgzsprqplmhq and listunspent still doesn’t return an unspent output with that address in your guide.
mempoolfullrbf by defaultmight be good to mention stopping and restarting bitcoind28 without mempoolfullrbf=0 (since the last time bitcoind28 was started in the guide it had this flag).
Nice work @rkrux!
Counter intuitive behavior for the TRUC novice towards the end of V3 Transactions TRUC:
testmempoolaccept shows siblingTx2 as being in TRUC-violation and not allowed, but its child txWithUncle has no issues listed.submitpackage then accepts siblingTx2 but rejects txWithUncle. (Wouldn’t it be nice if submitpackage was atomic, all or nothing, instead of breaking the package apart? (I see it is consistent with the bitcoin-cli docs though)).Earlier in the instructions it says:
the
txWithUncleis not accepted because it is a third generation transaction violating the max size of 2 unconfirmed transactions rule of TRUC.
…and…
the
txWithUncleis not accepted in the mempool because it violates the TRUC rule of unconfirmed ancestor count.
…which seems inconsistent with the testmempoolaccept-output. Maybe comments could be added explaining the output?
Including the working directory is not necessary as the aliases operate on absolute paths. It also leaves land mines when copy-pasting from the guide:
➜ 27-test bcli27 getblockchaininfo -> bcli27 getblockchaininfo (or ➜ bcli27 getblockchaininfo), etc
rctesting bcli28 -> bcli28
test28rc bcli28 -> bcli28 (test28rc is named 28-rc-test at the beginning of the guide, assuming both are directory names).
Download less unnecessary data from GitHub for the test + move comment out of the code block and capitalize&punctuate?:
0cd $RC_TEST_DIR
1git clone https://github.com/bitcoin/bitcoin.git
2cd bitcoin
3git checkout tags/v27.0rc1
4(ensure source is present in RC_TEST_DIR/bitcoin in either instance (run mv if necessary))
->
0cd $RC_TEST_DIR
1git clone https://github.com/bitcoin/bitcoin.git -b v28.0rc1 --depth 1
2cd bitcoin
(Ensure source is present in RC_TEST_DIR/bitcoin in either instance (run mv if necessary)).
Create a new transaction without BIP125 signalling, -> Create a new transaction without BIP125 RBF signalling,
What is this sorcery? :)
Doesn’t make my browser (Firefox 115) scroll to a specific line, regardless of whether I make my window tiny or not.
Now that we have a V3 transaction in the mempool that has NOT signalled for RBF, lets create a new transaction that double spends this one by spending the same input used in the first transaction. -> Now that we have a V3 transaction in the mempool that has NOT signalled for RBF, lets create a new transaction that double spends this one by spending the same input used in the first transaction (same source & destination as before, just decreased value/increased fee).
This section could do with some more back-ticks around the names to make them stand out, alternatively remove them from the rest of the paragraph.
For testing this feature, we will create a parent transaction (parentTx) having 2 outputs and then subsequently create a child transaction (siblingTx1) spending the first output of the parent transaction. We will then send both these transactions and they should be accepted in the mempool. Later we will create another child transaction (siblingTx2) of the parent transaction by spending its second output but with higher fees, this would become a sibling of the first child transaction. Also, we will create a child transaction (txWithUncle) of this new child transaction and then submit both the (siblingTx2 and txWithUncle) together. Expectation is that
0flowchart TB
1 subgraph phase 1
2 parentTx--->siblingTx1
3 end
4
5 subgraph phase 2
6 parentTx--->siblingTx2
7 siblingTx2-.->txWithUncle
8 end
Reference: http://mermaid.js.org/syntax/flowchart.html#subgraphs
Source minus the mermaid at the very beginning:
0flowchart TB
1 subgraph phase 1
2 parentTx--->siblingTx1
3 end
4
5 subgraph phase 2
6 parentTx--->siblingTx2
7 siblingTx2-.->txWithUncle
8 end
List the unspent and pick any one of them. We will pick one with 50 coins.
->
List the unspent and pick any one of them. We will pick one with 50 coins (you might need to call bcli28 -rpcwallet=test -generate 1 to make more coinbase transactions spendable).
I didn’t read what what came after
Create the txWithUncle now that spends the output of the siblingTx2, edit it, and sign it.
So I when signrawtransactionwithwallet without the extra parameters refused to work I went back and redid it again before reading what was written afterwards. Maybe add some emphasis formatting?
Note that while signing this transaction we must pass few details of the previous transaction it is spending because… -> Note that while signing this transaction we must pass few details of the previous transaction it is spending because…
Could also mention bcli28 getnewaddress for the destination here in the beginning around:
Pick any one unspent and spend it in a new transaction
The first decoderawtransaction output is not properly formatted. (Triple-back-ticks too close to HTML element?).
Milestone
28.0