Yes.

Probably no. I'd expect him to be extremely cautious with his privacy. Tails didn't exist in 2008, but he must have had different user in his computer for this kind of activity. For example, anything related with the "Satoshi" identity would occur there. Coding, forum posting, emails, domain name registration etc.

None of our business, though.

It is true that the rest of the mining pools can trivially notice that the attacker is trying to make them run late, and ignore validating his block deliberately, because it's not worth the effort  / risk. Currently, no mining pool software does that, but it might be updated if there's need to.

Sounds like a bad strategy regardless. If it's mined on top of the attacker's block, then it depends on the attacker's block validity (trusting instead of verifying). If it ignores attacker's block, and mines at the same height, then there's no reason not to include highest paying transactions, since it competes with the attacker.

Would this megabyte type of transaction be propagated normally? I think it is non-standard.

Also, vjudeu, I'd appreciate if you could spare your two cents on the previous block size debate. Bigger block size arguments doesn't sound like that bad (anymore). This kind of attack is what still discourages the arbitrary block size increase, in my mind (apart from political conflicts which will, without doubt, arise). I think you support small block size, because I'd read you in the bitcoin-dev mailing list, and you're all small blockers there, IIRC.

I highly respect the endless hours you've spent, discussing on that mailing list. I think you can enlighten us.  

That's the attack I was looking for but couldn't find. Thanks, garlonicon! As I understand it, this attack requires dedicating a little less than 1 MB of block space to execute. Currently, it is very expensive, but if the block size limit is 16 MB, a mining pool attacker could always fill a quarter of their block with these transactions. This would force the rest of the network to spend more than 12 minutes verifying them, effectively giving the attacker 12 minutes to mine alone.

Is that perhaps one of the best arguments in favor of a small block size? I see that it can practically only be resolved if we start implementing even more severe exclusions in the Script, but I'm not sure if it could be trivially resolved otherwise.

Does that mean there are default round parameters hardcoded in the client?

Theoretically, it would might be recommended to avoid them, but practically, there is no internal function within the client that would let me know they're running rounds in parallel, AFAIU. That's something I need to manually check. For example, I need to notice that my coins belong to different coinjoins. Isn't that correct?

Miners is another obstacle I completely overlooked. By rising the block size to 16 MB, you need to convince them that this will be more beneficial for their pockets, which is very debatable. At the moment, a simple wave of Ordinals can rise their block fees income by 100%.

You need to convince them that on-chain transaction volume will eventually increase by orders of magnitude compared to before, but none of us can responsibly make that promise. No one can be held accountable for the potential shortcomings.

Can I verify everything you've presented in this thread in Wasabi client? I'm curious. For example, I had used Wasabi when reviewing it, and I don't remember it allowed me to choose my own round.

No matter how many times he repeats it, running a coordinator in the right way, isn't simple to do. To have coinjoin participants, you need liquidity, otherwise you're not attractive. It's like being a maker in Joinmarket, but takers need to manually type your URI.

Second prediction: $67,600

Second prediction: $67,005

But, why? It'd be boring and very limited. I can think of Satoshi introducing Script as a way to tell the public that "this is more about peer-to-peer transactions", or "play with it, you may think of something smarter than I have".

It would be better if I quoted him directly:

He really had put the effort to create Bitcoin the right way. 

I imagine a decentralized sidechain to issue tokens which are pegged 1:1 with bitcoin. This sounds pretty much like lightning, with the important difference that the tokens are not transferred off-chain.

Why is price increasing an argument in favor of the democrats? Bitcoin price also increased when Trump was president, even more than 500%. Does that make republicans "good" for Bitcoin? And since when the US is the sole arbitrator of the price?

This barely has anything to do with democrats. BlackRock saw the opportunity for an ETF, and it got it issued. It could have happened under Trump's presidency.

I'm not suggesting that republicans will be any better, but there's clearly a hostility. They have tried passing laws that attack Bitcoin like the ones which discriminate based on self-custody or usage of privacy enhancing tools. They have been funding blockchain surveillance companies using taxpayer's money etc. These policies are against Bitcoin, if I had to call them somehow.

That was a softfork. When you invalidate a currently valid rule, it's a softfork, and in this case, you invalidate blocks with size > 1 MB. However, a few years after this, a hardfork emerged.

Any decision taken by Satoshi was unquestionably followed, because... it was Satoshi. It's good that we don't have that source of influence anymore.

It still is surrounded by loads of controversy. First things first, what's the ideal block size increase? We're agreeing on the 16 MB limit, but stompix wants it to double on every halving. Another one might think 16 MB is still very small. I can already predict that the hardfork will end up just like Bitcoin Cash; uncertainty on the ideal adjustment will encourage people to stick with the tested, conservative 4 MB.

I want to remind you, at this point, that before Bitcoin Cash, there were Bitcoin developers who supported big blocks. The fact that they split a long time ago highlights how unlikely it is for the current small block developers to suddenly change their minds.

We should always fight against online scams, and scammers should be punished. However, arresting them depends on their own mistakes. If the scammer knows what they are doing and properly uses the available privacy-enhancing tools, I highly doubt there is any point in spending time trying to catch them.

Picture this: A scammer uploads a compromised version of Electrum on GitHub and directs gullible newbies to it as a phishing attempt. He can use Tor to create the repository and then exchange his stolen bitcoin for XMR. There's absolutely nothing that can be done to catch him.

<local board invasion>

I don't speak Italian, but I can sense the competitive instincts in your veins. Good luck you all!

Old smartphones barely have 100 GB in storage. If your goal is to help the network in terms of bandwidth, it's required to store and transfer the entire blockchain, which is far bigger in size than that.

There is no point in doing that, though, unless the smartphone owner wants to run a node for personal gain (privacy and security of their funds), and is incapable of running one in a PC. Installing and running Bitcoin Core on your smartphone is not easy to setup, and questionably secure.

There are over 50,000 nodes running. The network is pretty good in terms of bandwidth, already.

I agree, this is beyond insanity. It's like asking from a 9-year old to propose a piece of legislation that will prevent money laundering. It's clear that they're not trying to ban it anymore. They want to take advantage of it, by illegalizing any sort of privacy enhancement the user can get. It's like trying to turn Bitcoin into a CBDC.

Haven't they passed such law in the US already? I remember reading about "unhosted wallets" being considered illicit until proven otherwise.

My bad. I must have counted the time it takes for a Raspberry Pi to do it, and I ignored batch verification, or other techniques Bitcoin Core implements to increase efficiency. I just multiplied the average total transactions times the time it takes to verify just one ECDSA signature. However, I do believe certain transaction types take more time to verify than typical, which can be used as an attack vector. I'll get back to it when I find the data to back this claim.

For the sake of the discussion, let's assume that the 16 MB limit is a harmless one. How do we enforce it in a softfork way? Segwit was enforced in a clever way, by separating the witness data from the transaction data. AFAIK, it's impossible to achieve it in softfork, unless you've figured out of another way to restructure the transaction data.

"Why shouldn't this be done in a hardfork way?". It's already history, called "Bitcoin Cash". There is no point in redoing the same thing.

$67,800

$67,950

Time: 9'
BC.Game ID: 35021766

No, he knows very well what's going on. He's just probably financially associated with Wasabi, and desperately needs to protect it. This explains his mania to direct people to Wasabi on nearly every post of his, or the diplomatic responses on zkSNACKs using coinjoin fees to fund a surveillance firm. He hesitated even commenting on that decision, even though WabiSabi is open-source and not strictly related with zkSNACKs.

However, I think he's right about the Sybil resistance. If you truly register each input with a separate Tor identity, then it's easy for the client to detect that the coordinator is Sybil attacking. I'm not totally sure, but confident enough. And I'm not sure the Wasabi client checks for all these things, but in theory, it is Sybil resistant.

The only thing I find difficulty understanding is when listening for round updates. For example, can't the coordinator initiate different rounds in which they continuously use their inputs and only few of the registered inputs each time? For example:

- Alice registers 10 inputs.
- Bob registers 2 inputs.
- Charlie registers 3 inputs.

David (the coordinator) receives 15 inputs that want to be coinjoined. He initiates 15 coinjoins, each of which contains 14 of his inputs and one of the 15 of the registered inputs, resulting in de-anonymization. Why can't this occur?