Exposing your master public key will severely reduce your privacy. When putting it into an app, the app has to make a connection off the phone to get all the transaction information related to your master public key. This means that the app, or the server that it connects to will know the transactions that you have made or will make in the future.

Not saying you get loads of privacy from using Coinbase. I would recommend you to just monitor individual addresses as and when you need to.

It's a free market. By market forces, the price should reach an equilibrium when the demand is equal to the supply. If somehow the demand overwhelmingly exceeds the supply, then the price will rise. It continues until it reaches an equilibrium. It's simple economics. More demand, same supply = higher price.

It functions on simple economics.

Unfortunately, yes. Segwit has made some improvement in this regard but it is definitely insufficient. Unless you're proactively doing consolidation and making transactions during the less congested periods, it's likely that you're going to pay a significant fees when doing micro transactions. If you're looking to do micro transactions, it could be better for you to explore offchain solutions instead. Lightning network offers instantaneous transaction while maintaining a fairly low fee.

Coin control is a feature that is implemented in the GUI. You can replicate this by getting listunspent and construct your raw transaction, sign and broadcast it.

Lockunspent is the easier way to do it without the need to specify inputs. You can just use sendtoaddress normally after using lockunspent. Note that this list doesn't persist through a Bitcoin Core restart.

Yes. That database represents all the unspent coins (or rather unspent outputs) that currently exist. If I've understood your question correctly, which is how Bitcoins are defined and represented at a protocol level. Reading the book would probably answer most of your queries.

Nope.

Transaction always references the UTXO that are created from the previous transaction.  UTXOs are stored within the chainstate for the reference client. The link for the more technical format is here[1].

You should have a read up on Mastering Bitcoin, it has plenty of visual references which should aid your understanding. Specifically to this question, you'll have to refer to this[2].

[1] https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage#The_UTXO_set_.28chainstate_leveldb.29
[2] https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc

---

Edit: Link within the wiki is outdated and they changed the format of the chainstate from around 0.15.0 iirc.

You'll have to refer to this: https://github.com/bitcoin/bitcoin/blob/master/src/coins.h#L24 for the current format Bitcoin Core uses.

No.

There isn't any data that specifically represents a single Bitcoin. Rather, transactions references UTXOs (unspent transaction output) within transactions to send the funds. Every transaction, other than the coinbase transaction within a block contains a UTXO to be defined and spent. The UTXO set contains data like the TXID, TX index, block which it's in, script etc, amount, etc.

Bitcoin works like a ledger where the coins are originated from the coinbase transaction in a block but there is no actual representation of individual unique coins.

The ledger should not contain the private keys pairs for each pkh address. Transactions can only be spent by fulfilling the criteria as defined in the UTXO, be it corresponding signatures or specific conditions.

Your OP_Return has to be below 80 bytes (or a little less) or it'll be rejected by the relaying nodes as it is non-standard. Testnet is able to relay the transaction because the standardness rules are disabled there.

To increase the limit, run Bitcoin Core with -datacarriersize=X, where X is the size in bytes. Note that this only ensures that your own node is able to relay or mine transactions with OP_Return greater than X. It does not mean that the other nodes will relay or any miners will mine your transaction.

Each standard transaction can only contain a single OP_return script so you're out of luck there.

Not any. Some wallets has a different derivation path and you might have some trouble trying to change it to generate the correct addresses. Depends on what you're doing, generating a new wallet and getting a new seed can be a good idea at times, if you feel insecure reusing the seeds.

It's okay to switch wallets and get a new seed. Sending them when the fees are low would be better though.

There isn't a way to get the absolute value since there isn't anyone actively recording the mempool size of the individual nodes.

The mempool size would be more dependent on the limit as specified by the individual node as opposed to the number of nodes it's connected to. Transaction propagation is generally fairly extensive, nodes will always attempt to find out transactions not in their mempool by sending mempool messages and receiving inv message as a response to populate their own mempool. It's thus fairly unlikely for the node to miss any transactions unless all of their peers has rules that are more restrictive than the user's nodes.

Not running your node 24/7 or not having more peers should not result in your mempool being significantly lower than others. At least the reference nodes should be able to see most of the standard transactions.

Your previous thread: https://bitcointalk.org/index.php?topic=5304116.0. I didn't receive any response from you but please let me know if you didn't understand any parts of my explanation.

To correct again, the mining software doesn't interfere with the wallet nor 'pays' the miner's rewards. The most it could do is to specify the coinbase transaction and the outputs which are already decided before a valid block is mined.

Your transaction fee was 0.0001BTC, not 0.0011BTC.

You should upgrade your Bitcoinqt, the latest version is 0.20.1. Both transactions are untouched and there isn't any other transactions in the wallet. Are you sure you were using Blockchain.info? Did you doublecheck the address you sent to after creating the URI request? You should have received either 0.001BTC or 0.04517068BTC.

Why did you not realise the error after sending the funds? It has been nearly 6 months.

Electrum pre-generates up to 20 unused addresses for their main address and 10 for change addresses. This is known as the gap limit.

When an address receives a transaction, it's marked as used and another address is displayed to maintain the 20 addresses buffer. The change address is used when you send a transaction. As transaction outputs cannot be spent partially, the remainder of the funds after fees are sent to your change address. As to why it doesn't spend the funds back into the original address, it's for privacy so that an outsider cannot immediately determine which addresses is your recepients.

As an illustration, if I receive 0.1BTC and I'm sending 0.09BTC to B.

Me (0.1BTC) -> 0.09BTC (B)
                       0.01BTC (Change address)


As a HD wallet, Electrum uses different derivation path for both the receiving addresses and the change addresses but it is transparent to you. You will be able to generate both with your seed phrase.

No. ECDSA keys are used for the public/private key. SHA256 hashes has 64 characters, not 256. Message signing is also not done with SHA256 but rather ECDSA.

---

Bitcoin wallets usually use WIF for easier importing of private keys and they usually start with 5, K or L and are not 256 characters long. For ECDSA private keys to be 256 characters long, the key would have to be represented in binary, which AFAIK no wallet does that.

Most wallets only lets the user have one type of addresses to prevent confusion. It's totally possible that some wallets could offer it in both formats, for compatibility with certain services. You can probably try to use walletexplorer to see if it belongs to exchanges. Some exchanges have both bech32 and p2wsh for their deposit addresses.

It's possible for the transactions inputs to contains UTXOs from both address type, as long as the requirements as encumbered in the UTXOs can be fulfilled.

I've never heard of that wallet before.

Where did you get the address to give to Coinmama? On Blockchain.info, do you see your address in the output(recipient)? If you accidentally copied the wrong address, then the funds are lost and there isn't any way to get it back.

Not much, I daresay. Most electrical appliances are actually well designed to be consuming as little power as possible. Your study was from 2004. But, that's not the point.

I totally agree that Bitcoin won't be the significant factor in climate change. However, the rhetoric is that, mining is a frivolous and wasteful use of electricity. The research aims to find out how much electricity Bitcoin really consumes, I'll be happy to have something to show the skeptics and it would provide a way better visualization, and also a far more accurate estimation than most other sources.


How exactly would any one be able to determine how much electricity Bitcoin uses? Such research aims to determine the energy consumption, just see their FAQ (https://cbeci.org/faq/). If anything, research proves that Bitcoin doesn't contribute too much to climate change. Objective research is necessary; no one would really have a decent gauge of the energy consumption if research like this doesn't exist. No one cares if people say Bitcoin doesn't contribute to climate change, they want concrete data, which is provided by the research in the thread.

I don't think research are necessarily pointless, if at all. No matter how useless people think they are, the data collected and/or the conclusion drawn can be used as a reference in other papers.

There is a glimpse of hope that by the time we get to that phase, the market would've matured enough such that huge price movements would be less common. It would also signify that miners are just having a thin profit margin and shutting down the bulk of their equipment would be more worth than just keeping it running to earn a marginal profit.

I see block rewards as a way to distribute the coins but as the block subsidy decreases, the adoption rate would've increased. Currently, the main offchain scaling solution is LN. If the only time the on-chain transactions are needed is to open and close the channel, I would think that the total on-chain fees would increase while still having the same or even more utility.

For the fees to completely replace block rewards, assuming current levels should bring the fees about x6 more expensive and/or x6 increase in transactions/block. I would think that given time, the problem could be resolved. There is still a few years until block rewards would form a big bulk of the miner's profit.

Then there isn't really a negative to this. You still need to secure the wallet.dat, just that you don't have to do it every 1000 transactions.

By running your client with upgradewallet flag, it will dump all the used addresses into the wallet.dat and future addresses will be generated from the seed. AFAIK, it doesn't automatically sends the funds to a new address generated using the HD seed so you shouldn't really need to transfer the funds.

HD wallets allows for the generation of addresses from a single seed. As long as you have that seed, you just need to make a single backup. There should be virtually no limitations on the amount of keys that could be generated from a seed.
You can always consolidate when the fees are lower. HD wallets do provide much more convenience over older wallets and you won't have to make frequent backups to your keys as well.

If there's an option for seed phrase, even better. Paper backups would be even easier.

---

What wallet are you using now?