[tal8d]

When you blow up the transaction limit you physically centralize the verification process. This is why you'd see miners gamble with sitting on a solved block and secretly beginning the next search, with a few seconds of head start, before announcing to the network, or skipping the inclusion of any transactions: because fractions of a second make a big difference. Bigger blocks propagate more slowly, and magnify the advantage of employing those kinds of undesirable behaviors. This is why HFT boxes end up as physically close to Wall Street as possible. This is also why bcash got so much early support from Chinese miners.

[CryptoPunk]

>>When you blow up the transaction limit you physically centralize the verification process.

You could 500X the transaction throughput and running a full node would only require a 25 Mbps internet connection.

>>Bigger blocks propagate more slowly, and magnify the advantage of employing those kinds of undesirable behaviors.

Miners do not propagate blocks all at once. They use propagation protocols like compact blocks to only propagate the transactions not already in other nodes' mempools: https://ieeexplore.ieee.org/abstract/document/8922597

The transactions fill the mempool over the course of the entire on average 10 minute duration between blocks, meaning that by the time a block is discovered, other nodes already have almost all of the transactions in that block.

The 'validation free mining until the new block is fully propagated and validated' strategy further mitigates the competitive disadvantage miners face when receiving large blocks from other miners.

All-in-all, centralization concerns do not justify preventing Bitcoin blocks from growing to meet market demand up until they reach at least 500 MB (ie. 3.3 MB/s of transaction throughput). The current 1 MB - or 1.6 MB assuming full SegWit adoption - limit, which only allows for 2 KB/s of transaction throughput, is absurdly inadequate, and makes Bitcoin's current energy consumption absurdly wasteful.

[tal8d]

You are overlooking the disadvantage of not verifying the prior hash, which you can't do until you can verify hashMerkleRoot, which you can't do until you have collected the entire block. If you skip verification, you open yourself up to bad actors feeding you a bogus header - and you only figure that out after being drip fed a bunch of transactions that don't match the merkle root. Erasure coding doesn't fix that. In any case, proponents of the 'cram everything in the public ledger' method have already advocated 128MB and even completely uncapped block sizes... so the outcome is predictable.

Take a hint from every successful network that has ever networked since ever: hierarchy, extensibility, etc. Demanding that it all be crammed into a homogenous block is so obviously doomed to fail that you should be suspicious of the proponents' motives.

[CyberDildonics]

> being drip fed a bunch of transactions

Where are you getting ideas like this? How fast do you think internet connections are?

Only in the context of bitcoin do people start thinking 250 byte transactions are somehow difficult to send over gigabit connections. The average bitcoin block is 900 -kilobytes- at most at 10 minutes on average.

How is it that people have absorbed propaganda that makes them actually think that causes anyone a problem? blizzard.com is 13MB, gfycat.com is 29MB. Who are these miners that are struggling to send out 900KB ?

[tal8d]

> Where are you getting ideas like this? How fast do you think internet connections are?

As fast as the packet source wants? The only way to defend against a slowloris DoS is by accounting for it at the application layer, which is both unusual and difficult - as DoS attacks are usually handled at the transport layer. In this case that could mean applying a deadline for the block announcement in its entirety - which means mandating a minimum connection speed, and classifying every connection that dips below that as an attack... so you better have a good SLA with your upstream network. Well, that is no problem for centralized operations... Guess what happens to cryptocurrencies that adopt massive 128MB+ blocks in order to increase their transaction throughput - they become incredibly fragile as the slightest amount of packet loss starts waves of peer bans.

> Who are these miners that are struggling to send out 900KB ?

Anyone who wants to handicap a competing pool by forcing them to either wait for the complete false block, or waste time hashing on a fake block header.

When are you going to admit that you haven't thought this through?

[CyberDildonics]

Now you are trying to say that for after 11 years, miners will for some reason sit and wait for someone that isn't sending them a block fast enough and that other miners will attack people like that.

No one is waiting. If someone tries to send out a block slowly, someone else mines that block and sends it out fast. This is not difficult to understand.

It's amazing all the made up nonsense you've thrown out to try to predict a future that has already come and gone. Why are you so desperate to prove something so ridiculous? What you are talking about doesn't happen at all at any throughput on any cryptocurrency.

[tal8d]

Check the reference client buglist, they got hit with a slowloris resource exhaustion combo. They fixed the resource exhaustion (kind of), they did not address the slowloris vulnerability. So again, you have no idea what you're talking about. Doubly so if you didn't write the backend of a major mining pool - because you're just running your mouth about code you haven't seen otherwise.

[CryptoPunk]

>>If you skip verification, you open yourself up to bad actors feeding you a bogus header - and you only figure that out after being drip fed a bunch of transactions that don't match the merkle root.

Malicious actors can't give a bogus header, because you can verify the bogus header doesn't have enough PoW. If the malicious actor does produce sufficient PoW for their bogus header, they are foregoing massive block rewards to fool your node for a few seconds. That's why this kind of malicious activity doesn't happen, and why miners do validation free mining on a new header until they've verified the whole block.

[tal8d]

> Malicious actors can't give a bogus header, because you can verify the bogus header doesn't have enough PoW.

Ok, I guess you don't know how verification works. Here are the 19 steps: https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messag...

    Step 4) "Block hash must satisfy claimed nBits proof of work"

The bad actor has full control of that, he just has to make sure the fake header has enough leading 0s in phony header nBits, the function that checks this is CheckProofOfWork() at https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L...

    Step 10) "Verify Merkle hash"

Well gee-wiz, how are we going to do that without having all the transaction in the block that the phony header hashMerkleRoot represents? GetHash() at https://github.com/bitcoin/bitcoin/blob/master/src/primitive...

[CryptoPunk]

That doesn't adrress my point at all. You can verify the requisite proof of work was done just by hashing the data in the block header to see if it meets the difficulty requirement.

The malicious actor cannot fake that. They have to produce massive amounts of proof of work to find a value in the nonce data field in the block header that results in that hash meeting the required difficulty, and even if the malicious actor delays transmitting the whole block, they cannot delay transmitting the block header, or other nodes will not even bother trying to extend their block.

So all miners can immediately verify if the block headers they are receiving have the required PoW behind them, and it would be very costly for a malicious actor to generate fake block headers with enough PoW to be accepted, while giving the malicious actor very little advantage in an attack, meaning it would be a completely impractical and ineffective way to attack way to attack Bitcoin.

[CyberDildonics]

What kind of a response is this? They said anyone can verify the proof of work and you are saying they can verify the proof of work. Where is the contradiction?

Verifying blocks is trivial. You aren't still saying that needing to receive 900KB is a big deal are you?

You seem to be acting like there is some sort of prediction that there will be a problem. Ethereum already produces blocks every 13 seconds at three times bitcoin's throughput.

[tal8d]

> Where is the contradiction?

I said that you can't verify the header until you have downloaded the entire block - meaning the time between a false header being submitted and the last transaction in the block being downloaded is time the miner either abandons its work on the last real block and then sits idle or risks hashing a new block prior to verifying the false header. He implied that you can somehow verify using the PoW. I demonstrate that you cannot. I'm not sure how you could have missed it.

[CyberDildonics]

> When you blow up the transaction limit you physically centralize the verification process.

What numbers are you basing that on? Bitcoin is 1.5KB/s. A $10 vps is 80,000 times faster than that.

> because fractions of a second make a big difference

No they don't. The examples you are talking about are rare and have very little impact. If the entire network makes blocks once every 10 minutes on average, each miner finds blocks much less frequently.

> Bigger blocks propagate more slowly, and magnify the advantage of employing those kinds of undesirable behaviors. This is why HFT boxes end up as physically close to Wall Street as possible.

Where are your numbers here? How long do you think it takes to send around 900KB ?

A single twitch stream will propagate more than that around the world every second to thousands of individuals. Cryptocurrency only has to send the same tiny amount of data every few minutes to miners.

High frequency traders trying to be physically closer to a connection are operating on the scale of single micro seconds. You are comparing that to something 600 MILLION times slower.

[tal8d]

> What numbers are you basing that on? Bitcoin is 1.5KB/s.

You know you can't verify an incomplete block, right? If you think you can just plow ahead after getting the first packet... you are going to have a really bad day once the other miners notice that you can be fooled into wasting hash power on bogus headers. You know that blocks get announced by the miners after they solve the hash, in chunks that can be up to the max blocksize, right? For Bitcoin that is 1MB, for bcash it is 32MB. Imagine if NASDAQ offered two levels of service: one that put the FIX protocol behind a 1MB buffer, and the other behind a 32MB buffer - which one would be disadvantaged? Anyone sitting at the 32MB buffer would be getting their lunch eaten. This is about as fundamental as it gets, so you might want to do some reading - because you've clearly got a big blindspot.

> No they don't. The examples you are talking about are rare and have very little impact.

If you are talking about bitcoin, you are very wrong - it is a thoroughly documented occurrence, it even has a name: the selfish miner strategy. If you are talking about bcash, I dunno one way or the other - I don't pay much attention to the joke coins. https://doi.org/10.1109/ICBC48266.2020.9169436

> How long do you think it takes to send around 900KB ?

Again, you need to actually do some reading on how mining works and what the network propagation characteristics are. I really don't want to have this come off as meanspirited, but it needs to be said: you obviously thought you knew how things worked, and you obviously don't - I wonder how many people you've misinformed.

[CyberDildonics]

> you are going to have a really bad day once the other miners notice that you can be fooled into wasting hash power on bogus headers.

What are you even talking about here? 900KB takes a fraction of a second to transfer on a modest internet connection, any miner with $10 a month for a VPS can transfer that is a millisecond. No one said anything about downloading fractions of blocks, you hallucinated that.

> Anyone sitting at the 32MB buffer would be getting their lunch eaten. This is about as fundamental as it gets, so you might want to do some reading - because you've clearly got a big blindspot.

What is it that you think is even happening? Blocks get sent out. One has 32x the transaction throughput. Why do you think 32MB or more would be anything other than trivial to send and receive? Any miner can send and receive that in a second.

> I don't pay much attention to the joke coins.

Bitcoin cash already has more sustained transactions than bitcoin. Maybe you should reach beyond the propaganda of /r/bitcoin

> it even has a name: the selfish miner strategy.

Miners that do that take the risk that someone else will propagate a block before them since they didn't share the previous block they found. Empty blocks have much more of an impact on bitcoin because the throughput is so constrained. Empty blocks do not have much of an impact on the usability of bitcoin cash because it has plenty of throughput. A miner maliciously mining empty blocks on bitcoin will also leave a lot of money on the table because they won't get transaction fees.

> you obviously thought you knew how things worked, and you obviously don't

Everything you said is either completely made up or an exaggeration of some minor effect. In your last message you compared something with a 10 minute window to millionths of a second. For some reason you ignored this and ignored the actual numbers of modern bandwidth. You keep using hyperbole but won't quantify anything because the numbers don't add up.

[tal8d]

> What are you even talking about here? 900KB takes a fraction of a second to transfer on a modest internet connection...

You are assuming that there are no bad actors in the network who might not want to transfer a block in a fraction of a second, and don't have to because they control the packet rate. Also you seem really hung up on this 900KB figure, you've repeated it in 8 recent posts. You know bitcoin's 30 day average block size has been above 900KB since 2018-10-24? But why would you harp on bitcoin's block size when you are advocating for a max block size that could accommodate all of Visa's transactions? Is is because you know that a 300MB+ block guarantees the death of decentralization and you'd look ridiculous pretending otherwise? To quote you before you presumably exchanged your BTC to double down on your bcash airdrop:

"Once again, whatever people's views on bitcoin at least realize that mining hashes don't dictate how many transactions can be processed by a miner. They mine a block, then they include as many transactions as they think they can get away with and keep the latency low enough to propagate."

2016 -- https://news.ycombinator.com/item?id=11689765

> ...a VPS can transfer that is a millisecond.

Ah yes, that has worked out great for several exchanges and various other cryptocurrency related services. The cloud has been great, fill it with all the things.

> No one said anything about downloading fractions of blocks, you hallucinated that.

You don't seem to understand how packet switched networks function either. Go lookup "MTU", I look forward to hearing how even the most modest internet connection enjoys IPV6 with a 300MB jumboframe policy spanning the entire network path!

> Why do you think 32MB or more would be anything other than trivial to send and receive? Any miner can send and receive that in a second.

Except for everyone transiting a sub 256mb peering point... so alot of people: https://www.peeringdb.com/advanced_search?info_traffic__in=0...

It isn't that it'd take them 10 minutes to download the entire block... it is that they are at a 0.92 second disadvantage to their competition - this drives the physical centralization.

> Bitcoin cash already has more sustained transactions than bitcoin. Maybe you should reach beyond the propaganda of /r/bitcoin

lol, the salty salty tears.

> Miners that do that take the risk that someone else will propagate a block before them since they didn't share the previous block they found.

And yet they do it, because it has been mathematically demonstrated to be a winning strategy - even before block bloat induced propagation delay. The rest of the statement is simply nonsensical.

> In your last message you compared something with a 10 minute window to millionths of a second. For some reason you ignored this and ignored the actual numbers of modern bandwidth. You keep using hyperbole but won't quantify anything because the numbers don't add up.

Yeah, you clearly don't understand the comically simple idea that a consistent head start on your competitors guarantees eventual domination. The 10 minute window is completely immaterial to the point. If you can consistently verify the newest announced block 1 second before every other miner - then your average solve rate is guaranteed to be 1 second faster than their average solve rate.

[CyberDildonics]

> You are assuming that there are no bad actors in the network who might not want to transfer a block in a fraction of a second,

No, you are assuming that it matters if people try this. Who cares if someone sends slow? No one waits for them. They send a block slow, someone else mines the block and sends it out fast. You have hallucinated this attack, it doesn't happen. Show me evidence of this having any effect if you can.

> bitcoin's 30 day average block size has been above 900KB since 2018-10-24

This is not true. 900KB is where the MAX size of the blocks. The average is much lower from variance. This is not difficult to see:

https://bitinfocharts.com/comparison/size-btc.html#3y

> But why would you harp on bitcoin's block size when you are advocating for a max block size that could accommodate all of Visa's transactions?

Where did I say any of that? All I've done is point out that the things you say have no evidence and don't even make sense.

> Ah yes, that has worked out great for several exchanges and various other cryptocurrency related services. The cloud has been great, fill it with all the things.

This is just vapid sarcasm. There are no problems with exchanges. If you have evidence, show it.

> You don't seem to understand how packet switched networks function either. Go lookup "MTU", I look forward to hearing how even the most modest internet connection enjoys IPV6 with a 300MB jumboframe policy spanning the entire network path!

Focus please, confront the topic at hand, stop with irrelevant nonsense.

> It isn't that it'd take them 10 minutes to download the entire block... it is that they are at a 0.92 second disadvantage to their competition - this drives the physical centralization.

Show evidence that this happens and is a problem to anyone.

> lol, the salty salty tears.

This is not evidence of anything. Ethereum and bitcoin cash do have more transactions going through them than bitcoin. I will show you the actual information:

https://bitinfocharts.com/comparison/transactions-btc-eth-bc...

> And yet they do it, because it has been mathematically demonstrated to be a winning strategy - even before block bloat induced propagation delay. The rest of the statement is simply nonsensical.

It isn't a winning strategy, it is a mild attack that accomplishes very little and loses money from not including transactions. Bitcoin cash does not have capacity problems so people don't even notice. Sitting on blocks accomplishes very little since the rest of the network is more likely to out mine you as time goes on.

> If you can consistently verify the newest announced block 1 second before every other miner - then your average solve rate is guaranteed to be 1 second faster than their average solve rate.

The time it takes to verify a block is trivial. If it was so important, why aren't all the blocks empty?