Quote from: tvbcof on February 08, 2015, 04:11:29 AM

Initially, at least, I'll only use a sidechain which can recognize an attack and freeze peg operations until the attacker gets tired of wasting his effort and goes away. If it even takes that to protect the sub-system.

That's not how sidechains work. If you want two-way convertibility, without using trusted third parties, the only thing that controls where the suspended BTC backing the sidechain go is proof of work, so a successful >50% attack can steal all the BTC backing the sidechain.

Quote

As I've said before, I'm open to a conversation about blocksize as long as there is a well defined problem and proposed solution regarding scaling. I've made no bones about the fact that I myself have serious concerns about 4-7 tps even when most native Bitcoin transactions are sidechains balancings and user 'safe deposit box' style transactions if/when crypto-currencies are more than a tiny tiny part of the world's financial activity.

None of you pro-fork people have given anything to hint at where you want to stop with your simplistic 'increase block size to scale' scheme, or where you want to draw the line with exclusions. All I hear is 'faith based' assertions that market forces will make everything work out. Start talking numbers and we'll start analyzing. In the mean time, we have one chance to stay within the constraints of what is achievable behind TOR and realistically likewise hardening methods. I'm not interested in throwing it away... especially when there is no need and a very promising solution is around the corner.

The only point I'm adamant about is that the 1 MB block size limit absolutely needs to be raised, because otherwise Bitcoin's chances of mass adoption are severely curtailed. You'll notice a lot of the people pushing for a permanent 1 MB restriction are supporters of one or more altcoins, and it is altcoins that I believe stand to benefit most from the Bitcoin community failing to do the right thing and raise the current limit.

I am also open to different proposals on exactly what to replace the current 1 MB restriction with, in order to make the right trade off between distribution of full nodes, and transaction throughput.

As for which particular proposal is best, I wrote this on Reddit a while ago, and for brevity, I'll reproduce it here:

I would go with Gavin's 16.8 MB, and doubling every two years after that (40% per year), up to a maximum of 16 GB 20 years from now. If it was entirely up to me, I'd probably raise it to the same 16.8 MB, and then grow it up by a smaller percentage every year (e.g. 25%). However, I haven't studied bandwidth growth rates closely enough to know for certain what the right rate of increase is.

Whatever it is, I'm not overly concerned with a 'too-high' block size limit, as there are multiple mechanisms in place already that prevent blocks from getting too large, other than a hard limit at the protocol level. Thus far in Bitcoin's history we've seen that blocks don't get as big as the hard limit permits: the limit has been 1 MB for five years, and blocks are still only 0.5 MB. And if the hard limit turns out to be high, AND the other mechanisms fail to impose reasonable limits on the block size, a soft limit can be imposed by miners, that would be enforced as if it were a hard limit. So whether the hard limit grows by 25% or 40% every year, is not a big deal IMO.