Why? Buying and hoarding that much ASICs without using them would be ridiculously expensive and you'll have to outpace the entire network (given stagnant hashrate) as well. It'll make far more sense to control the current 51% of the network and suddenly switch to their own rogue chain. It is far cheaper, or seizing them would be the cheapest. It is far more scary for a sudden percentage of the hashrate to go offline for an extended period of time.

Besides, after that, every SHA256D coins are either worthless or would just fork to something else.

I took a quick look at the node on my server. I'm seeing a few addr messages with less than 10 IPs being sorted into the bucket every few seconds.

Are you periodically retrieving the data from peers.dat or are you using a better method? If it's the former, then I'll parse the peers.dat later on at fixed intervals and see what I can find.

Sarcasm isn't well conveyed through an internet post. Many a times, I thought people were just joking but they in actual fact weren't. I'm really not kidding, just go through a few threads in this board and you'll understand what I mean.

Worst part is, some people would actually take these posts seriously. Better to have some clarity before the spammers come and spam the thread up with nonsensical posts that makes a big hoo-hah out of a joke.

Forum uses cloudflare as well.

It is in effect an MITM with Cloudflare so of course not a great idea. Most (all?) DDOS protection services requires the packets to be routed to them for scrubbing though. Just use the onion address with Tor and you wouldn't have a problem.

Earlier blocks didn't specify addresses for the coinbase rewards. It is definitely unintentional and you shouldn't read too much into it.

It is also the wrong permutation.

Yes. That is a typical double spending attack in theory.

As I've said, the cost of such an attack, or at least the opportunity costs is in the neighbourhood of a few million dollars. Whether the exchange is willing or is able to process such a big transaction without at least some precautions in place isn't guaranteed.

The thread is a covert mining attack with the state adversary against Bitcoin. There is no reason why the state would be remotely interested in the profits; as said, the costs of an extended attack is huge with their attacking chain becoming either abandoned or at least largely unpopular with the community. If you're in it for the profit or attempting to recoup any significant part of it, the fiat exchanged must be at least 400 million dollars, given two weeks and even more because your ASICs are now worthless. China isn't interested in doing that, their GDP is 14 trillion USD, and you don't gain enough from an attack like this. An attack from China cannot possibly be profit motivated. If you're not looking to profit from it, mining alongside the chain for extended periods of time only serves to make the attack much more expensive.

Chinese miners are also not interested in that. They've made tremendous investments in mining, they are going to profit more by being honest.

I think there is a security issue right here. If some of the nodes aren't online at a specific time, then they won't know if the blocks were reorg-ed before. Sybil attacks are also a problem in this case. The potential for a network split in this case is far greater.

I wouldn't put sole control of the private key (or funds) with any single entity, that doesn't provide sufficient redundancy in case of a compromise. Rather, I'll prefer having a Multisig of sorts, or a secret sharing mechanism such that it requires more than one form of authentication to spend the funds. For eg. Putting one of the 2-of-3 multisig with a secure service, and giving one of the key to the trusted party. Either that, or I'll have it written up on my will, the unlocking of a certain safe or secured storage upon my death.

There is no reason why you should entrust any of your keys to any centralized party. Or at the very least, it should be encrypted with the password included in the will. There shouldn't be a scenario where a compromise of the secured service results in the complete loss of security.

Well, that was 2019, nearly 3 years ago. IIRC, the development for epochtalk started quite a while back but has been quite a few years since then. Cobra once mentioned that millions were spent on this; also quite a while back.

I can't find any updates later than that though...

Ensure that your fake email address can't be generated. There was at least one instance where users opted for gmail accounts which were never created and it was displayed publicly. An attacker created the email, reset the account and gained access to it. It'll be far better to generate an email yourself, generate some random passwords and leave it there. If you're not planning to use the email as a way to recover your account.

In Bitcoin, we don't spend funds by looking at the balance on addresses. Instead, we spend inputs and create new ones. Let me show you an example: https://blockchair.com/bitcoin/transaction/c21523ed3745959ce1389f571ec1c46181eb09c10d85301923bf875cfc0fd1b9. The transaction has 3 inputs, by spending them, I've effectively created a single inputto be spent. If I were to replace it with any address that I own, then I would've effectively consolidated it by spending 3 inputs and creating a single one.

If you were to spend 15 inputs in a single transaction to your own address, you'll create a single transaction output for it to be used in the next transaction. The other 10 inputs can then be spent in another transaction to create another inputs. Afterwards, I'll just use the two inputs that I've created through the consolidation into the transaction that I originally wanted to make, but was unable to do so due to the restrictions on the number of inputs.

So, create a transaction that sends back to your own address; Go to View>Tools>Show Coins, then select any inputs, as long as there isn't 20. Go to your Send tab, input an address from your own wallet and press Max. Afterwards, do it as you would for a normal transaction. Upon loading it into ColdCard, you should expect to see a message saying that you're sending it to your own wallet. After both your consolidation transaction gets confirmed, then you can spend it normally, as you've reduced the number of UTXO (unspent transaction outputs) from 25 to 2.

Is there a problem with consolidating the inputs first? Using a few transactions with less than 20 inputs to send back to your own address, and sending the consolidated inputs to your destination.

Deleting the inputs would result in your having less inputs for your transaction, and you need to include them all or else your total amount would be less than you desire.

What's wrong with the ads? They aren't scams, at least. I think the forum should have enough cash but I also don't think they should draw from their reserves primarily. Hosting is already quite expensive by itself and there are other miscellaneous costs as well.
More exposure simply isn't bad. Same can be said for almost all the signature campaigns on the forum, and some are just blatant pump and dumps. There is nothing wrong with advertising for an altcoins, the two that I see aren't as terrible as those that I see in sig campaigns.

That is for the PSBT file. PSBT files includes loads of redundant data and stripping it down helps to reduce the size restricted by the communication bridge.

Try if it'll sign with <20 inputs first. Use Coin control if needed on Electrum. I think fees are fairly low right now; would it be possible for you to send two transactions back to an address in your wallet (1x 12 inputs, 1x 13 inputs) and spend it with ColdCard, the two created inputs from the two transactions?

Miners do not earn 0.001BTC per block for the fees, that is absolutely absurd and should never happen. Currently, miners earn anywhere from 0.1BTC to 1 BTC depending from the network conditions. Average count for the transactions appears to be about 2000 per block (3.3 TPS), so that is far lower than any realistic estimate for any mass adoption or any widely used payment processors, with LN or not. If we were to make optimizations throughout the years and/or make the block size larger, then I don't see a problem with fitting 10x that in a hundred years, maybe even more.

Currently, network throughput for the miners is about ~100EH/s, at it's peak was about 170EH/s. That is quite a large number and shows that even with current block rewards, it is very very far from being remotely profitable for any attackers. Remember, you don't only pay for electricity, you also pay for the ASICs themselves, the landspace, etc. I don't think it's too far of a stretch to assume that by the time block rewards are <1BTC, the fees would supersede it. It should only be a concern if the network becomes insecure *enough* to be attacked, not if the cost of mining can't be matched with the current estimates.

I definitely hope it won't fluctuate forever. Yes, I agree that the point about the fluctuation is completely valid. I'm making a point about having either an increase in the price or the increase in the adoption. Either of which increases the profitability, either by relation to the fees or the profit from mining.

Granted, I do think that I might not be right about a sustained security as there are a ton of factors on that but I don't think that the security (or rather the hashrate) of the network would ever dwindle to dangerous levels. If it ever gets to the point where it is better to be dishonest than to be honest, then that would be a problem because the system fails.

No as in, there is a difference between a coinbase transaction and the coinbase rewards. Why would the coinbase be zero though, then where do the fees go?

LN as of now still settles transactions on-chain so that'll be opening or closing a channel. If there is a still some degree of scarcity with on-chain transactions, then these kinds of settlement transactions will be more expensive but users won't have to pay a great deal of money when you spread it over to the many transactions that the user could've made while on LN.
Coinbase transactions will always exist. They're the only required transaction in a Bitcoin block.

Eh, that's actually the issue.

Coldcard supports 20 inputs to be signed at once[1], presumably due to the fact that it is unable to sign so many due to hardware limitations. I've never encountered this issue, only because I've never had to sign that many inputs but I think that the limitation still applies right now. Since it's mainly a hardware limitation, there isn't anything else that you can do other than to split the transaction up smaller.

[1] https://github.com/Coldcard/firmware/blob/master/docs/limitations.md#max-transaction-size

Please DO NOT download anything that you're unsure of. People often intentionally dangle these kinds of files as a bait. I would avoid downloading them at all costs, even if you're not going to execute them. I'm not sure why people would recommend doing so, you literally can generate one by downloading Bitcoin Core. You don't even need to synchronize it.

I find it quite common, given how people almost always take the advice of "don't use Windows" at it's face value. Your security depends far more on your habits rather than the OS.

Exactly and I can't emphasize it enough. People seem to think that there are no vulnerabilities associated with Linux based distributions. That is completely and utterly wrong. Zero day vulnerabilities has been exploited from time to time; Shellshock on Unix based systems with bash, a whole bunch of distribution specific backdoors as well. The main reason why WannaCry was such a big problem was because it was patched previously but people were either unwilling to update or still using EOL OSes. The most common is still users willingly running it themselves.

I don't disagree that Linux is better than Windows in some aspect but Windows is designed to be KISS and not over complicate certain things. From time to time, you'll see users coming on the forum to seek advice on running certain things on Linux. It is quite obvious that some didn't do their due diligence and are instead relying on websites to teach them how to compile Core, for example without knowing how to resolve simple issues; not having correct Path variables, not having updated dependencies, etc. It's okay if you want to learn how to use Linux, but if you aren't prepared to read up on it in depth and practice simple security habits, then you're just shooting yourself in the foot.

Oh okay, then it's not fabricating transactions.

It doesn't matter except that it slows the propagation of your blocks down by a lot. End result is still the same, fork with a different algorithm and chain. Extended re-orgs are not very common without malicious intent so it wouldn't be difficult to differentiate. If the end result; forcing Bitcoin to change the algorithm and instill fear in the people is the same, whether you just start attacking in real time or release your own alternate chain, then I fail to see what is the difference except the latter is far, far more costly. It's mostly a difference between a few million dollars and a few hundred million dollars, assuming that they don't have to care about the cost of the ASICs nor the space.

There isn't any rules about that, nor would it be implemented realistically. We wouldn't bother to implement any consensus change that doesn't deal with the root of the problem; rather, I believe that invalidating that chain and changing to an algorithm would be the most obvious and direct way to deal with it.

It is an attack that threatens Bitcoin, that is correct. Whether it is viable to do so, is a whole other question.

You can't fabricate transactions.

Truth is, the economic majority probably wouldn't want to continue using a chain which was manipulated by an external party. The only rational way out is to rollback the chain to before the 51% attack and continue mining with a different algorithm. It would be as if the attack has never happened. Announcing prior to the attack would just result in majority of the exchanges halting deposits and I would be surprised if there isn't any mechanism to monitor for extended re-orgs on exchanges, considering how many altcoins are already susceptible to these attacks.

They have no choice. As long as someone else has the capability to build a longer chain with a greater accumulated PoW, everyone will re-org to that chain. If we do discover some malicious intent, then I don't believe it would be a huge issue to just abandon that malicious chain in favour of the honest one.