Quote from: d5000 on May 05, 2017, 12:13:10 AM

Yep, maybe. What I meant was that big spam transactions would cost them an amount of hashing power that they - if they ignored these transactions or give them a very low priority - could use better to find blocks faster and get an advantage over their competitors.

a ASIC does not have a hard drive.. it does not matter to an asic if a block is 250bytes or a gigabyte. the "hashing" is the same
an asic is just given a hash and rehashes it.

data or bloat does not hinder ASICS one bit.. it only hinders the pool/server that validates/relays full block data.

Quote from: Lauda on May 04, 2017, 05:11:23 PM

Quote from: d5000 on May 04, 2017, 05:01:33 PM

2 MB + SW in my idea would occur in >2019. If Bitcoin's growth continues at the same speed than until now (30-50% transaction volume growth per year) then we could see pretty full mempools then. OK, maybe not if sidechains or extension blocks are functioning.

I don't agree with the instant jumping visions anyways. Why not 1.2 MB now, 1.4 MB next year and so on, until we hit 2 MB? These kind of approaches make more sense to me.

its taken years of debate and still no guarantee on moving the block size once.. do you honestly think moving to 1.2mb is going to benefit the network, and then have another few years of debating to gt 1.4mb..

if your talking about progressive blocksize movements that are automated by the protocol and not dev decisions per change.. then you are now waking up to the whole point of dynamics.. finally your looking passed blockstream control and starting to think about the network moving forward without dev spoon feeding . finally only took you 2 years (even if you think that hard limiting it at silly low amounts is good)

give it 2 more years and you will wake up to hard limit of 4mb and soft limit that moves up in increments.
EG
like the last 8 years (rplace hard with consensus and soft with policy, and you will start to understand)
1mb consensus 0.25mb policy 2009-2011
1mb consensus 0.5mb policy 2011-2013
1mb consensus 0.75mb policy 2013-2015
1mb consensus 0.99mb policy 2015-2017
to become
4mb consensus 2mb policy 2017-2018
where policy grows

oh and guess what.. pools never have just jumped from 0 to 0.25.. or 0.25 to 0.5..
even when policy allowed it, pools took things cautiously to avoid orphan risks

so say
4mb consensus 2mb policy 2017-2018 was implemented
pools wont make a 2mb block the very first block of activation. they would test the water with 1.000250mb to see the risks, timings issues of bugs orphans etc.
and increment from there.

you may argue "but whats to stop a pool jumping to 4mb".. well the same reason pools didnt jump to 1mb.. and instead themselves went up in safe increments to protect their own risks of orphans and other issues (as my last paragraph explained)
also thats where nodes would have an extra safeguard.. but ill leave you to take a few years to realise the extra safeguard. which is what dynamics is all about.

so go spend 2 years shouting nonsense/irrelevant until it finally dawns on you
have a nice 2 years