It is recommended for users to use an unique address for each transaction for better tracking and privacy of payments. Otherwise, it is okay to use the same address for donations. Just create a button to let others donate to your address.

If you want to generate an unique address for each transaction, try using Electrum [1].

[1] https://electrum.readthedocs.io/en/latest/merchant.html

You're underestimating the amount of resources and the benefits governments would gain from attacking Bitcoin. Cryptos will still thrive regardless of if the attack suceeds or not. Its not difficult for Bitcoin to fork to a different algroithm and the government would be left with a huge pile of useless ASICs.

If they have enough resources, there's no fight at all.

I see no point in increasing the cap of Bitcoin. The main characteristic of Bitcoin is for it to have a fixed supply and thus a stable deflationary model. For the coin cap to be changed, it would ruin that characteristic of Bitcoin and it probably would never garner enough support.

It's much more viable to increase the denomination of Bitcoin though I never imagine there would actually ever be a need for that.

Just to explain the existence of its warning; with a different version numbers, the client would automatically assume that the miners could be voting for activation of an unknown rule for the network. This could be dangerous for the client if the client doesn't know what the miners are signalling for and thus what the change is about.

In this case, it's simply the fact that the miners are using overt ASICBoost which changes the versionbit to one that is non-standard. The client would automatically display a warning as it has an unknown version but it wouldn't be that big of a concern to most since it only appears in the debug.log.

Oops sorry. My bad.

I was referring to a bug that was present in Bitcoin quite some time ago. The bug allowed the coinbase of two different blocks to be the same. This resulted in one of the two coinbase transactions being invalidated and thus the coins are permanently lost. IIRC, this was the motivation behind BIP30.

First of all, you calculated the supply that includes the reward given to the gensis block. By design, the genesis block's reward is not included in the UTXO. That is 50BTC gone alone.

IIRC, there were a few blocks that had a fork and the coins from those blocks were lost. Due to bugs in the miner's implementation, there were instances whereby the miner didn't claim the entire block reward and/or fees and that is definitely not in the satoshi range.

You have to consider that some coins were also burned by the use of OP_Return and they were removed from the UTXO of the client.

The private keys has to be known by the 3 escrow agents. The link stated only serves as an example as to how that specific multisig address was generated. In reality, the multisig address is created by using the public keys of the addresses belonging to the 3 escrow agents.
Hardware wallet may have some difficulty signing raw transactions for multisig transactions depending on the hardware itself. You have to choose a wallet which allows you to sign and broadcast raw transactions.

---

You don't really need to have 3 escrow agents. Multisig works perfectly with one escrow agent and both Alice and Bob hold a key each. For that multisig set up, it would be a 2-of-3 multisig and 2 parties would be needed for the funds to be released (Alice/Bob, Alice/Escrow or Bob/Escrow). It would still be safe since either both parties have to agree to release the funds or the escrow have to agree with one of the parties.

Still looking for this!

Would pruning not work for you? It's possible for you to use a code to script your own raw transaction and then directly broadcast the raw transaction to the other nodes. But that would require you to be able to obtain the information about your UTXO in the first place and it would preferably be from your Bitcoin node.

You don't have to keep the entire blockchain on your computer for the whole time. You can delete the older blocks as you go with pruning and keep it from exceeding a certain size.

That being said, Electrum offers JSONRPC and you can easily integrate that with your code. There's some examples here[1].


[1] https://electrum.readthedocs.io/en/latest/merchant.html

Unless something has changed in recent versions, the risk of downloading a pre-verified blockchain can be quite substantial. With the chainstate being built, it is possible for the attacker to manipulate the client to display the wrong information or to get you to a wrong fork. The checks that Bitcoin Core does during start up only validates the recent blocks for corruption and doesn't check through the whole blockchain.

AFAIK, in the earlier versions, the reference client started mining using setgenerate and it would always mine to a new address. It doesn't necessary mean satoshi mined Bitcoins to different wallets but it could mean that satoshi mined Bitcoins to many addresses within the same wallet.

Different addresses=/Different wallets.

Where did you get your Electrum client from? The current version is only 3.3.8 and it is nowhere near 4.0.0 yet. Are you certain that you copied that address correctly? If the address differs from the one that you saw on their website, then it's your fault and there's nothing that they can do. And if that's the case, then you could possibly be a victim of clipboard malware.

Stateless verification only means that the information required to validate a script is contained within the script itself. This does not necessary mean that a script is guaranteed to be valid. This only means that the script will be executed the same way on every client. The only way for the individual clients to know if a script is valid is that if they check for it themselves.

As per discussed, I have returned the loan early (with prorated interest): d1d1e4ed1efaf1e0dee36e2005315c3002995bc0fd46b0b8c11e43b3163cd134. Thank you for the loan, appreciate your help!

Can you use an external client (https://iancoleman.io/bip39/) to validate if the address is within your xpub? I know blockchain.info is not reliable but its weird that its not showing up when you search your xpub either.

Else, import it into Electrum putting a BIP44 derivation path when asked.

The whitepaper served as a concept as to how a cryptocurrency like Bitcoin should work. The whitepaper did not encompass all of the rules that Bitcoin should have because they weren't concrete yet. I'm sure most of the protocol rules were decided after the release of the white paper.

Most of the protocol rules that you have in the client now is after many revision of the reference client. For example, there wasn't any limit on the block size and it was only enforced after a few releases.

For most of the services, the GPU is connected to the server itself. You would be using the server like as if its a normal computer with a GPU inside it. However, you must pass the flag to the programme. (ie. adding a -gpu in the argument).

You can't. Having an address will not reveal the other addresses generated with the same seed. The only way for you to obtain all the addresses within the wallet is by using the master public key to generate them all. If you were to disable change address, all your Bitcoins would be consolidated within one address, provided that you also only use that one address. This would greatly affect your privacy however,

You'll be looking at crypto-payments.net. They offer a wide range of crypto currency for users to pay with and is relatively easy to implement and stable. Alot of merchants are using them too.