I don't think it's helpful to refer to both the existing protocol and Mike's 8 GB block limit monstrosity both as "Bitcoin". It makes discussion difficult. When I talk about "Bitcoin" I mean the system we currently have, in which there is a blocksize limit of 1 MB. That Bitcoin is the own which doesn't see the invalid blocks.
Well, sorry, that is religion, not science or engineering...
The number of miners accepting invalid blocks doesn't matter. Their blocks will be rejected anyway unless you're running the XT fork.
Big blocks will be rejected
only by players running BitcoinCore (or some other small-blockian software).
The longest valid chain accepted by Core *is* the longest valid chain, by definition.
Of course not; that is the longest valid chain *only for Core*. For implementations that accept bigger blocks, bigger blocks are (of course) valid, so the longest valid chain may be a different one.
And for implementations of dogecoin, dogecoin blocks are valid. What's your point? For Bitcoin core, 2 MB blocks are invalid no matter how many miners mine them.
That is exactly my point: the word "invalid" is meaningless by itself. Things are valid or invalid only
according to some standard, software, person etc. 2 MB blocks are valid for all clients and miners who are running any version of the Bitcoin software that accepts them.
The [Litecoin] software forked, not the blockchain.
No, Litecoin's blockchain
started with its own Genesis block on 13 October 2011. There is no block that is shared by the two chains.
It will not be easy to use the two chains independently, because all transactions are in principle executed on both chains. (That is another reason why they cannot be called "altcoins".) Only transactions that spend coins mined after the fork will be executed exclusively on the same branch.
The XT chain will quickly become polluted with outputs which are invalid on the BTC chain. "Taint" from coinbases generated only on the XT chain will fan out.
Yes; just as any transaction that uses utxos tainted by coinbases of blocks in the small-block branch will execute only on the small-block chain.
But only sophisticated users will know that, and only they would be able to exploit that feature to work with each coin independently. (How would
you get your own pre-fork coins tainted that way?)
Have you read BIP101? It proposes jumping the blocksize limit to 8 MB next year, and then doubling of the blocksize limit every 2 years, for 20 years. That gives us 8192 MB blocks in 21 years. And that's what the sane bitcoiners should want?
Sigh, it wlll NOT give 8 MB blocks next year, nor 8 GB blocks 21 years from now. Those are block size LIMITS. Bitcoin had a 32 MB block size LIMIT for almost 2 years at the beginnig, but teeny weeny block SIZES. In fact it had a 1 MB size LIMIT since then, and yet the average block SIZE is still 0.45 MB.
I wrote "limit" twice in the sentence you are complaining about.
Indeed you did, but then you concluded that BIP101 "
gives us 8192 MB blocks in 21 years". It surely will NOT, just as Satoshi's original implementation did not give 32 MB blocks in 2009, and the reformed one did NOT give 1 MB blocks in 2010.
If the block SIZEs ever get close to 8 GB, it means that the traffic is 15'000 times what it is today, which ma mean a user base of hundreds of millions.
No, it doesn't. Any miner can create a full block by generating their own transactions for free.
And why would he do that? Why didn't miners create 32 MB blocks in 2009, or 1 MB blocks since 2010?
Bigger blocks take longer to propagate and have a slightly higher chance of being orphaned. There is no advantage for a miner to pad his blocks, and a slight disadvantage.
Moreover, a miner who, for some reason, wished to fill his blocks to the limit cannot broadcast his spam to the network, because some other miner could mine it and take the fees. But then everybody will realize that those extra 7.5 MB is spam that he created himself. Then his peers, even without explicit agreement, could decide to ignore his blocks and orphan them.
But I do agree that BIP101's schedule is stupid: it is silly to plan parameter changes several years in advance, when no one knows even whether bitcoin will survive to next year.
Good. Then please stop arguing in its favour. The sooner it dies, the better. We need to reject this and find a proper solution.
I do not argue in favor of BIP101. A substantial increase in the block size limit before the end of the year is obviously necessary to keep bitcoin working, as it has so far, for a few more years. Any software that does that will do.
However, it seems that the only way that will happen is through software that is not controlled by Blockstream. People who care about bitcoin's future should try to become independent from the BitcoinCore version.
