Stop fuckin' around, fork the son-of-a-bitch already.

[franky1]

This is all completely false, and useless to read. The number of nodes updating has nothing to do with HF activation parameters.

let me guess you have on many times suggested consensual parameters that are acceptable... but you are now pretending that instead you imagine the parameters have to be some different and lower doomsday parameter and 28 day grace just to make your newest doomsday argument your creating plausible.

the argument that I'm creating.

again.. the 95% does not trigger until 5700 have reviewed code, tested it and happy to run it..
this could take days-weeks-months before we start to see people using it. and longer before there is a clear 95% stable and constant use of it that meets a stable/constant use parameter of lets say 1000-10000 block measure of constant 95%.

then after that (which itself may take months to get to that point) there is also a further grace period.

this is not to say the 95% trigger is time locked to activate next week
this is not to say the 95% trigger is going to happen at any predictable time at all..
it will happen if and when 95% have done all the checks and tests and run the code for a length of time

[Lauda]

again.. the 95% does not trigger until 5700 have reviewed code, tested it and happy to run it..
this could take days-weeks-months before we start to see people using it. and longer before there is a clear 95% stable and constant use of it that meets a stable/constant use parameter of lets say 1000-10000 block measure of constant 95%.

No. You have no idea what you're talking about. The "95%" is regarding the hashrate supporting the proposal, not the number of nodes supporting it. If it were up to the number of nodes, one could easily disrupt this by creating a ton of AWS nodes using an older version. Once again, you have no idea what you're talking about.

[franky1]

again.. the 95% does not trigger until 5700 have reviewed code, tested it and happy to run it..
this could take days-weeks-months before we start to see people using it. and longer before there is a clear 95% stable and constant use of it that meets a stable/constant use parameter of lets say 1000-10000 block measure of constant 95%.

No. You have no idea what you're talking about. The "95%" is regarding the hashrate supporting the proposal, not the number of nodes supporting it. If it were up to the number of nodes, one could easily disrupt this by creating a ton of AWS nodes using an older version. Once again, you have no idea what you're talking about.

no wonder you have your fingers in your ears.. its digging all the grit out from sticking your head in the sand.

seems you forget what happens after the grace period.
when miners see users are ready users are then happy to accept 2mb blocks, but still only receive 1mb blocks, because...

miners have to be satisfied their competitors dont disregard thieir blocks
so when miners are then satisfied that atleast OVER 95% of user nodes have the rules ready... then the miners do their own flagging and consensus mechanism over another block measure to show a 95% of miners are happy

seriously wake up to reality and join the conversation, get out of the fantasy doomsday nightmare that is not reality and start thinking rationally about how things will work in the real world.

miners wont jump first, they will wait for users.
even when users are ready, miners wont jump unless they see other miners also consent, that way the orphan risk is low (around 0-5%, same as any other day where we are seeing small % orphans a eachday)

[Lauda]

need you forget what happens after the grace period.
miners are then satisfied that atleast OVER 95% of nodes have the rules ready... then the miners do their own flagging and consensus mechanism over another block measure.

Miners don't care about the situation with the node count and they should not be interested it. The number of nodes in a small period of time is a horrible metric as it can be easily manipulated.

seriously wake up to reality and join the conversation, get out of the fantasy doomsday nightmare that is not reality and start thinking rationally about how things will work in the real world.

Ad hominem & no argument once again.

miners wont jump first, they will wait for users.

Again, the "users" that run nodes are a small minority. There's no way to properly "wait for users" as there's no way to "measure these users".

[franky1]

need you forget what happens after the grace period.
miners are then satisfied that atleast OVER 95% of nodes have the rules ready... then the miners do their own flagging and consensus mechanism over another block measure.

Miners don't care about the situation with the node count. The number of nodes in a small period of time is a horrible metric as it can be easily manipulated.

seriously wake up to reality and join the conversation, get out of the fantasy doomsday nightmare that is not reality and start thinking rationally about how things will work in the real world.

Ad hominem.

miners wont jump first, they will wait for users.

Again, the "users" that run nodes are a small minority. There's no way to properly "wait for users" as there's no way to "measure these users".

"users" refers to nodes that are not mining. not the physically breathing and eating and pooping human at the computer
also its the nodes that do the validating, that could lose a miner alot of income if the miner jumped first and made blocks that other pools reject and users full nodes reject.. so they do care about users nodes.
EG imagine if no merchant/exchange was using the same rules as the miner.. the miner cant then spend their income.
think about it. in a waking reality.

wait..
let me guess your subtly hinting that the node decentralization doesnt matter and you think that 6000 nodes is irrelevant and we should just have 1 node? or wil you backtrack and admit that the nodes do an important job.

[Lauda]

"users" refers to nodes that are not mining. not the physically breathing and eating and pooping human at the computer

That's not the definition of a user. It's one thing to be a user, and another one to be a node operator.

also its the nodes that do the validating

You don't say?

wait..
let me guess your subtly hinting that the node decentralization doesnt matter and you think that 6000 nodes is irrelevant and we should just have 1 node?

You've guessed wrong, yet again. If I thought that decentralization didn't matter, then I'd be proposing ridiculous block sizes like those BU lunatics.

[franky1]

"users" refers to nodes that are not mining. not the physically breathing and eating and pooping human at the computer

That's not the definition of a user. It's one thing to be a user, and another one to be a node operator.

also its the nodes that do the validating

You don't say?

wait..
let me guess your subtly hinting that the node decentralization doesnt matter and you think that 6000 nodes is irrelevant and we should just have 1 node?

You've guessed wrong, yet again. If I thought that decentralization didn't matter, then I'd be proposing ridiculous block sizes like those BU lunatics.

im not talking about node operators (the human) im talking about the demographic/category of nodes.. mining nodes vs user nodes
but atleast now your admitting that the distribution of non-mining nodes has an important job as part of the network.

and it seems you have failed to understand BU.
the 16mb safetly number, is the same as cores 32mb safety number..

then below those safety numbers:
BU has a dynamic mechanism for preferential buffer
core has a fixed preferential buffer of 1mb for 0.12 and 1mb base 4mbweight for 0.13

oops did you forget cores 32mb limit, well then
 
but have a nice day,

P.S
the 16mb explicit cap and cores 32mb explicit cap. have nothing to do with the preferential blocksizes the consensus should work at, but to do with a secondary safeguard in relation to issues with data packet sizes and other issues regarding the internet as a whole (beyond bitcoins control)

 i laugh at your mindset
'big blockers want 2mb'  ........ (core wants 4mb)
'big blockers have a secondary barrier of 16mb'     (core has 32mb)

easy maths question.
2 and 16.... or 4 and 32. which is perceived as the real big blockers?

[franky1]

lets put it into a scenario you may understand.

town rules.. the town shouldnt have more than a 32bedroom house because outside of town it can cause highway congestion(internet packet loss/delay), aswell as inside the town(bitcoin network) by logical default

now there are several neighbourhood councils(implementations) within the town(bitcoin network) with their own rules below the town rules.

old satoshi QT 1 bedroom houses but only half the room can be used due to a db bug infestation
old core council 1 bedroom houses
new core council 1 bedroom houses with a 3 bed mobile-home on the drive for parents(signatures) to sleep, possibility of 2 bedroom houses next year
BU council want people to choose but are highlighting the town rules by lowering the town rule threshold. while still allowing preference below it
other council want 2 bedroom houses, with hope that later the rule can be consensually changed again (in years, like an oliver twist' please sir can i have some more')

all council rules are WAY way way below the town rules, because although the town rules are in regards to outside town issues, the neighbourhood council are worried about immigrants over population (spam), local road delays (transaction bottlenecking within bitcoin), costs of maintaining the house ($200 hard drives)

[zimmah]

Other than a mindless fearr of a hard fork, give me 1 solid reason based on logic against a block size increase.

1) Security risk of a DOS due to quadratic validation problem.
2) No hard fork experience.
3) High risk of damaging merchants and businesses that do not manage to update in time (if the activation parameters are improper such as with Bitcoin Classic).
4) Higher storage cost.
5) Higher bandwidth cost.
Even if we disregard the 4 latter, the primary issue is still the security risk.

1) You could limit the transaction size while still increasing the blocksize.
2) ETH did fine.
3) Few shops actually directly accept bitcoin without an intermediary. Those intermediaries should be bitcoin-savvy enough to prevent damage to the merchants. Those merchants that do accept bitcoin directly probably know enough about it as well.
4 & 5) The increased costs is only marginal. Most people already have internet that can easily support much bigger blocks than 1MB, both upload and download, without even affecting regular browsing behavior. And most people have plenty of room on their hard disks, even if they don't a 1TB hard disk will go a long way (lasts for 19 years with 1MB blocksizes assuming they are all full and are never once pruned in those 19 years). So obviously there is room for significant improvement without being cost-prohibitive to most people. In fact, a vast majorty of people wouldn't even notice the effect.

[Lauda]

1) You could limit the transaction size while still increasing the blocksize.

It's not a matter of 'could' or 'could not', but rather a matter of "should" or "should not". I disagree with those limitations.

2) ETH did fine.

We're talking about Bitcoin, not a mutable shitcoin.

3) Few shops actually directly accept bitcoin without an intermediary. Those intermediaries should be bitcoin-savvy enough to prevent damage to the merchants. Those merchants that do accept bitcoin directly probably know enough about it as well.

This argument has no relevance to what I said. You don't know how long it takes for those "intermediaries" to upgrade and test their custom implementations (hint: 28 days is ridiculous).

4 & 5) The increased costs is only marginal.

A minimum of 2x increase is "marginal"?

And most people have plenty of room on their hard disks..

You can't know this. Example: I have to upgrade my node soon due to inadequate amount of storage on it.
Oh, and I forgot to mention that in case something goes wrong with your datadir (if you use Core as a wallet for example), you will spend a ridiculous amount of time fixing it with absurd block size proposals.

[franky1]

4 & 5) The increased costs is only marginal.

A minimum of 2x increase is "marginal"?

what actual costs..

a 2tb hard drive does not cost more if its storing 52gb or 104gb.. and in 20 years-40 years when its full that hard drive cost is marginal
wait. lets put it into cores 4mb preference
10 years usage

most people change their computers every 5 years anyway

You can't know this. Example: I have to upgrade my node soon due to inadequate amount of storage on it.

oh i forgot you dont have a real node running on a home computer. you have an online AWS node with only probably 100gb storage

try splashing out $300 and run a real node for once and be part of the decentralized network. that $300 will last you over 10 years
($30 a year, $2.50 a month) much cheaper then amazons $15 a month

[zimmah]

I don't think it is "mindless fear" to point to Ethereum's failed hard fork and point out that it permanently split the network. This caused significant losses for custodians---Coinbase lost ETC and still hasn't repaid their customers. BTC-E was replay attacked and lost all of their customers' ETC; they won't be repaying it. The results would have been disastrous if Kraken and Poloniex didn't have the foresight to ignore the Ethereum Foundation's advice to ignore ETC and not repay their customers their money. Replay attacks were commonplace, and many users lost money in trying to spend on only one chain or the other.

Seems like mindless fear to me, the replay attack has been fixed on all of the proposed Bitcoin forks, it is rather trivial to fix actually. The ethereum foundation purposely decided not to fix this particular issue, I thought that was a mistake. Splitting Bitcoin as a minority would not cause such problems at all, custodians also need to be more responsible in such a situation and take it into account. Some of those custodians simply just did not believe ETC would survive, now we know better.

That's not true. If Classic merges an update to change transaction format (not just add a new transaction format), it will be true for Classic. XT and Unlimited offer no replay protection. This is actually not just a technical issue---many that believe that a clean hard fork (one network) is possible don't want explicit replay protection because it promotes the idea that multiple blockchains will emerge. This was partially why Ethereum did not include replay protection in their fork; they simply assumed the original chain would die. The very idea of including replay protection in a fork is to make both networks viable (i.e. to enforce a network split). In the past, Gavin became quite upset at the suggestion that a hard fork could split the network---I'm curious about his thoughts on this.

I suppose that is why I now support splitting the chain, the alternative chain would simply have alternative clients that support it, solving the replay attack on both networks. I think that you are correct in thinking that a non controversial hard fork is no longer possible unless it is done through Core, who seem unlikely to increase the blocksize limit anytime soon. Therefore the only solution for people like myself who prefer that Bitcoin stays true to the original vision of Satoshi, is splitting the chain, after all Satoshi was a big blockist as well.

While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall.  If Bitcoin catches on on a big scale, it may already be the case by that time.  Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms.  Whatever size micropayments you need will eventually be practical.  I think in 5 or 10 years, the bandwidth and storage will seem trivial.

Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section Cool to check for double spending, which only requires having the chain of block headers, or about 12KB per day.  Only people trying to create new coins would need to run network nodes.  At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware.

The eventual solution will be to not care how big it gets.

But for now, while it’s still small, it’s nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won’t matter much anymore.

The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users.

The threshold can easily be changed in the future.  We can decide to increase it when the time comes.  It's a good idea to keep it lower as a circuit breaker and increase it as needed.  If we hit the threshold now, it would almost certainly be some kind of flood and not actual use.  Keeping the threshold lower would help limit the amount of wasted disk space in that event.

Part of the problem in Ethereum is the heavily centralized development under the Ethereum Foundation, which has no public review/consensus mechanism. Vitalik said "let's fork" so mining pool admins ignored their miners, client developers forked their clients by default (no user choice whatsoever) and the fork came from the top-down. This makes user consent very difficult to gauge. Even in this context, Ethereum could not successfully hard fork.

Ethereum presently has the same consensus mechanism as Bitcoin, users can choose to use Ethereum Classic instead, this is what gives people the freedom of choice, that is part of the consensus mechanism of Bitcoin as well and soon this will happen to the Bitcoin network as well.

The effects of splitting the Bitcoin network and increasing the supply of "bitcoins" across multiple blockchains could be far worse for Bitcoin's value proposition than a network split in Ethereum.

Splitting the network does not worsen Bitcoins value proposition, since the share of total Bitcoins remains the same across all chains for investors, which means it does not create any type of monetary inflation, it protects the value of investors. Furthermore because it is already relatively easy to do this with a small minority it should already be a part of Bitcoins value proposition, if you are not taking this feature into account you are not truly evaluating the value of Bitcoin, for me it actually improves the value proposition of Bitcoin since I perceive this feature as being a crucial part of the governance mechanism.

Within a particular network, there has not been inflation, but you need to consider public perception and a confused userbase deciding among multiple networks, each with a supply of 21 million BTC. Again, I wonder if you could point to the protocol documentation or description from the whitepaper that suggests that breaking the consensus rules are "a crucial part of the governance mechanism"? Like I said, go ahead and fork....just don't be surprised when no one refers to your fork as Bitcoin.

Exactly, a confused user base does not change the fact that investors are still protected under such a mechanism. Not everything is in the whitepaper, but the consequences and reality of the rules that exists are within the code and the world for all to see. Because this is possible, it should be considered as part of the design of Bitcoin itself and considered inevitable from happening, especially considering the nature of human behavior.

If find it sad and surprising that so many people seem to be in favor of core, as opposed to classic/unlimited. I wouldn't be surprised if they just went with the 'default' option not actually even knowing that by downloading the 'default' wallet they actually vote in support of core.    

Core's official roadmap claims to have Segwit and LN active in April/July 2016 respecitively, but it's already september and neither of them are active now. Mainwhile blocks are mostly full and no solution is offered by core.    

By the time segwit and LN go online (if ever) it's too little too late. Mainwhile, bitcoin is losing marketshare rapidly, and due to the network effect, this could have permanent disastrous results for bitcoin.    

In my opinion, people make way too big a deal about an increase from 1MB to even 2MB, while 2MB blocks don't even hurt anyone (heck, even 20MB blocks wouldn't hurt anyone).        

[Lauda]

what actual costs..

1 MB of data per full block -> 2 MB of data per full block. This equals to 2x increase.

oh i forgot you dont have a real node running on a home computer. you have an online AWS node with only probably 100gb storage

My node is not on any online service. Stop spreading lies.

try splashing out $300 and run a real node for once and be part of the decentralized network. that $300 will last you over 10 years

$300 won't last you 10 years.

Core's official roadmap claims to have Segwit and LN active in April/July 2016 respecitively

Both are false. Core did deliver Segwit in April, but there was no mention of activation by that time. "LN active" is a pure lie. There are other groups that are developing Lightning.

In my opinion, people make way too big a deal about an increase from 1MB to even 2MB, while 2MB blocks don't even hurt anyone (heck, even 20MB blocks wouldn't hurt anyone).         

Statements like this one make people ignorant fools by default.

[redsn0w]

Interesting, freedom of choice no one will force you to run a software... never.

[zimmah]

1) You could limit the transaction size while still increasing the blocksize.

It's not a matter of 'could' or 'could not', but rather a matter of "should" or "should not". I disagree with those limitations.

If you limit the transaction size to 1MB, nothing changes from having a 1MB blocksize without a transaction size limit.

Who would ever need to fill an entire block with 1 transaction?  

You are just disagreeing for the sake of disagreeing at this point.      

2) ETH did fine.

We're talking about Bitcoin, not a mutable shitcoin.

That doesn't mean you can't look at other coins as an example. The main use of altcoins is to be a testbed for bitcoin, so that bitcoin can learn from their successes and mistakes. To prevent havng to make the same mistakes, while still benefiting from their successful projects.    
If bitcoin can keep up with the successful implementations of altcoins, while avoiding their mistakes, there will never be a reason for any altcoin to overtake bitcoin.    
However, if we stick our head in the sand and ignore altcoins altogether, some altcoin will eventualy shove bitcoin aside as old-fashioned and out-of-date. (Bitcoin would become the myspace of crypto)

3) Few shops actually directly accept bitcoin without an intermediary. Those intermediaries should be bitcoin-savvy enough to prevent damage to the merchants. Those merchants that do accept bitcoin directly probably know enough about it as well.

This argument has no relevance to what I said. You don't know how long it takes for those "intermediaries" to upgrade and test their custom implementations (hint: 28 days is ridiculous).

It does. You can't just say this every time someone disproves your statements.

4 & 5) The increased costs is only marginal.

A minimum of 2x increase is "marginal"?

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?    
Do you have any idea how long it takes for a TB to fill up on blocks of just a few MB? FYI a TB is a million MB.
Even a year worth of blocks only takes up a fraction of a home computer. Not a server, a regular home computer (even a laptop). If we increase the blocksize, it would only take up a larger fraction, but still it doesn't even fill an entire disk. So it would not actually cost anyone anything, unless their hard disk is already full. But even if someone's hard disk was full, he'd soon need a new drive anyway, because even without bigger blocks he'd run out of space soon.    
And since no one is going to buy a hard drive of less than 1TB anyway (are they even sold anymore?) your argument is mood.      

Even worse with network. Does anyone seriously have a bandwidth so low that 266kb/s is a problem? (that would be 20MB blocks).

rol)

 i laugh at your mindset
'big blockers want 2mb'  ........ (core wants 4mb)
'big blockers have a secondary barrier of 16mb'     (core has 32mb)

easy maths question.
2 and 16.... or 4 and 32. which is perceived as the real big blockers?

You're forgetting the part where they claim we want bitcoin to be a "get rich quick scamcoin"  

Because obviously the only reason we want bigger blocks is because a bigger block would magically cause the bitcoin price to become 20 times higher, which also is a bad thing.

what actual costs..

1 MB of data per full block -> 2 MB of data per full block. This equals to 2x increase.

oh i forgot you dont have a real node running on a home computer. you have an online AWS node with only probably 100gb storage

My node is not on any online service. Stop spreading lies.

try splashing out $300 and run a real node for once and be part of the decentralized network. that $300 will last you over 10 years

$300 won't last you 10 years.

Core's official roadmap claims to have Segwit and LN active in April/July 2016 respecitively

Both are false. Core did deliver Segwit in April, but there was no mention of activation by that time. "LN active" is a pure lie. There are other groups that are developing Lightning.

In my opinion, people make way too big a deal about an increase from 1MB to even 2MB, while 2MB blocks don't even hurt anyone (heck, even 20MB blocks wouldn't hurt anyone).        

Statements like this one make people ignorant fools by default.

You don't pay for data directly, most people already own a computer, and they use nowhere near 100% capacity on their internet nor on their hard drive.

Increasing the maximum block size doesn't change this (unless you increase it to terabytes, but  am not asking for terabytes)    

Besides, not every block will be full anyway. Every block is full now, but the whole point about bigger blocks is that not every block should be full in the first place (there needs to be some headroom).    

I don't know about you, but we haven't paid per MB of internet usage since the 90s. Or were you using your mobile phone as a node with cloud storage? Because in that case, you're doing it wrong.

By the way, a $300 computer can last you 10 years easily, you're not using it for gaming, you're using it as a node.

Also, where is segwit then? And if t's already deployed like you said, then why are they promising to deploy it in 2017 now? It's already active right?

[Lauda]

If you limit the transaction size to 1MB, nothing changes from having a 1MB blocksize without a transaction size limit.

There may or may not be attack vectors that could work with 2x 1 MB transactions. Just because it seems safe, that doesn't mean that it will be.

Who would ever need to fill an entire block with 1 transaction?  

I'm not talking about normal usage when it comes to security problems.

You are just disagreeing for the sake of disagreeing at this point.  

Said every person when losing their ground.

   
That doesn't mean you can't look at other coins as an example.

It's one thing to fork something small and centralized, and another to fork Bitcoin.

Bitcoin would become the myspace of crypto

Stop being "spoon fed" (as franky1 would put it) by Ver & co.

It does. You can't just say this every time someone disproves your statements.

It does not, as can be seen with your lack of experience in regards to large scale infrastructure.

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.

And since no one is going to buy a hard drive of less than 1TB anyway (are they even sold anymore?) your argument is mood.      

Yes, they're being sold and yes I plan to buy a 1/2 TB drive.

Even worse with network. Does anyone seriously have a bandwidth so low that 266kb/s is a problem? (that would be 20MB blocks).

You obviously aren't factoring in the primary bottleneck, but let's go with this. How did you derive this number, i.e. by calculating what?

[zimmah]

If you limit the transaction size to 1MB, nothing changes from having a 1MB blocksize without a transaction size limit.

There may or may not be attack vectors that could work with 2x 1 MB transactions. Just because it seems safe, that doesn't mean that it will be.

The whole reason huge transactions are unsafe is because of quadratic scaling, which won't work if you split up the equation across two transactions that scale linearly with each other.       

       

Who would ever need to fill an entire block with 1 transaction?  

I'm not talking about normal usage when it comes to security problems.

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? That gets rid of your man argument (security) while also allowing more transaction throughput, and therefore more users.   

Are you mad because I can destroy your entire argument in 2 minutes of typing?

You are just disagreeing for the sake of disagreeing at this point.  

Said every person when losing their ground.

Sorry but I just destroyed your argument, and you have no ground to disagree on, except the right to disagree, but you have no actual logical reason to disagree.     
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. 

   
That doesn't mean you can't look at other coins as an example.

It's one thing to fork something small and centralized, and another to fork Bitcoin.

TIL ETH is centralized. Yeah they have their differences, but centralization is not one of them.

Bitcoin would become the myspace of crypto

Stop being "spoon fed" (as franky1 would put it) by Ver & co.

I don't even know Ver, but from the few interviews I have heard from him he seems like a reasonable and nice guy, although I don't always agree with all he sais.

It does. You can't just say this every time someone disproves your statements.

It does not, as can be seen with your lack of experience in regards to large scale infrastructure.

And you can teach me?

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.

I'm sure this is in no way a strawman argument.

If anything, your conjecture is based on a strawman argument, because you are defending imaginary nodes (strawman) that would be blocked out of being a node because they can't run an imaginary node on on imaginary system with a hard drive that belongs in the 90s and internet that is basically quite literally smoke signals.   

Any computer made after 2000 and even the most basic internet connection has no problem at all running a 20MB node. And with no problem at all I mean that it is barely noticeable that you are even running a node while at the same time actually using your computer for other tasks.

If anyone is having strawman arguments it's you, because you're using strawman nodes to back up your defense. I am talking about actual technology and actual nodes, that are not aaffected by larger block size in the slightest.

If you can find actual persons that actually will be affected by a larger blocksize, be my guest, I'd like to hear their testimonies.

And since no one is going to buy a hard drive of less than 1TB anyway (are they even sold anymore?) your argument is mood.      

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)

Even worse with network. Does anyone seriously have a bandwidth so low that 266kb/s is a problem? (that would be 20MB blocks).

You obviously aren't factoring in the primary bottleneck, but let's go with this. How did you derive this number, i.e. by calculating what?

It's quite easy, you just divide the blocksize by the average time it takes to find a block. Obviously, you would need internet faster than that to be actually useful as a node, but on average your internet would use that amount of data. When a new block is found, it would for a few seconds use more bandwidth, followed by a couple of minutes of almost no activity at all. The point is though that 266kb/s is ridicilously small, and everyone has internet orders of magnitudes faster than that, so even for the most basic internet user, the network usage would not even be noticable.

And what is the primary bottleneck then? I'm sure memory won't be a problem with blocksizes smaller than a few gigabyte.

[franky1]

Yes, they're being sold and yes I plan to buy a 1/2 TB drive.

500gb hard drive. well your the one that chooses to not think about the future, only you will be the one crying
cant blame bitcoin or anyone else if your hard drive fills up in 2.5 years+ (core 4mb weight)

a 2tb hard drive is only 800,00 kuna (im guessing your still in croatia) (£90 : $120 for those not wishing to convert kuna to western currencies)
not sure why you are even choosing 500gb

i feel like your actually trying to shoot yourself in the foot just to have a reason to cry in 2 years, even though 2tb is not a "data centre" cost and will last you for atleast 10 years (core 4mb weight)

[Lauda]

The whole reason huge transactions are unsafe is because of quadratic scaling, which won't work if you split up the equation across two transactions that scale linearly with each other.    

I wasn't talking about that when I mentioned the potential of unknown attack vectors.  

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.

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.

I'm sure this is in no way a strawman argument.

It's a pure example of strawman fallacy. I never argued that "technology didn't become cheaper" did I? Don't attempt to use fallacies again, else we end up with nonsense as "Strawman nodes".  

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)

20 MB per block x 6 blocks per hour x 24 hours a day x 365 days a year = ~1051 GB per year. Please explain how a 1/2 TB drive (aka 500 GB drive) would run for "several 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.

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.

a 2tb hard drive is only 800,00 kuna (im guessing your still in croatia) (£90 : $120 for those not wishing to convert kuna to western currencies)

No, I am not and have never been in Croatia.

[franky1]

a 2tb hard drive is only 800,00 kuna (im guessing your still in croatia) (£90 : $120 for those not wishing to convert kuna to western currencies)

No, I am not and have never been in Croatia.

well i just thought that with all of your cries about internet speeds and stuff there was no way that you could live in america..
also things like talking croatian and being a mod of the croation category..

anyway
although 20mb is diverting off the current proposals by a factor of 5-10x.. and entering the cosmic theory of doomsday dreams, lets ask you..
are you saying to this other guy that 0.3mb internet speeds is something the world is averaging.
is this 0.3mb speed something you yourself are suffering with..

have you also complained to skype for offering video services to millions of happy people because in your eyes them millions of people must be unhappy.
have you also complained to twitch, youtube, and other video upload services that do live streaming?

in short is 0.3mb a real world problem where video uploading and livestream is a problem (uses more data then all current bitcoin proposals)

hmm.. lets pick a country .
ok africa..http://www.africawebtv.com/
ok korea..http://www.afreecatv.com/
ok russia..http://www.vichatter.com/

i could go on..
seems all countries around the world can livestream.

the funny thing is that you are more distraught about including 3rd world countries than excluding them.
this is because internet speeds are not excluding 3rd world countries, but the thing you have shown many times, is that your desire for higher fee's will price 3rd world countries out of using bitcoin.
i then laugh that you pretend you want higher fee's to reduce spam. yet you want to remove features like sigops, which will allow spammy transactions to increase. (funny that)