There is a separate topic about only that: https://bitcointalk.org/index.php?topic=5552091

In short: peg-ins and peg-outs are visible on Bitcoin, everything else happens on a sidechain.

Bitcoin miners only validate Proof of Work, exactly as in BIP-300 and BIP-301. Everything else is checked only by a given sidechain.

If you imagine having only block headers on Bitcoin, and everything else on a sidechain, then you should get the idea. Publishing a puzzle is like sharing a block header. The whole sidechain content is on a different layer, and it is not visible on Bitcoin. And because for BIP-300 and BIP-301, one sidechain peg is supposed to happen every three months, it would mean just one Bitcoin transaction with a solution to some puzzle, broadcasted once per 13150 blocks.

Exactly. Proof of Work, and other simple things like multisig or timelock, can be done on Bitcoin. But everything else is enforced only by a given sidechain.

Back to the topic: In general, if someone wants to decentralize mining, then quite often, a second layer is needed. Because otherwise, every time, when a given miner would receive a bunch of satoshis, it would be expensive to handle all of that on-chain, atomically, for every share, for every user. Such miners would pay more transaction fees, than they would earn from mining.

Exactly as planned and predicted by Satoshi:

Which means, that even if it will be technically possible to mine at home, and earn a few satoshis from doing that, then still: it won't be profitable. Buying the same amount will be cheaper for a typical user, than mining that amount.

Also, if you want to lock coins on Proof of Work alone, then you actually can. For example: https://bitcointalk.org/index.php?topic=5551080.0

Which means, that you can increase the reward by attaching more coins for example to bc1qn9vp8l5rs7huyl237s4q9lhrzcs0mzaajt528ysq3wgnzvlkay5sdfz6am, and then, any miner, who will check around 2^64 double SHA-256 hashes, would be able to move these coins anywhere. And guess what: it is currently more profitable to try mining the next block, than try to claim 53,000 satoshis from such address, if you calculate the needed hashrate per satoshi. Maybe if that reward will be bumped, without making the challenge harder, then some miner may try to collect it, while also confirming your transaction.

So, technically, as a user, you can always lock your coins on such scripts, and then, making a double-spend will be as hard, as re-mining the puzzle for a given address. Then, if you create any standard transaction, and one of your outputs will be used as a CPFP, along with the puzzle, then some miner may solve the puzzle, while also confirming your transaction. This is how sidechains can be built in a trustless way today, without BIP-300 or BIP-301 on Bitcoin. Then, they don't use Merged Mining, but they can use Proof of Work from the puzzle, and they can use real BTCs, without creating new altcoins out of thin air.

Which means, that if you want a decentralized solution, then I just described it, and you can use it, if you want. But in practice, for years, people did it differently: they just released altcoins, which were easier to mine, and then they simply sold them for BTCs. This is probably the fastest way to "mine" some satoshis, if you need to get them in that way: by mining some altcoins, and simply selling them. My idea doesn't change that model that much, it only makes it possible to do on real BTCs instead. And putting real satoshis into such puzzles is not that much different, than buying altcoins. Because for you, to sell a given altcoin for BTCs, some other user have to put some BTCs into it, to make ends meet, and form a transaction between a buyer, and a seller.

I think I can see the problem: if a public key starts from 02 or 03, then it is just a multisig. But if it starts from anything else than that, and there is some 32-byte value, then it is non-standard, and you won't get it mined, without some support from the miners.

For example: this is non-standard:
And if you flip a single byte, then it is multisig:
See the difference? When Bitcoin Core will tell you "nonstandard", instead of "multisig", then it means you won't get that kind of multisig, without the help from some miners. Which also means, that mempool.space marks it differently than Bitcoin Core, and shows MULTISIG in cases, where maybe it shouldn't.

There are two different things: elliptic curves like secp256k1, and hash functions like SHA-256. If you break only elliptic curves, then the network can move to a different algorithm, while still using SHA-256 as usual. However, if you break SHA-256, then you can break everything, including mining, and then, it is a completely different situation. Breaking SHA-256 will also break secp256k1, if you would be able to generate any preimages, because then, you could start from any known public key, generate (r,s,z) values randomly, which would match it, and then generate a transaction, which would hash into that random z-value.

Also, even finding collisions for SHA-256 would be harmful, because then, you could create colliding merkle tree branches, where one transaction would send coins from Alice to Bob, and another transaction would do that from Alice to Charlie, and both would hash to the same value, which would hash to the same merkle root.

When you create a private or public key from the seed, then hashing is used in-between, specifically for example HMAC-SHA512 from BIP-32, where SHA-512 is used.

Yes. And it has a drawback, that should be clearly stated: if a given key is not coming from any HD wallet, but is just generated randomly, for example by OpenSSL, like it was done in early days. In these cases, if committing to the seed would be always required, then these coins would be as hard to access, as coins from "bitcoin eater": because it would then require finding a seed, where none is known. Which is why that kind of solutions are technically possible, but it is hard to reach consensus, if there is a risk of blocking someone's coins, if that person didn't use any seed at all.

It is relevant, because the attacker would be able to break only ECDSA, but not the quantum part, which could require for example knowing the seed.

Of course. But the attacker still wouldn't know the seed. And if it will be required in that "quantum part", then only the real owner would be able to make it.

Think about it for a moment: if the real owner knows the seed, and the attacker cannot get it, without breaking hash functions behind it (which is different case than breaking elliptic curves), then it can be used to check, if a given signature is made by the attacker, or by the real owner.

No, because if committing to the seed will be part of the "quantum path", then only the real owner would be able to do that.

In general, the main downside of using that approach, is that not all public keys are derived from seeds, some of them are just randomly generated, if some user is not using any kind of HD wallet. If not that, then it would be much easier to reach consensus here, and simply require committing to the seed for all old addresses. But because there are non-HD keys in use, that approach would make them unspendable (or rather: as hard to spend as "bitcoin eater", and similar addresses: it would simply require breaking the cryptography behind converting seeds to keys).

By default, they accept the new block as valid, and reject all conflicting transactions, which they had in their mempools. Note that the coinbase transaction is also never in the public mempool, but it is normally accepted as valid.

Of course, some miners can try to reject a given block, but then, they usually need two blocks to do that. Because blocks are accepted, based on first-seen rule: if you produce a different block on the same height, then you need a second block on top of it, to trigger chain reorganization.

And also, sometimes two blocks can be broadcasted at almost the same time (and they can contain different transactions), and then, the next block will show everyone, which chain is the correct one.

Of course. For example: https://mempool.space/testnet/tx/2703e6d0215261d4916e0436438a366f4198fe473ff856036e01306ddce20315

This miner included his zero fee transaction first, before other transactions.

No. Each node has its own mempool.

Of course.

By default, it is dropped after two weeks. However, any node can decide to store it forever, and broadcast it later.

It means that a given node can refuse to drop it for whatever reason (for example because of using the old software).

If you use the latest version, then transactions with lower fees can be replaced by bigger fees. Which makes it possible to "unstuck" it.

Only by those, who upgraded their code.

Yes.

Of course.

Nothing, because after reaching a single confirmation, everyone will know, which version was placed in a block. And all new blocks on top of it simply couldn't include a second version, without invalidating that block.

This is the whole reason, why miners are needed in general. Because Alice could create two transactions: one sending coins to Bob, and one sending coins to Charlie. She could broadcast different transactions to different nodes. And then, whatever miners include first, will be enforced in practice.

Only if transactions are independent. If you have Alice to Bob transaction, and Bob to Charlie transaction, using Bob's coins, received from the previous transaction, then they have to happen in order. But if they are completely disconnected, then miners can swap them as they wish.

Of course. You can send a transaction only to a given miner, and nowhere else. If that miner will include it directly into the block, then the rest of the network will get it, only when that block will be mined. This is how people get non-standard transactions confirmed, or solve transaction puzzles, where revealing the public key would allow moving the coins by someone else (because of weak N-bit private key).

Yes. They just create a template, where they pick some transactions, and then they constantly replace some transactions with others, to get more fees out of it. But in general, mining is NP-hard, and they solve the knapsack problem here.

It was the case in the older versions: https://en.bitcoin.it/wiki/Miner_fees#Priority_transactions

Now, it is counted in satoshis per virtual kilobyte.

It could crack the private keys, but not the seeds.

No, these limits are handled independently: https://github.com/bitcoin/bitcoin/pull/33106

Which means, that if a lot of miners will start confirming transactions, where single satoshis would be used in outputs, then it could be lowered in the future. But now, it is not the case yet.

Also, if not miners, then we would still use 1 sat/vB, but some of them started confirming transactions with lower fees, so Bitcoin Core decreased it into 0.1 sat/vB, to improve block propagation.

Of course. Because if something is generated by AI, but contains some good points, then I think it should be merited. AI usage is not strictly banned, the only missing thing may be related to explicitly telling people, that what they see, is artificially generated.

Rather it is about testing the limits: first, we will have 1:1 copy-pasted replies from AIs. But sooner or later, some smarter users will try to mix their own words with AI-generated things. And then, it will be harder and harder to see the difference. Which means, that it is rather about checking, what will be accepted, and what will be detected, and blocked.

It is simply a cat-and-mouse game: if the most primitive usage of AI will be blocked, then we will have more advanced cases, where to tell a difference, you will have to do something more, than just passing the content through some detectors: you would need to find patterns, which are human-specific, and can be seen, if you technically know, which answer is correct, and which is just a hallucination. And that kind of things are beyond what automated tools can "understand".

For me, it was clear since I received the first replies from him in September 2025. But I wondered, how much time it would take for others to figure it out.

Because that's exactly how AI works in practice. It can produce things, which are 90% correct, or 95% correct, and the devil is in the details. Now, even some Bitcoin Mailing List users use AI summarizers, to write their replies, and some of them are even accepted by moderators.

And sometimes, after reading some replies, I know a given person used AI, if for example there are copy-pasted hallucinations from pages like that: https://tldr.bitcoinsearch.xyz/

For example: https://tldr.bitcoinsearch.xyz/summary/bitcoin-dev/March_2026/combined_-BIP-proposal-Pay-to-Schnorr-Key-Hash-P2SKH-

I didn't introduce any proposal, I only replied on that topic. And now, if someone sends an e-mail to me, which contain words like "you introduced P2SKH", then I know, that it is probably generated by some AI (or someone, who read AI summarizers, instead of thinking on its own, and reading the original topic).

You should probably bold the second part instead. Not exposing the public key is crucial in this sentence. It simply means, that if you have some presigned timelocked transactions, sending coins from P2PK to P2PK, then obviously the destination P2PK is not yet exposed, if it was never broadcasted anywhere. Which means, that a proof can be constructed, that you know it, and later it can be revealed. Then, even if everyone will know the private key, the previous commitment will enforce the proper destination.

Existing BIPs are not set in stone, they can be updated. I already put my comments in some discussions there. It is more likely, that I will discuss, what is already there, instead of creating yet another BIP. Also because existing ones are not that detailed, so they need to be expanded anyway.

Which is also why we don't need more BIPs, dealing with the same topic. It would only create confusion, and it could end up in the same way, as block size BIPs, where you have many of them, and none is implemented on BTC. Only altcoins like BCH used them to some extent in practice, and for the actually deployed Segwit, block size increase was fully optional, and if it would be deployed without Segwit discount, then we would still have 1 MB blocks.

It depends, what exactly will be required, to move old coins. For example: if a BIP would say "let's freeze them, without any recovery phase C, or anything like that", then yes, they will be burned.

However, if it would be similar to the previous soft-forks, where coins were not burned, but only some new scripts were limited, then there could be a different rule. Like: "you need ECDSA, and a quantum signature to move it". And then, depending on what exactly is required in that second part, coins could be burned or not. For example, if it would be needed to provide the seed, then HD wallets may be spendable, but random keys may be burned.

Which means, that knowing what is burned, and what is not, depends heavily on the "recovery phase C". If it doesn't exist, then everything is burned. If it does, then only coins covered by that are safe, and everything else may be burned, or locked into trap-like addresses, where for example you would need to break the quantum algorithm to move it (just like you need to break RIPEMD-160, to clear 1BitcoinEaterAddressDontSendf59kuE).

We have such cases. For example, secp256k1 generator was picked in some unknown way: https://bitcointalk.org/index.php?topic=5469657
When we calculate half of the generator, then for secp256k1, it is equal to 0x3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63. Similar values are used for secp160k1, secp192k1, and for secp224k1 it is even identical, which makes it easier to potentially construct some DLEQ proofs. But why exactly these values were picked, and not something else? Nobody knows. And some people are even preparing rewards for anyone, who will explain it properly for some curves. And even though knowing it wouldn't break secp256k1, the full procedure is still unknown, also because in the past, the generator was meant to just be used as an example, and different systems could use different generators; but in practice, a lot of people just implemented the default values from the documentation.

Going backward is possible, but it is just hard for big elliptic curves. For small examples, it can be done through brute-force, and for some a bit bigger ones, there are algorithms, which could be used to do that in sqrt(2^N) steps (which means for example breaking 32-bit private keys after 2^16 computations).

You can find some examples of going from public to private keys in a small elliptic curve here: https://bitcointalk.org/index.php?topic=5460766

Well, expanding your knowledge usually leads to more confusion, when you want to explain it in simple terms. For example, you can tell newbies, that "we use public keys to lock coins". But if you go deeper, then you will see the whole complexity behind the Script, that we have. And it is similar with many different aspects of Bitcoin: the more you know, the better you understand, that it is a complex topic.

It depends, what do you want to achieve. Because by knowing the code, you will know better, how it works, but it doesn't mean, that you will earn more coins. Quite the opposite: many altcoins are endlessly pumped and dumped, and a lot of people got a lot of coins from altcoins, which were designed only to generate more BTCs for their creators, when they sell them, and leave the community with almost worthless coins.

Also, the more you know, the more unhappy you would be. Ignorance is bliss. And contributing to the Open Source projects is hard. By working on closed sources, people usually earn more, and are less exposed to many toxic people. We got many great things like Linux and Bitcoin through Open Source, but it is more about sacrificing your time and effort, to make the world a better place for everyone, than about getting financial reward for doing it. Of course, many early developers earned a lot of money, but if they would just be regular users, then they could get the same thing, as long as enough volunteers would put enough effort, to push everyone to the same place, where we are today.

Not only that. There are some questions, where nobody knows the answer. Which is also why the system is still safe, because if you would know for example everything about secp256k1, then you would also know, how to break it, and how to convert public to private keys. The same with hash functions, and other cryptographic primitives: when people don't know some things, then systems like Bitcoin could be built, which would work, as long as nobody can produce the solution.

If you need more money, then just focus on investing. If you are curious, how things work under the hood, then that curiosity will push you forward, even if you won't get any money from expanding your knowledge.

There are two big parts, which are required to make a system like Bitcoin. One is public key cryptography, which means understanding secp256k1, and another is hash functions, which means SHA-256. Hash functions can be implemented from scratch in a few hundreds of lines in C++ code, and it is a good starting point. For elliptic curves, you can start from some smaller ones, and gradually increase numbers, until you reach secp256k1.

Of course. You can always run regtest locally, and test everything there.

It will cause a lot of FUD, but mainly only multiparty addresses will be affected in practice. However, if collisions will be there, then you will no longer know, if any new 160-bit address cannot be spent in a different way, which was not yet revealed on-chain.

And also, it will put other puzzles in question, because finding a second preimage may be easier than solving them. Because all of them are just behind P2SH. And also, practical collisions would mean, that people could use P2SH instead of a TapScript, where each branch would just collide with each other, so the same P2SH address could be moved in many different ways, just like it is true for P2TR.

Try signet, and see, how much it is worth: https://altquick.com/exchange/market/BitcoinSignet

Also, if you wonder, how Bitcoin would behave, if this or that would be changed, then there are a lot of altcoins, which can show you exactly that.

If nothing else would matter, then Bitcoin wouldn't be created in the first place. It was born just after 2008 crisis, and you can literally see in the first input ever created, why it was made. In general: if fiats would be better, then Bitcoin would never be needed. And as long as centralized currencies are stable for a long time, and then they crash hard, by making a lot of people poor, Bitcoin will be needed.

There is one problem with that way of thinking: similar solutions are known for years. There is nothing new, if you want to make yet another centralized mint:

https://en.bitcoin.it/wiki/Bitcoin_is_not_ruled_by_miners#Efficiency
And when it comes to other altcoins, how do you know, that some "chancellor" would never do a "second bailout for banks", but this time on these altcoins? If you wonder, why so many people are using altcoins, just to get more BTCs, then now you should know the answer. Many altcoins are doing well, mainly because a lot of people use them as a way to get BTCs, or they wrap their BTCs into them, use them, and then earn BTCs from them. If not that, then they could be worth much less, because similar solutions existed long before Bitcoin, and you can see, how they ended, when they were not connected with any BTCs, to get some value from there.

What solution would be used for multisigs, wrapped in P2SH? There is a reason, why P2WSH uses SHA-256 alone, instead of applying RIPEMD-160 on top of it. In multiparty scenarios, collision-resistance may be more important, than secp256k1, because checking 2^81 RIPEMD-160 hashes, and finding a matching public key, which would give the same address for different scripts, is solvable on classical computers, and could become reality faster, than quantum computers will break 256-bit random public keys. Even today, there are Bitcoin blocks with 80 leading zeroes, produced every 10 minutes, for example: 000000000000000000003c5ff410ed3c66b3cb803c2aac90b5b6600b20ba91e5. Changing double SHA-256 to HASH160, and using it to produce collisions, is just a matter of incentives: for now, mining new coins is still more profitable, than trying to reach RIPEMD-160 collisions.

Which doesn't protect multisig P2SH users from anything, if making RIPEMD-160 collisions will be practical. Even if all addresses are unique, then still: convincing someone to put coins in a new P2SH address, which seems to be a multisig, and then moving it alone, would require a new grinded address anyway.

They require 100 confirmations, so they should be safe.

From the perspective of a node, working on a minority chain, it looks exactly like that. But fortunately, only coinbase transactions are "replaced" in practice, everything else usually ends up being confirmed by all chains. In the worst case, some transactions could go back to zero confirmations, if some miner will decide to include some double-spends, but still: that miner would need to take part in that transaction. You have to sign your input in a different way, to actually make a double-spend, so if users are just sending transactions between themselves, then they will be safe even in that case.

No, because they will accept ASIC blocks, produced by the new chain.

In theory, the chain could split for a while. But later, a chain reorganization will just solve it. Old nodes will have some ASIC blocks, and some CPU blocks, while a new chain will have only ASIC blocks. If the new chain will reach a bigger chainwork, then it will overwrite the old chain.

Also note, that the code for mining things in a new way can be used today, without any soft-forks. The soft-fork part is only about marking CPU blocks as invalid. But mining ASIC blocks with 20 minutes delay can be done here and now, which would lower the difficulty.