Probably not the case.
I update it via a script every 5 minutes, but I'll lower it. Probably wouldn't matter as long as the update interval is somewhat reasonable.

I'll say that your method will have limited effectiveness, if you consider the current situation. Being able to broadcast your transaction entails that the total mempool will be less than 90~100vMB or so depending on overheads. When you're able to broadcast it, it'll probably be when there are only 1 sat/vbyte transactions left in the mempool and all of the others were mined by a miner. This definitely won't happen overnight and even if miners were to mine successive blocks, which is unlikely to be sufficient, there is little chance of your 1 sat/vbyte transaction (currently there is 90vMB+ of transactions paying 2sat/vbyte or more) being confirmed even if it gets relayed. After it gets relayed, if the minmempoolfee increases at the slightest, your 1sat/vbyte transaction would be evicted again and the whole process repeats.

Just to put things into perspective and help you manage your optimism.

Public keys are not technically addresses as addresses are the hash of the public key.

Let's establish some things first for clarity. 1M311YjWBuHbZhLDynBKFCTXosJe7d2Boi did not exist in 2009; Satoshi (or whichever miner who mined that block) did not send the Bitcoins to a Bitcoin address but to a public key. Blockexplorers tend to oversimplify this and associate public keys with the corresponding addresses had it been expressed as an address. You can check it yourself by decoding the raw transaction and see that it is infact a P2PK transaction.

Blockexplorers will associate P2PK transactions to the corresponding addresses and that is fine. But, in the case of Electrum, your query to the server would be your watch-only address which is not a public key. Since Electrum nodes only fetch the transactions related to that script hash (ie. the two transactions shown) as they do not do what blockexplorers usually do, you would only see the transactions that are sent to and from that address, not public key.

No. P2PK is Pay-to-Public-Key which means you're not specifying the outputs as an address but rather an ECDSA public key.

Nope, it's not or perhaps their settings is slightly different.

Both Statoshi and my nodes are indicating it to be slightly more than 1.9sat/vbyte. You can check my node's info for something that indicates the default settings and thus the general node population: http://163.172.57.208/getmempoolinfo.txt.

I would probably expect it to be purged again after the TX volume rises by the mid week, if that happens just broadcast it again. Don't think ~2sat/vbyte has any chance for a confirmation given the current situation.

Electrum doesn't display P2PK transactions, and the earlier coinbase transactions are all P2PK transactions.

When you're importing a watch-only address, Electrum looks for the transactions which is related to you through it's script hash derived from the address. P2PK transactions are thus not related to that scripthash and not shown.

That output is usually displayed after the user runs bitcoind, or at least that's the case for me on Linux distros. It basically outputs the logs that you would see on debug.log onto command line and is usually just it accepting new blocks or peers activity. You can see it by opening the debug.log as a text file that is located in the same directory as the blocks. Default directory for Mac is ~/Library/Application Support/Bitcoin/.
If you want to get the status, try ./bitcoin-cli getblockchaininfo for the synchronization progress.

Don't really think most people actually has that much difficulty when typing passwords? Bitcointalk doesn't usually add the tiny features frequently but it would be fairly easy to do so.

Instead of asking the forum, why don't you just get a tampermonkey script that would toggle the password's visibility?

Institutional adoption is by no means a suitable indicator of mainstream adoption. It just means that its volatility nature allows some riskier firms to venture into crypto. While it isn't very hard to learn the basics of Bitcoin, which by the way would give you quite some insight if you can read the whitepaper, it just doesn't make sense for the general population to use it. There isn't really any viable and widespread real life use as of now and possibly in the near future.

Not really. 2FA only serves to protect the user from external threats and assuming that the site doesn't have any loopholes in terms of social engineering and other vulnerabilities.

Coinbase may seem secure but so did most of the exchanges before they got hacked. They are known to have outrageous policies which allows them to freeze your coins and track your transactions whenever they want. You won't know how secure it is until something happens. Trezor is a hardware wallet which mainly defeats the threats through malware and to an extent physical attacks as well. They are not a cold wallet. I consider hardware wallets to be mostly more secure than web wallets; 2FA can only protect you so much and it doesn't always fare that well against malware in the first place.

Same reason why people urge others to run a local instance of their wallet instead of having to connect to something that can be changed at a whim without any of the user's authorization.
There is[1]. It isn't necessary for the user to use SatoshiLabs' servers, they can run their own and be perfectly fine.

[1] https://wiki.trezor.io/User_manual:Running_a_local_instance_of_Trezor_Wallet_backend_(Blockbook)

Did you select the correct wallet file to open? So you're saying that you've restored the wallet using the seed months ago, left it there and you can't see anything on it now?


Did you create a 2FA wallet in the first place?
Nope, it's fine. Just go to File and New/Restore and select the options to restore your seed.

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.