So you agree there's no normal use case for 1MB or larger transactions, so why do you oppose limiting transactions to 1MB while increasing blocksize?
I don't agree with that. I haven't thought about it, and I'm pretty sure that there may very well be a normal use case for some business.i hope you have at least that level of intelligence.
Considering your contradiction posts on this subject though, I am starting to doubt that. (either that, or you are forgetting your own statements in less than a few hours after posting them).
Statement 1:
I don't want blocks larger than 1MB
Statement 2:
I might want transactions larger than 1MB
These are not compatible with each other (not to mention, they're ridiculous, even in their own, but together they're even worse).
Are you mad because I can destroy your entire argument in 2 minutes of typing?
1) I don't get "mad" when someone rationally shows supreme arguments. 2) You did no such thing.I have proven this to be factually correct, and it remains true until you prove proof that your disagreement is backed by logical reasoning and facts.
You have done no such thing. You're starting to resemble Veritas.And you can teach me?
I may or may not be able to, not that it would matter.First of all, technology has become much cheaper in the past 6 years (on average at least). And besides, who really has a hard drive measured in gigabytes anymore?
Strawman argument.
You're only showing that talking with you is a massive waste of anyone's time.
Yes, they're being sold and yes I plan to buy a 1/2 TB drive.
That's still plenty to run 20MB blocksize for several years, even if you falsely assume every single block is full. (and it's still a drive measured in terabytes)Still, in practice even a cheap 500GB drive would last for at least half a year, and most likely longer because it's unlikely blocks of 20MB would be filled every time at least for the next few years.
It's quite easy, you just divide the blocksize by the average time it takes to find a block.
20 MB / 10 minutes = 2 MB per 1 minute. 2 divided by 60 = 0.03 MB/s. Let me tell you why your thinking is flawed (not that you're going to admit this). If a node is downloading at this speed, it will never catch up. Why is that? By the time that it downloads a 20 MB block, it is likely that another one will be created. The node would still be validating the previous block in addition to having the next one. I do wonder how long it takes to validate a 20 MB block on decent hardware though.Except that you snipped out the part where I actually admitted this before you even brought it up as an argument, along with saying that this isn't an issue because it's several orders of magnitude lower than even slow internet speeds. So even if you account for this, it's not a problem.
Not only do you show an inability to reasoning on any level of intelligence, you also are also purposely misrepresenting my quotes. I'm not beyond admitting when I'm wrong, I am wrong sometimes, but that does not invalidate my arguments. Fact is, every single person is wrong sometimes, but that does not make everything they say wrong.
And xthin blocks would solve that issue too, but Core doesn't support xthin (of course, because core doesn't support improvement).
And what is the primary bottleneck then? I'm sure memory won't be a problem with blocksizes smaller than a few gigabyte.
Validation time.Well, it's a good thing Satoshi was smart enough to keep block times at 10 minutes then, unlike many altcoins who have blocktimes of mere seconds.
10 minutes should be enough for the slower nodes to keep up with plenty of headroom. (this is also why I oppose of altcoins with very fast blocktimes).