Yeah I get what you mean. But the NODE_NETWORK_LIMITED doesn't mean that the node is pruned. My node, which has the entire blockchain on disk also signals NODE_NETWORK_LIMITED with 1033 flag, 1024 for being able to serve last 288 blocks, 8 for NODE_WITNESS and 1 for NODE_NETWORK.

So, for a full node with the entire blockchain, it should not only signal NODE_NETWORK_LIMITED but also NODE_NETWORK.

A nifty way to do so is to (prepend) the desired strings[1] as a subdomain to query. For example, nslookup x9.dnsseed.bluematt.me.

This will work if the DNS seeder supports service bits filtering[2].


[1] https://github.com/sipa/bitcoin-seeder/blob/a09d2870d1b7f4dd3c1753bbf4fd0bc3690b7ef9/main.cpp#L165
[2] https://github.com/bitcoin/bitcoin/blob/7cb0bcb6811070786937fb5cc0af82cf4ef21ff0/src/chainparams.cpp#L121

It is not free. Costs are incurred in the areas of R&D, maintenance, labour, etc. These are all costs that has to be offset by the producer and it should be more expensive than current methods. It's more of a cleaner energy than a free energy.

Proof of work will still function fine, you're possibly only (as stated probably not) reducing the costs from consuming the electricity. There are still scarce resources being consumed and incurred, production of ASICs, land, labour. It doesn't diminish any security of PoW based coins, perhaps slightly in the worst case.

State sponsored attacks, assuming 51% attacks has never been limited by the electrical costs or anything in that area. It is possible for countries to attack Bitcoin this way but it really doesn't make any sense right now and I don't expect countries to attempt it in the future either. ASICs required and the opportunity costs of having an attack is far greater than any benefits that they may have.

It is quite hard to prevent any leakage of the connections that you have. Getaddr does have privacy measures but if a person is determined enough, they can still achieve it though with much more difficulty. As I've mentioned in my previous post, without a MITM, it would be fairly hard for an adversary to execute a sybil attack that affects the security to that extent. Something like this would require a (relatively large) amount of resources with different IP ranges, and a huge number of nodes it to be even possible, not regarding the feasibility.

Having a secret or a trusted node can be a solution but it is definitely not necessary or doable for most, unless the final node that you're connecting to is definitely not getting sybil'ed, then you're safe. If it isn't then you're just wasting your resources. The counter against such attacks is the cost and the features of Bitcoin Core.

Connections between nodes are not encrypted. Packets can be dropped by the adversary and there is simply no way to detect something like this happening if the attacker can intercept the packets.

Not exactly. It does nothing if the attacker is actively listening to your connections, ie. a public wifi of some sorts. I'm not sure if this is the case but it wouldn't work if Bitcoin Core will tell the peers about the nodes you know about upon receiving a getaddr message. Trying to connect through another type of network or using some form of secure communication would reduce the chances of a successful MITM.

Implementing anchors.dat does help with the situation somewhat by mitigating the possibility of eclipse attack.

These attack should probably work better with MITM attacks and the attacker can possibly restrict the peers that they can connect to. It is usually quite targeted and specific as well, instead of it being a general attack as that'll be quite impractical given both the financial limitation as well as Bitcoin Core's node connection policy (IIRC it restricts the number of connections to each subnets). A single connection to a non-attacker controlled node will render this attack ineffective as well.

Both of them are possible but the scope of the attack is quite limited as well and doesn't make much sense financially.

No they cannot.

The nodes can do whatever they want, accepting invalid transactions, accepting blocks with thousands of block regards, etc. However, as you've mentioned, nodes enforces the rules themselves. No matter how many nodes an attacker controls, the set of rules that each node enforces cannot be changed. They will not accept any invalid blocks, transactions, messages, etc and they will be kicked after hitting the ban limit for the nodes.

The miners also cannot dictate the rules directly nor can they violate any rules if they want it to be accepted by the nodes.

Have a general sensing on the local laws first. If the jurisdiction that you're visiting explicitly bans cryptocurrency and/or deems any activities related to it as being illegal, I would advice you to err on the side of caution and leave it at home. Especially if you're a person of interest, something like this is probably an excuse that they can use. Might just be unnecessary paranoia but I personally wouldn't leave it to chances.

Hardware wallets are not completely safe from physical attacks as well, exposing it unnecessary like this would bring about a huge risk.

Probably. $100 is still quite little even with 10sat/byte.

ViaBTC requires at least 10sat/byte.

Depends actually. Some wallet do not remove or give their user an option to remove the transaction even when it gets dropped from most node's mempool. Could be a problem if this is the case.

At 20sat/vbyte, you'll be looking to pay at least $300-$400 in fees. If anyone is willing to confirm it for less than that, they're likely trying to scam you.

What wallet did you use for this? You can probably attempt to make another transaction which spends a higher fee if it gets dropped.

The capacity of Bitcoin is limited; 1vMB per block. People would be able to choose the fees; paying more if they need a fast confirmation and less if they're willing to wait.

Allowing the user choose their fees allows the fee market to function where people would pay more (in terms of fee rates) for miners to include their transaction in a block. Having fixed fees wouldn't be beneficial at all, people would be able to spam the network at a lower cost as the cost of spamming it remains approximately constant as opposed to the current structure where the attacker has to compete with the rest of the network as well. Miners would also have no preference over most of the transactions as the fee rates are the same, some users could be waiting ages for a confirmation even if they are willing to pay more for it to be confirmed.

The conditions for it to be conducive for Bitcoin mining is not only the electrical prices but also the general environment as well; labour costs, cost to ship the ASICs, etc. As such, it doesn't mean that Bitcoin miners necessarily flock to places where electricity rates are low due to it being produced in excess. Most places do not produce sufficient energy for the entire region and requires a few fossil fuel plants to supplement them. While Bitcoin mining can help subsidize the development of renewable energy, I'd say that Bitcoin miners still consume electricity that could've otherwise been used to supplement another region.

It doesn't have to be. The block retarget aims to keep the blocks at a 10 minutes intervals but will in no way ensure that they're at least 10 minutes apart due to varience.

To answer your question, which I don't think the posts above actually addressed. I'll define parent transaction as the transaction which sent the coins to your address and the child transaction being the outgoing transaction. Your parent transaction doesn't have to be confirmed for you to be able to spend it. You can create a valid transaction by referencing the hash of the parent transaction and broadcast it, even if it isn't in a block yet. This also means that for the nodes to accept or see your child transaction, your parent transaction has to be in the mempool and if there is sufficient propagation, it should be nearly instantaneous. In the rare case that the parent doesn't get propagated well enough, nodes would likely keep it as an orphaned transaction without including it in the mempool as they cannot find the parent transaction. However, it is important to note that the child transaction can only be confirmed provided that the parent transaction is also confirmed.

There are cases where you won't see a transaction until it gets confirmed. People can directly contact miners which are capable of mining a block to include their transaction without relaying on the network. As such, the first time that the majority of the nodes see the transaction is also the exact time that the block from that specific miner gets mined and relayed. This makes it seems like the transaction was instantaneous but it is in fact not the case. Miners can include any transaction that they want as long as it is valid.

Unless Blockchain.com changed their wallet recently, I don't think they have opt-in RBF at all.

Go to Blockchair.com, search up your transaction IDs and check if the Replace By Fee is opted in. If not, then CPFP would be your only choice.

Yup. I understood that.

Probably lesser. Most of them are P2PKH which has no issues at all.

It will permanently affect Bitcoin. By deeming those stolen coins as valid, the circulation of the coins would be increased quite substantially (I think Satoshi has at least 1 mil and there are some other early holders as well). If you want to stop it from affecting the market, you'll have to censor it which raises a whole lot of other questions. It would completely destroy Bitcoin; how can Bitcoin be deemed as a safe asset (secured by math ) by anyone if the community is unwilling to implement** the draconian policies that ensures the security of it?

** I don't foresee it happening but rather it'll be two different forks with one vulnerable and the other isn't. It'll be interesting to see who would support the respective forks though.

Probably not. Addresses are scripted in a way that relies on the ECDSA signature and ECDSA signature will be vulnerable if such a powerful QC gets developed.

Making millions of Bitcoins remain vulnerable is an economic risk. Your whole economic functions within Bitcoin will fail catastrophically given that hypothetical scenario and make Bitcoin absolutely worthless. Keep in mind that the millions of Bitcoins are likely to have been in control by Satoshi and there is little to no chance that he'll come back and do anything. Unfortunately, for the betterment of the community, you have to impose drastic changes.

Then unfortunately, I believe most of the Bitcoin users believes that in order for Bitcoin to survive, you have to make certain hard choices. Of course, given Bitcoin's nature, you don't have to do so. Just make a fork to invalidate any ECDSA signatures and have another fork which still uses that standard. It is a choice that is left up to the user, if they believe in not burning those funds, then you can use the fork but also bear the blunt of the impact if anything happens to the ecosystem.

Its quite obvious that there will be two sides of the camp when met with such a scenario. But it is really not a partisan issue; if an attacker gets his hands on those Bitcoins, then you have to face the choice to either block it through a fork or let them liquidate it and possibly crash the value of Bitcoin as well. It's not quite like a block size debate where both scenario would pan out just fine and to me, not making the drastic measure (if there isn't any other solution) isn't the correct choice.

The maximum block size of 1MB was only enforced in 2010 onwards. Prior to that, Bitcoin had a different block size limit (32MB?).

Yes. They share the blocks on disk and also relay transactions. Doesn't hurt for them to be accepting incoming connections.
Depends on reorg depth. You cannot reorg beyond the pruned limit and I believe Bitcoin Core will just throw an error in that case.

---

If Satoshi did the calculations, you bet that there would be the calculations somewhere. Even in 2009, the time it takes for any computer to validate a single block should not come close to 10 minutes at all nor was the internet connection that bad. The way the nodes connects to each other should also result in the propagation to be taking much less than 10 minutes. There is obviously quite a significant room for error in this case and I'm sure that Satoshi just chose it as an arbitrary number.

Changes are not always abrupt and if they are, then it has to be for a serious issue. There would usually be quite a period of time before any significant changes to the protocol and probably would give enough time for people to move their coins.

A thought experiment, if quantum computers becomes (practically and economically) feasible enough to attack the exposed public keys, wouldn't it be better to force people to discard ECDSA keys in favour of a quantum resistant algorithm? If the network doesn't adopt drastic measures, then I would assume that there is a significant chance of funds getting stolen, especially the millions from the already exposed addresses and removing those kinds of keys would be better for the community.

Both Bech32 and legacy uses RIPEMD160 and SHA256. Even if these were broken, there is little incentive to deprecate these as you'll only be able to get the public key by breaking these. I could see a point in deprecating either if a collision occurs with either of the address type which is quite unlikely.

In the far future, we could possibly deprecate ECDSA as a signature algorithm if it becomes insecure and cheap enough to attack. Probably would be given enough time to shift to a new algorithm before that happens. This affects all PK algorithm (legacy/Segwit).

No. The bitcoin.conf is stored in your data directory. It should be in the same folder with your mempool.dat, peers.dat,anchors.dat etc. This requires a restart of your Bitcoind.

Alternatively, start bitcoind with -dbcache=2048.