I don't understand enough about that. You can also replace PoS with a protocol that has yet to be found.

In 20 years Biotcoin must be worth several million to be as safe as it is today. Or the fees or the transactions must increase significantly. We know where the reward will be in 20 years' time. But we don't know how many transactions there will be then. Or am I making a mistake in my thinking?


Perhaps thermodynamic protection would be a better phrase. I don't know. Be that as it may SHA256 forces the use of energy that can hardly be reduced. Correct? I think it is very secure today. I don't know how I could calculate SHA256 with significantly less electrical energy than Bitcoin computing systems do today.

But if there are fewer and fewer rewards, the price only increases by a few percent a year and not much more comes in via transaction fees, then this may change over time. Or am I making a logical mistake?

Now I want to ask you people here one more time:

Why isn't an additional PoS layer being discussed?

I understand that SHA256 mining is important during the distribution process.

But if everything or almost everything is distributed, SHA256 mining simply becomes a validation whose thermodynamic maintenance depends on the transactions themselves that are to be validated.

You then have to expand the money supply. You can call it "recycling" of "lost" coins, but in economic terms it is an expansion of the money supply.

In my opinion, an additional PoS layer would be economically less intrusive. The reward could still go 100% to the remaining SHA256 miners. But the transaction fees could be partially distributed to PoS validators.

I didn't write that. I wrote that fees are becoming increasingly important for miners. The increase in fees means less decentralization because the miners become more (much) dependent on the users.


But what if it isn't? Is it even desirable for the security of the network to depend on the level of fees? At the moment, the fees are used by users to prioritize their transactions. However, the miners are not dependent on the fees. And that wouldn't be good either, because unlike the mathematically predetermined reward, you can't plan the fees.

I don't have a definitive position on this. I don't have a suggestion that says: "this is how we have to do it!"

But I do know that in 16 years we will need eight times the market price of today to have the same fee-to-reward ratio.

As things stand now, the Bitcoin network would continue to exist with almost unchanged computing power even if there were not a single transaction in it. The miners would simply create empty blocks.

But will that still be possible in 20, 30 or 40 years' time?

And if the answer is no, then my question is simply whether that can be a problem?

My answer: I don't know, but I can't rule it out either.

But enough, I really have no idea. And I think smarter people than me still have a lot of time to think about it.

I don't have much of an idea, but I've given it some thought anyway.

I think that the mining process via the Proof-of-Work is the optimal safeguard in the distribution phase of Bitcoin. In this way, Bitcoin is distributed in a way that is acceptable to most people. The term mining implies that new Bitcoins are generated in this process. Changing these basics would indeed seem like fraud.

However, it is also clear that the Bitcoin price cannot more than double every four years for all time. This means that fees are becoming increasingly important for miners. Bitcoin loses its distributed nature because nothing is distributed anymore. But simply increasing the Bitcoin supply is not a solution either.

How do we escape this dilemma?

Instead of wanting to rule out 51% attacks, you probably need to think about how to deal with them.

Questions:

• What is the point of a mining process that hardly generates any new coins?
• Do validation and mining have to be inextricably linked?
• If the fees exceed the reward, is it possible to add a proof-of-stake process for validation?

These are interesting mind games. I think we have at least another 16 years before we actually have to deal with these things. But it will have to be done at some point if humanity wants to use Bitcoin permanently. Solutions are usually found when a majority finds a technology useful.

Thank you for posting this here. I think there is a lack of software that calculates addresses independently of the core client. There is the Ian Coleman tool. See:

https://github.com/iancoleman/bip39

But the tool does not support taproot, for example. It would be fantastic if there was an easy-to-use tool for this too.

I absolutely understand that you want to check the calculations twice. But let's assume we trust the core client and the math.

Why don't you simply save the output of


I have already used it to completely restore wallets (as a test). It can also be encrypted. Linux command line:
And it fits easily into a QR code.
You can of course also print out the QR code.

That's just an idea. And quite independently of that, I find your project very useful.

I don't have a sendable Merrit at the moment, but thank you very much.

Many thanks for the reference. I am trying to understand this as a whole and also came across this page:

https://learnmeabitcoin.com/technical/script/p2wpkh/

I hope the explanations there are correct.

I think my difficulties in understanding are due to the fact that I have not yet understood the classic P2PKH procedure in detail. So I still need to study it myself.

One question that is bothering me: What exactly is signed with the P2WPKH procedure? I sign on my offline wallet with the private key material. But what is the input for a signature?

Or to put it another way: How does the Core Client check the correctness of the signature? To which data does the core client (or another Bitcoin programme) apply the coresponding pubkey?

Thank you for your assessment. Is it possible to decode “txinwitness” even further? So the first value:

Question to ChatGPT:
I create an unsigned PSBT file (P2WPKH) in a watch wallet. I then sign the file offline and import the signed file back into my watch wallet. I can then broadcast the corresponding transaction and the transaction is added to the blockchain. However, when I look at the signed PSBT file, I only find “final_scriptwitness” as an additional value, but no explicit signature. What is the reason for this?

There's not much to choose from. You enter the Bitcoin amount and the destination address. The client takes care of everything else. It also calculates the appropriate fee, although you can overwrite this value with your own.


You can then view the PSBT file with the corresponding command lines and try to understand it before you broadcast it.

Yes. I have already used it successfully. My main reason for this is the hope that the QT client will just do the “right” thing. For someone with little knowledge (like me), this is perhaps the best option. I don't know.

Yes, that's exactly what you're looking for. This describes your HD Wallet mathematical complete. Even if your backup of wallet.dat is lost, you can use this output to restore your wallet. It contains the xprv key from which all key material can be derived.

If you use listdescriptors (without true), you will get the descriptors with the corresponding xpub keys. You can use this to set up a watch-only wallet on an online system.

I had exactly the same problem/questions as you.

This is how I proceeded:

• First I wrote `listdescriptors true` in a file on my offline system. Then I wrote down the xprv key manually. Then I removed the xprv key in the file from all descriptors and replaced it with a string, for example:
  '__XPRV-KEY-HERE__'
• I then saved the file with the descriptors (without xprv key) electronically and also printed it out.
• Finally (for testing only), I took a completely new offline system and merged the descriptor file and the xprv key again. I imported the result into the core client and used it to sign a test transaction.

The encoded xprv key is about twice as long as the old legacy keys. But you have stored all the private keys of your wallet with it. 

This is not a complete description of what to do. But I hope this gives you an idea of how you can proceed for your purposes.

Oh, that makes sense. Many thanks for the tip. I found a good explanation here:

https://www.reddit.com/r/Bitcoin/comments/wywsre/comment/im0g45w

Why do I have to rescan the blockchain for hours to see the correct balance when I add a descriptor/key, but when I broadcast a transaction, it is confirmed in no time at all? Sometimes it really only takes a few minutes to get the first confirmation. I usually end up in the next block or the one after that. 

How does the network check for double spending so efficiently?

Sorry for the maybe stupid question, but I'm stumped right now.

Or the corresponding button in the GUI? Thanks for the explanation, that helps me a lot!

I have two more questions if you have time to answer. 

1. I have imported one of the descriptors (pkh) on the online machine. The daemon has started a rescan. This probably takes a very long time in my case. The RPC call ended with a timeout at some point. But the daemon continued rescanning. Then I terminated the daemon as a test and started it again. But it does not continue with the rescan after restart.  I know that the displayed balance is correct, but why doesn't it continue the rescan or start it again? I have also reloaded the wallet.

2. I have received 4 descriptors with the same pubkey for each legacy address. The types are pk, pkh, sh(wpkh), wpkh. I have now used the pkh descriptor. But could I also use the others? What should I use? I would like to transfer the coins to a Segwit address (bc1).

Do you really mean all addresses or addresses with UTXO?

Given: A copy of an old non descriptor wallet (originally created 2013) on an offline system with Bitcoin Core 28. Only two addresses were used at the time (2013-2014).  Bitcoin Core 28 was able to open this old wallet and it was possible to migrate it to a descriptor wallet. Now listdescriptors shows me thousands of descriptors that I don't actually need. All this on an offline machine.

What I would like to do: I would like to set up a watch-only wallet for the two addresses on an online machine and then create a unsigned transaction that transfers the coins from the old addresses to a new hd wallet.

The problem I see is that I can't generate new keys in a legacy non-hd watch-only wallet. This shouldn't actually be necessary in my case, but I still have the feeling that I'm on the wrong track here. What would be the safest course of action?

Is it possible to have legacy descriptors and hd descriptors in one wallet? Would the core client then derive the change addresses from the xpub keys?

Is it safe to use an address twice (privacy excluded)?

I have read that if the random nonce k used for the ECDSA signature is not chosen at random then someone can calculate the private key.

Is this really a problem in practice?

I make a test transaction for new addresses to make sure that they work correctly.

I use Bitcoin Core 27.1.

You and nc50lc helped me again a lot. Nevertheless, I need to look into it more myself in order to fully understand what you have written.

What I generally understood:

The process of signing may require significantly more data than appears later in the transaction, as previous transactions may also be included here. The PSBT may then have to contain this additional transaction data. The size of the PSBT depends on how my transaction was added to the blockchain. I could use Taproot (Bech32m) to avoid the problem.

An average transaction is only 300 bytes in size. I could therefore mitigate the problem by converting the signed PSBT into a raw transaction on the offline device. Then at least the return path via a QR code would work. Do I see that correctly?

I don't know what you think, but I'm a little reluctant to use Taproot because it's still so new and I know so little. I didn't even understand the normal Segwit. I think I'll stick with the Bitcoin Core standard addresses (native Segwit) and figure out how to deal with the big PSBT problem and my air gap later.

Shouldn't legacy addresses according to BIP 44 solve this problem? The psbt file should remain small, shouldn't it? Do legacy addresses have any disadvantages for me apart from higher fees?