Most of them probably don't rely completely on Bitcoin Core and builds the block using their own implementation. Most mining pool don't use GBT but stratum instead.

Unless you're able to see how the pool functions, you probably won't know if the problem exists for them and what their remedy is. Since the error exists due to the fact that they expect the coinbase flags, they can just add it at the end before feeding it to the miners.

Most of them will work without.

Many of the HW wallet, or wallets in general uses BIP39 to generate their seed phrase. The method for them to generate the seed passphrase is completely transparent and it is not difficult to obtain the private keys from that directly. Even if they use a different standard like Electrum, you'll probably be able to figure out how it's done by looking at the codes, the extract the private keys yourself.

Intentional, the mining client should modify their client to remove the flags as it isn't in use anyways. I think neither BFGminer nor CGminers are in active development anymore?
There isn't any (only the peers.dat will be discarded, if I'm not wrong) compatibility issues, if that is what you mean.

Just a little insight: I was interested in using my spare unused 2Pacs for some solomining. It was working with 0.19.1 but it broke after updating to 0.20.0 and I was looking at the code and figured out that this pull request was causing the problem[1]. If you want to mine with 0.21.0/0.20.X instead, then you'll probably have to either modify your mining client somehow to ignore that missing part in the scriptsig and compile it.

SoloMining with 0.19.1 is perfectly fine, if you don't want to complicate things.


[1] https://github.com/bitcoin/bitcoin/pull/17519

Shouldn't you be comparing P2WPKH to P2TR instead? Eitherways, both of them are showing that TR has a lower raw size for me (99vbytes vs 109vbytes). Taproot is specifically designed for signature aggregation which is largely beneficial for P2WSH, 166.25 vbytes for TR vs 357.75 vbytes for P2WSH. If Musig is your main focus, you'll reap more benefits by using TR by the lower size as well as better privacy.

What has this got to do with your post? Should be fairly easy to breakdown the components to get the total size anyways.

As we have mentioned in the thread, the fees is dictated by the user with most wallets and the fees that you're paying acts as an incentive for miners to mine your transaction over the others (transactions with higher fee rates are usually prioritized by the miners.

You are free to pay as much or as little as you want (>1 satoshi/vbyte) which can be configured for most wallet. Typically, the fees can fall within 7 satoshis/vbyte to 150 satoshis/vbyte for a reasonable time for it to be included in a block throughout the week. The general trend is that the fees are lower during the weekends. You are better off trying to optimize your spending habits by consolidating inputs and using segwit to reduce the fees as opposed to trying to find a better wallet. Wallet that offers the same address type (segwit/legacy) has no difference if you're paying the same fee rate.

Does Taproot reduce overall transaction size for non musig? I did remember that TR TXes are smaller than Segwit TXes by about 20bytes 10 bytes or so for a 1 input -> 1 output.

Segwit was activated in 2017. Does Blockchain.com implement Segwit?

It is naive to think that just because Bitcoin Core implements something, then the rest of the community will follow suit. Soft fork makes it such that it doesn't have to be a mandatory upgrade and furthermore, there isn't any practical reason why wallets have to support Taproot. It does seems like you have a few misconceptions though.


It is 15.

There is no such thing as recommended fee. The median fees are probably higher if the person wants it to be confirmed within a set period of time. I'd imagine transactions sending 0.05BTC is not rare at all.


If you're using the wallet's built in fees estimation, it is probably fairly conservative and does the job most of the time. Opt-in RBF will solve the problem and that is why it is a recommendation to have it enabled. If your fees are too low, it is easy to just replace it.

I'm not sure about the point of this question. Your choices of fees will only depend on your priority; do you want it to be confirmed ASAP or are you fine with waiting for a few more hours or days for it to confirm? I personally have pretty large transactions in terms of the total value with lower fees as they're mostly just consolidation and I don't actively spend it anyways. Just RBF it if you need it to be confirmed.
No transactions would get "stuck" forever.

A little misconception, Multisig Wallets contains addresses that has a predefined N set of keys for which at least M of the keys must sign any transaction for them to be valid. A single wallet should not generate all of the keys.

MuSig is great if you're looking for a kind of contract that requires M parties to agree to a transaction out of N total parties. In terms of it's security, I would argue that using an airgapped wallet is enough. Having to transfer your raw TX through many devices only serves to complicate the matter somewhat. Definitely won't be sufficient for physical attacks, ie $5 wrench attack.

The signature aggregation will enhance the privacy as well.

Online wallets are generally not great if you're looking to minimize transaction fees, some of them don't implement segwit and some of the have poor fees estimation as well. Custodial wallets often charges their users more fees than necessary when sending Bitcoins. That is not the only reason why you shouldn't use them.

Transaction fees are not dependent on the wallet that you're using though it can be. Wherever possible, use Segwit (bc1) addresses to have the lowest fees or nested segwit if you want backwards compatibility. Electrum and Bitcoin Core both have decent fees estimation and features but you can also refer to mempool.space as a reference to adjust your fees as well.

Scarcity is a concept that exist with most things on earth, there really just isn't anything that is unlimited in nature. Gold and other precious metal are the common form of assets that is scarce, are they as valuable as Bitcoin? The only reason why Bitcoin is popular is because of the unique characteristic that it has, transparent, secure, decentralized, etc.

The reason why Bitcoin's price keeps on growing is due to the increasing adoption and the speculation around the currency. Having a limited supply is desirable but it is hardly the reason why Bitcoin's price keeps on rising. A deflationary currency is of no use if there is no demand.

It happens: https://bitcointalk.org/index.php?topic=5315273.msg56287394#msg56287394.

I have limited my dbcache to 100MB before and it didn't help one bit. There is literally no way for the UI to be freezing due to resource constraints on my computer. Free ram usually hovers around 7GB or so and my NVMe isn't a bottleneck at all.

Blocks were generated in those 24 hours for which the client has to synchronize to catch up. From my experience, the synchronization when there are lesser blocks to catch up is much slower. It can be misleading as it often freezes the UI while synchronizing. It should be fine as long as you are able to wait for a bit.

My fairly powerful computer freezes as it starts to synchronize and only displays the initial rate which is usually fairly low (0.05%).

Some mining pools actually pays out their miners when they mine a block and mine that transaction with no fees at all.

Yes, completely possible. Whether that will resonate well with the user is an entirely different story. Unless you're able to convince your users that even though they're paying for their transaction with a fee, they have to wait for hours, or even days for the mining pool to mine a block to include their transaction, then probably not. You would probably be better off just making the users pay for the transaction and removing the other aspect of having your own mining pool mine the TX entirely.

You can probably charge larger fees while batching transactions and gain more profit this way and probably not lose many users.

Nope. In Bitcoin addresses, Base58 works by taking the network bytes + RIPEMD160 + checksum and converting it to a decimals and afterwards using the modulo and getting the remainder from repeated divisions of 58. Afterwards, you reverse the byte order of the the remainder and match it to the table provided. As such, the first character after 1 would be the last modulo of the integer.

The highest possible integer is 6.2771017e+57 for a Bitcoin address (34 characters) which is around the neighbourhood of (58^32 x 23), 23 being Q on the encoding table. As such, for the second letter to be R through z, it has to be a 33 characters and below address, highest possible integer is (58 ^ 32) and is 23 times less likely.

Do CMIIW.

If your fees estimator uses the moving average of the fees within the transaction included the blocks without referencing the mempool or the transactions that were once in mempool, this could artificially inflate the fees for those mechanism. You don't have to broadcast the transaction in this case so that no one else would be aware of the transaction before it's mined. I'm sure that it would not be efficient for someone to reorg the blockchain just to claim those fees.

Its specific to v1 addresses as they're case sensitive. Just to correct you, not every address starts with a capital letter or a number. It is simply just that the distribution of it is very skewed; addresses with lower case can only be 33 characters long due to the nature of base58 encoding[1]. 33 characters v1 addresses are actually much rarer than those with 34 characters.

Address starts with a lower case and also not a number: 1sakm3t8NqYyeuGtdP265z6GGU8LctNoE

[1] https://en.bitcoin.it/wiki/Base58Check_encoding#Base58_symbol_chart

Some of the clients that I have seen are using mempool as a source of data which could be less susceptible to this kind of attacks as the transaction has to be in the mempool for it to take effect and thus could be a net loss for the miners if another miner takes it.

There isn't much guarantees that the space that you're wasting in your blocks would actually result in larger than proportionate increase in the average fees as the miners have to consistently be inflating the fees with their own high paying transactions in their blocks. Since Bitcoin transactions are not that crucial when considering the time taken (as of now, since there isn't that many good use case for normal small value transactions), there are quite a few scenarios where users would wait for a bit for the fees to drop and thus the miners would probably have to wait for it to take effect.

Great explanation above. I'll add on slightly.

Addresses are not concepts that exist on a protocol level, they are just better representation for the users using it as it does have error detection included. The output defines the criteria to be able to spend them, for most scenarios it means that only a signature that is signed by specific public key is valid as the public key hash is specified in the output script. In certain cases, this could be spending to P2SH address which would mean that only by fulfilling the criteria needed for that P2SH script then your transaction will be valid.

The blockexplorers that you see actually parses the blockchain and matches the transactions to the address but it doesn't mean that the network functions like this. Bitcoins are not stored in addresses, your wallet simply finds the unspent outputs and the transactions that are relevant to your wallet and displays them to you. This is also why you have to synchronize Bitcoin Core to be able to see your transactions and your address "balance".

Sender address is not specified in the transaction, your transaction contains the ECDSA public key of the relevant address and is also how nodes or anyone else can verify the signature to be correct and that the public key hash also corresponds to the public key hash that was referenced in the previous UTXO. For a P2PKH transaction, the previous TXID is referenced with its index and a signature with the public key.

If you're using Windows, just running the installer will do. It will remove the old files and replace it with the new. Your Bitcoins are safe if you backup the wallet.dat which if you haven't, you should do so ASAP.

I can't think of anything that breaks 0.16.0 in the recent releases. You should be able to make transactions without any problems. Even if the transaction you make doesn't end up being visible on the block explorer, you can just update Bitcoin Core and everything will still be fine.