An address cannot be an arbitrary string because the address itself is not stored in the block chain. Block chain explorers and wallets analyze a transaction to construct the address. As @pooya87 described, a legacy address is constructed from a 160-bit hash, plus a version and a checksum. The version and checksum are mostly out of your control.

Also, Fidelity Charitable is a donor-advised fund that many bitcoiners donate bitcoins to. I wonder if they have any stats on how many bitcoins have been donated to them.

All transactions in a block occur at the same time. The time of a transaction is the time of the block it is included in. The time of a transaction is not when it was created or broadcast, though that can influence which block it is included in. One transaction is earlier than another transaction only if it is included in an earlier block. There is no way to guarantee that your transaction is in the same block or an earlier block.

The timestamp of a block is not the time it was added to the block chain, but it is close. It is guaranteed to be within about an hour of the actual time it was added. Furthermore, it is not uncommon for a block to have an earlier time than the block that precedes it.

I'm curious about what you are trying to accomplish. When bitcoins are sent from A to B, why do you also send to B?

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 entity manufacturing 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 sign 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.

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 and 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" does. I think more appropriate terms would be "private and public key master" because they are used to create the 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 wallets does not an address. It contains addresses.
23. Decentralization -- The description applies to business management. It does not apply to networks and protocols.
35. WIF -- OMFG The link you posted links to 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.

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

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 there is no 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 converted 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.

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 simply 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.