How are you going to build and lengthen the blockchain without any miners?

If you are talking about switching to POS, it (probably) won't happen. The difficulty helps to balance it out, as the profit margin decreases, mining would be left to those with cheap electricity (probably hydro or other renewable sources) and efficient hardware. Not like electrical usage is really as much of a concern as the media makes it out to be.

The USB?

Using a QR code might be better for this, it's like a one-way communication and would give a true airgap setup. I think there is some limits to the size of the transaction, but that shouldn't be of a concern. If it gets too large, then you can just use multiple QR codes to stitch it together or use a different encoding. Electrum uses base43.

It's a blanket statement to dismiss it as untrue. Bitcoin does have its merits as a decentralized network but there's obviously a lot of work to be done. A 51% attack is not the focus of the project but to explore the other possible vulnerabilities regarding the protocol itself. Mining will never decentralized, at its current stage. Barring the Chinese government banning Bitcoin mining completely, it is impossible for them to not hold a majority of it; most ASIC manufacturers are based in China and the cost of mining is probably much lower there as well.

Obviously 51% attack is not economically viable if you were to just own the hardware and operate the ASICs yourself. The article doesn't dispute that but rather it was calling for a monitor *in the event* that it happens, which is completely rational. Bitcoin being open source doesn't mean that it won't have any vulnerabilities which I presume is what this is set up for. I don't think any of the statements mentioned in the article are unfounded, might be getting a bit offtopic with your replies here.

What? Bitcoin functions on the economics of game theory to ensure that 51% attacks are infeasible.

---

I can't really see anything bad that could affect Bitcoin. At best, they could contribute actively to Bitcoin development and at worst nothing happens. As for the 51% monitor (or rather double spend/forks), here it is: https://forkmonitor.info/nodes/btc.

As we have explained in the previous thread, miners are not entities that can be regulated on a protocol level. There is no reason why you should partition them into groups; they are solely the ones finding blocks with sufficient PoW and building the blockchain. Schemes like that would overhaul the entire Bitcoin and it would be better for anything like that to be implemented on an altcoin instead, though I don't really understand how that would differ from a traditional bank.

You could try to understand how Bitcoin actually works first before suggesting ideas. It would be far easier and more conducive for discussions that way.

#47 - ranochigo

Thanks!

So for the checkpoints within Electrum, they wouldn't do anything to protect against a sybil attack? My impression is that it makes attacks more costly as the difficulty of a block has to be much higher. If they are able to generate a block, then it could be a better idea to just mine legitimately?

No. I synchronized it on my computer with a fairly powerful processor with 6 GB of dbcache and it took about ~8ish hours. It was a stark comparison than when I was synchronizing it with my HDD which took almost a day under similar conditions.

In contrast, I'm running a node on my Intel Atom C2350 server, which is pretty weak in comparison and it took about 5 days with default settings. I don't think most users would want to run a full node if that is their hardware specifications; it'll just be a pain. A tip that I'd give is to increase the dbcache to push more of the data into the ram so that it can be accessed readily while the client goes through IBD.

Most users don't have to use full nodes if all they want is to send some Bitcoins. Full nodes will be better for users but it is not necessary for most. Obviously a tradeoff would be with the privacy and to a certain extent it's security as well.
Data storage and it's density are getting better throughout the years. I don't think it's necessary for everyone to be downloading a full node just to use Bitcoin. It can be downloaded while you're doing other things with your computers as well.
There has been a series of past changes to Bitcoin Core that has managed to speedup the synchronization exponentially[1]. I don't think I've seen a more recent version of this but there has certainly been much more optimization in the more recent versions.

[1] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/

That assumes that SPV clients do not consider any pre-defined hardcoded checkpoints within the client which would result in the subsequent blocks still being equally difficult or somewhere in that region to be mined. Isolating someone from the actual network is easy if the attacker and have a MITM attack with the client not implementing any redundancies in the process, ie. SSL connection to the servers in the case of Electrum. SPV clients are intrinsically less secure but attacks won't be as easy as that.

---

51% attacks is a guaranteed success but it doesn't mean that the attacker requires 51% of the hashrate to be able to have any chance to reverse TXes with only a few confirmations. See selfish mining.

The way the difficulty works should be the same as well. If it's empty, the merkle root is the TXID of coinbase so there is really no difference in the difficulty whether you are mining empty blocks or not. You could use covert ASICboost and mine empty blocks but that probably wouldn't make sense economically.

I see that you understand that the distribution of the block intervals follows an exponential function and that the probability of a block being 1 second from each other is 0.167%. The problem with this is that there is no perfect information when you're looking at block intervals. Propagation of the transaction across the network takes some time (depending on how well your node is connected). The only metric that is remotely usable is the timestamp that the block is received by the node which is subjected to the delay as above.

It would be a stretch to assume that all of the blocks are mined within 1 second of each other. It's much faster to just take just the hash of the block header on the other pool than waiting for it to be relayed through the network.

Bitcoin Core still has getblocktemplate's RPC functional. It should still be able to be used as a node for solomining.

How much fees did you pay? You should be looking at about 30 to 40 satoshis/byte for it to be confirmed within a reasonable period of time. You can try to right click and see if you're able to bump fee to get a replacement transaction sent with a higher fee.

It's pretty obvious that nothing is absolutely safe and not everyone can get a new computer specifically just for a specific use. Using a LiveCD would be fairly secure in the sense that only persistent rootkits would be able to infect it. It's more of a middle ground for OP.

Chrome is better than Firefox in terms of it's malware protection due to it's design. Anonymity should not be an issue here; OP is asking for security advice, nothing about privacy. If privacy is your concern, you should be looking at a browser that is privacy oriented, ie. Tor, Brave. Firefox is not designed for privacy without any specific modifications.

Privilege escalation attacks are not uncommon in malware and I would certainly always assume the worst case scenario with this.

---

Using them for suspicious website alone wouldn't probably infect you with malware if you're using a browser like Chrome. It has a sandbox that should reduce the risk factor.

Anyhow, unless you are able to separate your browsing activities from crypto, I can't see anything that would be foolproof. You can either use a LiveUSB for those or a different computer completely.

Yes, if the blocks are relayed at almost the same time.
Miners usually have to download and validate the entire block before continuing to the next block. Certain pools would connect to each other with zombie users to attempt to get the block headers ASAP, without downloading and validating the blocks. This was the case back in 2015, but the efficiency of block relaying has improved so much that it really isn't that necessary.

I'd say that there's really nothing to lose for the miners. It would be worth if the relaying and validation takes a few seconds; if you were to wait and assemble a new set of merkle roots in the meantime, the time inbetween is still wasted. The only caveat being that it isn't fully validated before the pool starts on the new block; resulting in 2015 Bitcoin fork fiasco.

Looks like it's listening to peers through Tor so you would have to disable Bitcoin Core from using Tor at all, not just connecting to clearnet only.

Try listenonion=0?

To determine whether a transaction originates from a specific node with absolute certainty, the nodes would have to be connected exclusively to you or have a MITM attack in place to capture the packets. Bitcoin Core does try to prevent this by limiting the connections to each block of IP, since attackers can easily purchase IPs in the same block relatively inexpensively.

---

There were concerns about deanonymizing attacks on Bitcoin nodes operated on Tor but that is fairly old and easily mitigated by connecting only to onion nodes. If you were to allow incoming connections, ensure that Bitcoin Core is binded to your Tor instance and not your clearnet IP. Bitcoin Core is pretty good at ensuring privacy (barring user behaviors and onchain linking), there is a randomized delay with inv messages which helps to make it harder for people to determine if the transaction originates from your node.

Hmm. Seems like Electrum was using a different serialization format since many releases ago.

I'm unfortunately out of ideas now. Don't think Electrum 3.0.6 is able to connect to any peers now. The only risk is the phishing message since the unprotected RPC was fixed the version prior. Perhaps some other members can chime in to help.

With only a throughput of 7tps (varies depending on segwit usage assumptions), it definitely sound like a limitation. Nevermind 2nd layer solutions, we're talking about onchain transactions.

I'm not sure what you mean by the statement by the way. Difficulty is a function of the average time difference between each block.

Does it start with a 3 or 1? Those are case sensitive.

Bech32 is not case sensitive and should either have all of it's letter in uppercase or lowercase.