What you are describing is called a "physical bitcoin". The idea has been around since the beginning, but it never really gained acceptance. One of the reasons might be that the cost of manufacturing is high.

If you are using multi-sig to prevent either party from knowing the other key, then you need a process that prevents the manufacturer of the notes from knowing the keys.

The straightforward solution is for the customer to sign a message with the private key used to sign one of the inputs in the transaction paying the bill. However, getting the wallet to provide the key is typically not straightforward, and I don't think any wallet provides an automated signing feature, which would be ideal for you.

I have to disagree with your assessment. The number of Bitcoin UTXOs has been climbing consistently, which means that the number of outputs has been consistently greater than the number of inputs.

A possible solution might be to require a transaction to cosign only one input for all of its outputs. However, that might create the reverse problem of not having enough transactions to cosign all the inputs (because there are more inputs than transactions). Perhaps the solution is to require a transaction to cosign a number of other inputs equal to the number of its inputs.

I think it's an interesting idea. I like your insight about validation through cosigning.

I have some questions. Forgive me if they have already been answered.

1. How do you prove that the cosigners were chosen randomly?
2. How do you ensure that cosigners are available for each transaction and transactions are available to be cosigned? It seems like there is a balance that must be maintained. For example, a typical transaction has one input and two outputs. This implies a shortage of inputs available to cosign.
3. An attack seems possible in which the attacker creates transactions but refuses to cosign their assigned inputs. I think this was already suggested, but your reply was not clear to me.

In my opinion, it is not a good idea to pre-select the answers to the questions based on the respondent's self-classification.

It introduces a bias because the respondent is likely to choose the answers that you have already chosen for them.

Without the bias, you would have the opportunity to compare the answers with the self-classification to gain more insight and to improve the analysis.

Bitcoin is a hedge against inflation because it has a fixed supply, or at least currently a supply growing less than the rate of inflation. In fact, most assets can be considered as hedges against inflation because their values are not dependent on the value of the currency. Debt is an example of something that is clearly not an inflation hedge.

A hedge is something that is not correlated (or at least not positively correlated), so price fluctuations are not relevant. What you are really asking is whether Bitcoin is a good hedge, considering it's volatility. In my opinion, if you are looking for something that is only a hedge, then Bitcoin is probably not the best. I think a better choice would be land or housing.

I feel that the terms "master private key" and "master public key" were poorly chosen, because they are not keys. The traditional "master key" is a key that can open a series of locks, and that is not what a "master private key" or "master public key" does. I think more appropriate terms would be "private key master" and "public key master" because a "key master" is used to create keys, but it is too late for that now.

Newbies seem to love posting glossaries, but they are typically full of errors and misunderstandings. I encourage newbies to avoid the practice.

The following terms have descriptions that are inaccurate or not applicable to Bitcoin:

13. Wallet Backup -- It says to update the backup every time a new address is generated. That is unnecessary and risky for a bitcoin wallet.
20. Wallet Address -- A Bitcoin wallet does not have an address. It contains addresses.
23. Decentralization -- The description applies to business management. It does not apply to Bitcoin, networks, or protocols.
35. WIF -- The link you posted is a description of WIFcoin. Clearly, you have no understanding of what WIF means.
37. Ransomware -- The term has no place in a glossary about Bitcoin.

Until Bitcoin demonstrates clearly that it has broad utility, the price will always be based on market speculation about the potential for utility.

You have made a lot of claims that are backed up by nothing. You might want to adjust your tinfoil hat and try again.

If change addresses are not automatically recovered from a backup, that seems like a serious bug/shortcoming in Bitcoin Core to me.

A couple of questions.


You write that you need the public keys, but the instructions never use them. When you wrote "public key", did you mean "address"?

How do you find the public keys (or perhaps addresses) generated by the wallet in an explorer?

That statement is confusing to me. How is the lost card protected? It can't be used because 2 of 3 cards are necessary, or because a PIN is required? Can you clarify?

Sorry for being late to the conversation. I'm curious why you would want to encrypt the drive. You might want to put your wallet and perhaps bitcoin.conf on an encrypted drive, but I can't think of a reason to encrypt anything else. If you only have a single storage device, I bet there is a way that you can split it into two drives and make one of them encrypted.

You are incorrect. The text of the mnemonic phrase is passed to the PBKDF2 function. The mnemonic phrase is not decoded back to the entropy it encodes. As such, anything can be passed to the PBKDF2 function. It does not have to be valid BIP-39.

From BIP-39:

The only reason for decoding the phrase to its original binary is to validate the checksum.

That is not my reasoning, but your point has merit.


Every hard and soft fork is an example of "rules that were set in stone since 2009" that are no longer followed. More importantly, are you advocating that changes to the Bitcoin protocol should not be discussed?

Any fee could be considered "confiscation", so the hyperbole is not helpful. And, the fee I am suggesting, 1 satoshi/bitcoin/block, is not "huge". It is very small. It is not 5% over 15 years. It is only 1% every 20 years.

The system has to pay for itself, so fees are necessary. In my view, if some use of Bitcoin has a benefit, then a fee related to that use seems appropriate. You make it clear that there is a benefit to holding bitcoins, so wouldn't it be reasonable to pay a fee for that benefit? Why should others pay for your benefit?

More complexity may be necessary, even though it is not desirable. Are you saying that none of the protocol changes currently being considered increase complexity?

My suggestion does not confiscate coins. Like yours, it imposes an additional transaction fee, but based on the age of the coins. There is no need to determine whether coins are "lost".

The purpose of "tail emission" is to guarantee revenue per block. Your suggestion of a flat fee does not accomplish that.


But that is a problem. If blocks are empty for 4 years, then there would be no tail emission for the next 4 years.


If you want to guarantee revenue from a block, but you don't want inflation, then you must pay it from the current supply. That requires some form of demurrage in the end as far as I can tell.

I have another solution -- a fixed tail emission paid for by demurrage. The result is that the value of each person's holdings decreases similarly to inflation, but there is no inflation.

Here is how I would implement it:

1. A number of satoshis in each input UTXO are burned in a transaction and cannot be spent. The amount burned for each input UTXO is equal to its age (in blocks) times its value divided by 100 million (1 satoshi/bitcoin/block).
2. In addition to the subsidy and fees, the block reward now also includes a fixed amount of 21 million satoshis. Transaction fees are still necessary, and the subsidy would continue to halve as normal.
3. Any UTXO with a value less than or equal to its 100 million times its age (in blocks) become unspendable.

The effect is:
1. Bitcoin becomes slightly more of a medium-of-exchange than a store-of-value.
2. Lost coins and dust are eventually recovered.
3. The number of bitcoins in circulation varies, but always tends toward 21 million.

This solution requires fractional satoshis. To make things simple, I propose dividing a satoshi into 100 million parts (because the demurrage cost is ¹/_{100 million}).

The number of bitcoins in circulation would vary because they increase at a fixed rate but are burned only as they are spent. However, the number would always tend toward exactly 21 million.

The cost due to demurrage would be about 52600 satoshis per bitcoin per year, or about 0.05% per year.

All bitcoins would be completely replaced every 100 million blocks, or approximately every 1900 years.

The demurrage cost is arbitrary. I picked 1 satoshi/bitcoin/block because it is simple and low. In contrast, a 10 satoshi/bitcoin/block would result in a cost of 0.5% per year, which I feel would be burdensome.

Imagine that your employer says to you, "In order to motivate you, we are going to hold half of your salary for 4 years." Also, consider the steady state -- the amount burned during the current period is the same as the amount paid to you from the previous period. The two cancel each other.



This will only work if the token retains value. First, I don't see why it would hold any more value than any other alt-coin. Second, the value of an inflationary currency always moves toward 0.

Also, if the coin does somehow retain value, then it would be competing with Bitcoin.

A result of your scheme would be blocks full of transactions with people sending bitcoins to themselves just to get that perpetual royalty.