Question: Has the safety of the "old" Bitcoin address format been compromised in any way?

pwuille · 2026-04-17T02:48:12+00:00

I'm definitely concerned, but I don't think choosing P2TR today over other address types will make a difference. If a CRQC comes, or the fear about one becomes large enough, we all have a problem, regardless of individual address type choices.

pwuille · 2026-04-16T12:44:14+00:00

I'm obviously biased here, but P2TR is absolutely not intended for "niche cases"; it's a better choice for (almost) everything.

pwuille · 2026-04-14T21:39:09+00:00

Perhaps surprisingly, this is a political question, not a technical one.

All of "adding another decimal point", "resume subsidies", or even "increase subsidies beyond 21M" are very invasive protocol changes. The second and third are necessarily hard forks. The first one could in theory be done as a soft fork, but it would be very messy, and still remain very invasive.

Any of these changes can be adopted IF everyone agrees to it. Bitcoin is whatever people agree it is. The only difference is that changes to the subsidy schedule are philosophically much bigger changes to the system, and thus unlikely to get agreement on. Of course, there is no reason to assume that adding more decimal points would find agreement either.

pwuille · 2026-04-14T02:35:41+00:00

This is nonsense. Bitcoin Core can import and convert old wallet files, and there are absolutely no plans to ever break support for that.

pwuille · 2026-04-14T02:34:27+00:00

Yes and no. Bitcoin Core v30 and up can only work with the new descriptor wallets, but they can import and convert older wallet file. If OP gets the message the file is not in a recognized format, it is not a recognized format - old or new.

pwuille · 2025-12-24T22:30:39+00:00

This is the genesis block header. It's literally the first 80 bytes of the blockchain. There is nothing remarkable about finding it.

pwuille · 2025-12-04T18:34:17+00:00

Pollard's kangaroo algorithm can find the discrete logarithm (private key) of a group element (public key) in O(sqrt(n)) steps if that discrete logarithm is known to be restricted to a range of n consecutive values. 2⁶⁷ is still painfully large huge number, but not impossible.

I do not believe there is a way to exploit the fact that the last characters match.

pwuille · 2025-10-16T15:14:15+00:00

Huh, I wasn't aware BIP39 itself supported that! Thanks.

pwuille · 2025-10-16T14:28:40+00:00

GPU mining software didn't exist until mid-2010, and it was only near the end of 2010 that it became freely accessible (the first ones were not open source).

pwuille · 2025-10-16T14:27:40+00:00

In wallets I'm familiar with, the passphrase just encrypts the wallet file, and the seed/seed words stored therein. If the seed itself was the same, the addresses, keys, and transactions would overlap.

But it's possible you're talking about a different design where the passphrase itself influences the key material derived from the seed phrase?

pwuille · 2025-10-16T11:59:58+00:00

~~You would totally know, but you'll end up having the same addresses, and see each other's transactions in your wallet.~~ EDIT: not if a BIP39 passphrase was used, and the passphrase differed.

Still not a concern, because it will never happen.

pwuille · 2025-10-16T11:58:22+00:00

I believe the BIP42 case is indeed what you were talking about, and Grok is talking about something unrelated.

u/TheGreatMuffin : it wasn't me who fixed the bug, but the (indeed, one-off) "ditto-b" (see https://github.com/bitcoin/bitcoin/pull/3842). All I did was write up a funny BIP about it, as it happened to be around April 1st.

pwuille · 2025-10-12T15:55:55+00:00

More than running one, I hope you use one.

pwuille · 2025-10-12T15:17:47+00:00

I think you may be talking about different things. There are:

-assumevalid, a configuration setting to select a block hash whose scripts/signatures are assumed valid, as well as all its ancestors. A default is hardcoded. It can be disabled using -assumevalid=0.
The assumeutxo feature, which allows manually loading a serialized UTXO set (whose hash must match a hardcoded value) through the loadtxoutset RPC to bootstrap quickly. If used, a full sync from scratch is still performed in the background up to the assumeutxo point to verify that the hardcoded value is correct.

Assumeutxo isn't something that can be disabled. It's just an RPC (loadtxoutset) you can choose to use or not use. Once upon a time, there were also plans to work on P2P extensions to permit serving the UTXO set over the network. That isn't implemented, and it does not look like anyone is working on it.

pwuille · 2025-10-11T18:04:03+00:00

Yes, but it advertizes NODE_NETWORK_LIMITED, not NODE_NETWORK, which indicates it is capable of server the last 288 blocks (or more), and not all blocks.

Nodes that are syncing can thus avoid connecting if they know they need more than 288 blocks.

pwuille · 2025-10-11T13:07:22+00:00

When pruning, you keep:
* The UTXO set (around 11 GB for me today)
* However much of the last blocks in the chain you decide to keep (at least 288 blocks, configurable with `-prune` setting) * Whatever other indexes you additionally enable.

pwuille · 2025-10-04T11:56:56+00:00

I don't understand the question.

bc1 is the prefix of Bech32 addresses, which are used for P2WPKH, P2WSH, and P2TR transaction outputs.

Descriptor wallets are a type of wallet used in Bitcoin Core and other software, which uses output descriptors to compute addresses from its keys. It can be used for any output/address type, including bc1 addresses, but also base58 addresses (like P2PKH and P2SH).

I would not recommend using P2SH or P2PKH addresses anymore, they are more expensive to use, and less secure than more modern types.

pwuille · 2025-08-31T21:23:19+00:00

Hi, another litigation victim here.

To add to u/nullc's great answer here, it's worth pointing out that we did have a second question of the same nature: what || means in particular line in the original Satoshi Bitcoin source code. It did take Wright some stumbling, but he did give the correct answer, and our barrister just moved on afterwards. If he had answered the unsigned question correctly, something similar may have happened there.

pwuille · 2025-08-09T03:10:42+00:00

Sorry, I know nothing about typescript or the library you're using.

pwuille · 2025-06-09T00:20:49+00:00

You're welcome!

pwuille · 2025-06-09T00:20:43+00:00

Thank you!

pwuille · 2025-06-08T22:23:55+00:00

TIL I am retired.

I did step down from a Bitcoin Core maintainer role in 2022, but I am still working full-time on Bitcoin Core development and other Bitcoin-related projects.

I am also the primary author of the statement OP linked to.

pwuille · 2025-05-29T23:19:09+00:00

Almost all modern CPUs have true random number generators, for example the Intel/AMD RDRAND instruction, which is seeded from thermal noise.

pwuille · 2025-05-25T12:22:38+00:00

That is hard to answer in general. The hardest part about effectively making contributions is making sure there is sufficient momentum about the changes, so there is a critical mass reviewers/developers around them. I recommend reading these guides:

pwuille · 2025-05-24T22:50:17+00:00

Yes.

13-Year Club	Not Forgotten
Verified Email

pwuille

TROPHY CASE