I wouldn't be surprised if normal operators are unknowingly assisting them with the spying.

Problem with any service that you're going to use is that there is absolutely no way to ensure that they're not collecting logs. Any VPNs or service that promises "no logging" shouldn't mean that your privacy is guaranteed. The fact that it isn't that difficult to start logging, either with the knowledge of the provider or not is a dealbreaker. Always assume that you are getting logged, unless you can verify that your contents are being encrypted in a way that makes it difficult to do so.

Protonmail specifically stated that they are legally obliged to comply with certain requests, which are nothing out of the ordinary. If anything, I'm supportive of them doing so given that the requests are made on that basis that doesn't infringe on human rights. They've mounted several legal challenges against a few requests, IIRC.

The fee market is determined by the supply and demand. You should look at the fee rates instead of the absolute fees, as the fees are affected by the size of your transaction.

If you're talking about the fee rates in Bitcoin, then the fee has mostly been unchanged. The mempool is quite empty right now and you should get a confirmation within a reasonable timeframe with 1 sat/vbyte and it is basically the same as when Bitcoin was normal.

TDPs of CPUs are mostly within quite a fixed range. 7nm Zen 3 are more efficient than 7nm Zen 2 and 12nm Zen +. As we're getting to smaller node size, architectures are more efficient (performance to power ratio). In fact, all of the criteria that you've listed all hold true. CPUs are cheaper relative to their performance, better performance and basically the same power consumption. Saying that chips are not improving over time is just untrue.


I certainly hope that you're not trolling but it feels like I'm talking to a wall at this point in time.

Big blocks encourage centralization, by making is far less practical for users to run nodes and relying on SPV or centralized servers instead. Excessively big blocks makes the network less secure, where users are seeing their own versions of the chain. With on-chain scaling, you are still limited to many factors that governs it, be it transaction finality due to the stale rates or just the block intervals. By introducing excessively big blocks, you are scaling Bitcoin by solving something and sacrificing the practicality of it.

I believe that we've made our point with the many pages of discussions. I would encourage you to at least consider the posts and DYOR. It is not a constructive discussion if you were to be so insistent on your views and refusing to acknowledge the facts.

Running a full node without inbound connections already means that you're relaying blocks and transactions.
Core by default already listens to that port. If you're behind any firewall, then you have to configure it yourself.
Not really. It is only a risk if there is an exploit within whichever application that is listening on the portforwarded port and accepts malicious commands. That is unlikely to happen.

The nature of Bitcoin allows for easier collection of funds when involved in ransomware attacks, that is an undeniable fact. Actively banning Bitcoin or otherwise imposing sanctions on an exchange does not solve the problem. It is merely an attempt at trying to show people that they're doing something. Fraudsters are always going to mix their funds and use P2P methods to exchange the funds and people would be none the wiser. OFAC is quite a useless list and doesn't do anything to tackle the problem.

No, you're comparing apples to oranges. In a similar architecture, yes a higher clock speed results in a better performance, simply by the logic of having similar IPCs. The point here is, if you are comparing a 6GHz Core 2 Quad from those days and a 2GHz i5 from today, the i5 wins, hands down simply by the architectural improvement. We are not pursuing higher clock speeds, only better IPCs. Your argument is that the we expected CPUs to be running at higher clock speeds over time, which is untrue. In this thread, we are talking about the increment in the performance of the chips, which is proven true for the past few years.

It isn't difficult to achieve higher clock speeds, if you design a CPU specifically just for it but it won't be efficient.

Inventing is not something that I would agree with. Bitcoin SV and Bitcoin are practically the same, save for a few parameter changes.

Again, Apples to Orange comparison. Bitcoin SV has 157 nodes[1], while Bitcoin has 8200 nodes[2]. It doesn't seem to be a problem because those who are using it are obviously supporters of it. You don't have to consider the actual feasibility, which lies in quite a few aspects (block propagation time, block processing time, storage limitation, etc) if you think that is the way a crypto is supposed to function. Bigger blocks are possible, excessively big blocks are possible as well, but there are quite a few drawbacks in the latter.

[1] https://blockchair.com/bitcoin-sv/nodes
[2] https://blockchair.com/bitcoin/nodes

Hmm, okay I misunderstood what you meant. By not considering those UTXOs, it can be a soft fork because the majority always prevails. Unless there is a divergence between them, for which there would be a messy situation.

I don't agree with the proposal. UTXO size is not a concern for us, not to the extent that would make us resort to draconian measures to intentionally censor and invalidate certain UTXOs. It isn't difficult to store the entire UTXO within your ram, and it certainly isn't impossible to have dynamic caching of it through your ram as well.

If I earn $1000 from my fees and the storage costs $10 per month, I probably wouldn't complain either.
Do you know what pools are?

For what it's worth, that was never the case. No one cares about the clock speed, because that is irrelevant to CPU processing speed. Moore's law is about the transistor density on chips which has been true for quite a while, and even in the recent generations of CPU, the instructions per clock has advanced far greater than that of the CPU of those days.

Just to address some of the points raised in the thread. As I've said, the point about not invalidating/deleting UTXO has to do with the ethical and practical concerns, where limits have to be arbitrarily defined and that will never happen. Truncating Bitcoin in that sense is NOT impossible, in case you've misunderstood me. It is totally possible, but you're going to be assuming that the pre-defined checkpoint is valid. As of now, it is not an issue because we don't have that sort of problem yet, nor do people want to hassle with it to solve an issue that might never really be one.

I'm not sure why Craig Wright is really in this conversation at all. He was NEVER proven to be Satoshi and the list of addresses he provided turned out to be someone else's[1]. A PhD in Computer Science isn't really that uncommon, and it really does nothing to show their honesty or moral compass. Signature validation are fairly expensive, if you were to actually look it up and compare it with an average computer running a Bitcoin node.


[1] https://web.archive.org/web/20200525113441/https://paste.debian.net/plain/1148565

Hard fork.

This is not an exploit. It is possible to mine empty blocks and that is completely normal. In fact, miners on Bitcoin can very well just start mining only empty blocks and the only expense would be the loss from collection of the TX fees.

Empty blocks are not necessarily an exploit at all, but selfish mining can be a problem. That would be a scenario where miners are intentionally withholding their chain to gain an advantage but empty blocks are not characteristic of that. Nothing should be done into it, or to enforce non-empty blocks for that matter.

They are referring to Electrum servers.

I would probably just run it either over clear-net or through Tor but not both because then the privacy benefits would be diminished. Running it through Tor should probably benefit you primarily through eliminating the risk of your ISP having MITM through your traffic. It wouldn't be so much as to the analysis through the nodes that you're connected to, though Tor does still provide certain degree of protection from that.
Linking addresses probably isn't ideal. Using a separate Tor identity for every single one of your addresses and transactions would be advisable.

It depends. As I explained before, the point behind this would be to look at the transaction that would be included in a block in the chain first. If the transaction that gets included first is your transaction, there is nothing a hacker can do, and vice versa. What a non-RBF transaction basically means is that nodes will not relay transactions that spends an inputs of another, without the opt-in RBF flag. In layman's term, miners are probably not going to see it.

Of course, there exists certain circumstances which this wouldn't be true. If a miner has seen that transaction and agreed to include it in their block, they can do so provided that your transaction hasn't been confirmed yet. There has been cases whereby miners have included transactions with a lower fee or non-RBF replacement transactions. They are few and far between though.

Tl;dr: Yes, it is possible albeit more difficult.

Yes. Transactions can be replaced until they get into a block, for which the difficulty of it increases exponentially. It is far easier for someone to RBF a transaction with opt-in RBF flag, but it doesn't mean that the transaction without the flag would be safe. Miners can (un)intentionally include a separate transaction from the one that you expect to confirm.

That being said, most of the time, you would either need the participation of the miner before the transaction gets into a block. Sending a replacement which spends at least one of the inputs of another non-RBF transaction that hasn't confirmed yet would result in a poor propagation, and a smaller chance for a miner to see and include it into their block.

Electrum is not designed for privacy, it is just a Bitcoin wallet. If you are aware of the privacy trade-offs for Electrum, then there is nothing wrong with using it. At no point in time did people think that their privacy is preserved simply by using Electrum alone.

If you really care about privacy, you wouldn't use Electrum in the first place. Samourai and Wasabi wallet both offers far superior privacy as compared to Electrum and are SPV wallets as well.

If you get fooled by a YouTube video, then I really wouldn't bother with it. They target the most gullible of the population and unfortunately you're a victim of it. If it sounds too good to be true, then it is. There is no such thing as free money in the world.

Again, I need to reiterate. Bitcoin is NOT flawed. It is not Bitcoin's fault that people fall for simple scams like these. You are responsible for your own funds and no one should have the ability to reverse their transactions. You are supposed to be double checking your addresses to ensure you're not sending to the wrong address. You can't eliminate human stupidity, no matter how much you do. If you need someone to be babysitting you, then you probably shouldn't use Bitcoin and should just stick with PayPal.

Probably the same logic as a nigerian prince scam, it has been around for decades yet people still fall for it.

If you need a platform that has a mediator, you should use PayPal or just your typical fiat banks. Bitcoin leaves the decision making to their own users and they have to do their own due diligence before making any transaction. Nothing would change if we impose a mandatory delay, and nothing would change if transactions were to be reversible. People are still going to get scammed regardless.

The site doesn't work at all, only that page is showing up. Any other individual pages cannot be loaded, only the page with the doubler message is working.

Hmm, guess that is considered a delay, though my take is that it is no different from the user just refraining from broadcasting the transaction for a few more minutes. The intention of nlocktime is not for the user to be able to decide whether to send the transaction or not. The decision should've been made at the point of signing, not after.

The onus is on you to take proper precautions to not get scammed. Bitcoin is not a currency which has a built-in delay or any reversibility. There is no point with introducing something that affects transaction finality. People are going to get scammed and people are bound to make mistake, no matter how much delay we can insert. Reversibility is out of the question, because there is no central authority that should govern what is reversible and what isn't.

Miners don't complain because they don't have to run a full node. Only pools do and they are compensated by their pool fees. The block size doesn't matter to them, because it means nothing when someone else is paying for it. In the grand scheme of things, actually 0.84EH isn't a lot. When you're trying to prove that 1GB blocks are feasible, it costs nothing to pad your blocks up with transactions of little value and make people think that large blocks are ideal.

Just because I can create an altcoin that pumps 10GB blocks per 10 minutes, doesn't mean that it would be the practical for an actual coin.

That is not why. The criminal networks around the world uses fiat as their primary currency, that is why you see so many incidents of major banks having money laundering schemes slip under their nose.

The government doesn't care what crimes are committed using Bitcoin. They don't want to adopt Bitcoin, period. It threatens their dominance using the fiat for which they have so much control over, why would they let go of it? Trust me, governments are not deterred from adopting Bitcoin because of a few small crimes. You don't see governments shutting down banks for laundering so much money, but the fine that is given is just a slap on the wrist.