New answers tagged

2

As far as I'm aware, there are currently no formal proposals to introduce Full RBF. Therefore, I'm expecting that the default behavior of upcoming nodes will remain to forward and create transactions according to the rules specified in BIP125, Opt-in RBF.


1

BIP 341 answers this. It is generally important to be able to prove that the internal public key that you choose is a point with an unknown private key. Otherwise a malicious party could hide a key path spend in the P2TR address, pretend not to have the private key for that internal public key but actually possess it. BIP 341 also provides instructions on ...


1

You could always run make clean between builds but a lot of the time it won't be necessary and it is slower. Pieter Wuille usually doesn't run make clean and only runs it when the build fails. If it still fails after that he runs git clean -dfx. Warning: This deletes everything and resets your work directory to a fresh checkout. You'll need to autogen.sh ...


2

The Bitcoin Core test README states: By default, up to 4 tests will be run in parallel by test_runner. To specify how many jobs to run, append --jobs=n The individual tests and the test_runner harness have many command-line options. Run test/functional/test_runner.py -h to see them all. Pieter Wuille also explained how he gets the total time down below 4 ...


6

Many others have received/lost commit access. How exactly is this decision made? and by who? Nowadays the decision is generally made by the developers during one of the weekly IRC meetings. This is not done by committee nor a specific group, just whoever is attending the meeting when the topic is brought up. It's usually the same people at every meeting. ...


2

On that wiki link you posted it states: If any opcode marked as disabled is present in a script, it must abort and fail. An attempted UTXO spend with a failed script will not be relayed between nodes running Bitcoin Core (and other major implementations) and certainly won't be included in a mined block. The mainnet coinbase transaction you link to includes ...


2

The migration tool will go through all the keys in the legacy wallet and create descriptors for them. This requires considering everything that IsMine matches on. From the Bitcoin Core release notes: IsMine refers to the function used to determine whether a script belongs to the wallet. This is used to determine whether an output belongs to the wallet. ...


7

The introduction of descriptor wallets presents an opportunity to introduce a new database backend as descriptor wallets are backwards incompatible. The following is taken from Andrew Chow's blog post on what's coming to the Bitcoin Core wallet in 0.21. (There was also discussion on this GitHub Issue.) Why move from Berkeley DB? Not designed to be used as ...


3

What exactly is happening in src/validation.cpp and what is saved in mempool.dat, when is this data required, what happens if there is an issue saving or loading data from the file? The current mempool of a node is kept in RAM during node runtime. As node operators, miners, and users we want transactions that are in our mempool and our own priority for ...


6

I was asked by Hasan Hasan, a junior developer, which of the following three books I'd recommend. Personally I think all three books are fantastic (I would recommend them all) but they do approach the topic from very different angles. Mastering Bitcoin (2nd edition, Andreas Antonopoulos) was the first technical Bitcoin book to be published. The 2nd edition ...


0

I'm pretty sure that your node will never re-verify those transactions according to the Taproot rules unless it is forced to do a new initial block download (IBD) due to database corruption etc. It verified them at the time as valid spends according to anyone-can-spend rules and so there is no need to revisit them. (I will correct at a later date if this is ...


0

When the soft fork (e.g. Taproot) is activated (assuming it is at some stage) all nodes agree to only verify transactions according to Taproot rules from the point of Taproot activation onwards. No nodes will verify transactions pre-activation according to rules specified at activation. Hence the network will always agree that your transaction following the ...


0

Disclaimer: This is an educational exercise. This Python code is for testing and should not be used in production or with mainnet Bitcoin. A private key of 3 is absolutely insecure. There are two Python files in the BIPs repo reference.py and test_vectors.py which you can view by cloning the BIPs repo. git clone https://github.com/bitcoin/bips.git These two ...


1

By "linear, no-fork" blockchain does that mean throwing away orphan/stale blocks (blocks that were successfully mined but didn't make it into the blockchain due to competing mined blocks)? Yes. What use cases would make use of this linearize script? The script was used to construct the bootstrap.dat file that was previously used to quickly sync ...


2

These bip340_test_vectors are used in two places: the unit tests (src/test/key_tests.cpp) and the functional tests (test/functional/test_framework/key.py). The Python code for testing the bip340_test_vectors is here. There are 15 test cases in all but only 4 distinct secret keys, 7 distinct public keys (3 of them don't have secret keys) and 15 distinct ...


1

(A 2-of-2, 3-of-3, n-of-n will be referred to as a multisig scheme and a 1-of-2, 2-of-3, k-of-n where k < n will be referred to as a threshold scheme) The most significant incentives for using Taproot (in terms of reducing transaction fees) exist for those who are using either multisignature/threshold schemes (the larger the multisig the larger the ...


0

You could enable -fallbackfee (as darosior says) but the easiest or quickest way to resolve this is to set a fee. In this example we are setting a fee of 1 satoshis per byte. ./bitcoin-cli sendtoaddress "bc1q09vm5lfy0j5reeulh4x5752q25uqqvz34hufdl" 0.1 "" "" false true 1 sat/B If you do ./bitcoin-cli -regtest help sendtoaddress ...


1

You could enable -fallbackfee as it says in the error message but the easiest or quickest way to resolve this is to set a fee. In this example we are setting a fee of 1 satoshis per byte. ./bitcoin-cli sendtoaddress "bc1q09vm5lfy0j5reeulh4x5752q25uqqvz34hufdl" 0.1 "" "" false true 1 sat/B If you do ./bitcoin-cli -regtest help ...


0

BIP 341 (BIP-Taproot) discusses this example where you don't require the script path. If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path. The BIP also explains here the rationale for this. If the taproot output key is an aggregate of keys, there is the ...


0

The Bitcoin Core test documentation provides some guidance on attaching a debugger. The functional tests are in Python so you are correctly choosing pdb (rather than gdb, lldb etc) for the job. A python debugger can be attached to tests at any point. Just add the line: import pdb; pdb.set_trace() anywhere in the test. You will then be able to inspect ...


5

Previous Bitcoin Core PR review club sessions A good starting point is the various Bitcoin Core PR review club sessions that have been held thus far on specific commits of the Taproot PR. The latest one was on "Implement Taproot validation" (hosted by John Newbery) and there are various notes and a transcript of the meeting there. There are also ...


2

An uninitialized read is when a variable is created without an initial value and then the value of this variable is read. This should be avoided as the resulting behavior is unpredictable and could be different each time the program is run. According to cppreference.com: Normally uninitialized variables are a bad idea, and the only place where they are ...


Top 50 recent answers are included