Quote from: JorgeStolfi on August 26, 2015, 03:46:20 AM

Quote from: kano on August 26, 2015, 12:44:19 AM

Mining has no economic reason to accept unlimited bigger blocks since that represents a loss of income

Most miners know that, if the network is allowed to become congested, it will become unusable, and very vulnerable to spam attacks, even by attackers with modest budgets.

Well at least whoever paid for those SPAM attacks got their money worth with you: believing in the dire straights the XT goons want people to think are already here

Quote

Then adoption will drop, public image will be in sambles, and the price will probably crash.

Nah, that's what XT has done to BTC already ...

Quote

Bigger blocks will at least remove one obstacle to further adoption growth, and will make spam attacks at least 10 times more expensive, and their effects shorter-lived.

Methinks that most miners, like most services and exchanges, will see the economic advantages of increasing the block size. (The five largest Chinese miners already did.)

They were approached directly by the XT goons and their response?
To use a non-XT voting method to vote for a block size ...
We don't need a bigger block size now.
We do need to have in place shortly the ability to increase the block size so that some time down the track when the pools/miners believe it would be ideal to increase it, that will be possible without the crap that is going on now.

Quote

Whatever vaues, formulas, and schedules the various miners use to set the block size limit, they had better result in the same number, at least for a few months after the forking time.

It does not matter if some miners are running code that accepts 8 MB forever, while others will accept 8 MB until 2018 and then accept 16 MB. Until 2018 they will be in agreement, and until then they may change their software again.

Read BIP100 ... seems you didn't bother to do that ...

Quote

Quote

[ ... ] contrary to the design of Bitcoin. Design changes that drastically reduce transaction free rewards will only result in failure in the long term for any fork using those changes without resolving the problem they cause. The solution is to simply not apply such changes to start with.

Amazing how one can turn the facts so completely upside down.

The design of bitcoin did not have a significant block size limit. Satoshi assumed that the network would never be congested, and all transactions with sufficient fees would be processed in the next block, apart from propagation delays. This assumption was so obvious that it did not even have to be stated explicitly. Only a fool would design a network to be operated in congestion mode.

Only a fool would believe it is already in "congestion mode"
and
Only a fool would look at a design and ignore the implementation.

Quote

Keeping the 1 MB limit until the network becomes congested would be a huge, disastrous change in bitcoin. Some transactions would be delayed for hours or more, no matter what fees they pay.

Your problem is your lack of temporal relevance.

Quote

Increasing the block size limit would be preserving it as it was designed and as it worked for the last 6 years.

Sorry, that '6' you are trying to use as hyperbole fails.
Halving only occurs every ~4 yours ... (210,000 blocks)

Quote

Quote

Bitcoin is designed to shift from block reward to transaction fee reward.

Indeed, but that can be obtained by setting fixed fees that clients know in advance; and clients who pay must get what they paid for.

No it can't.
Nothing controls the fees that pools/miners will accept but each pool/miner themselves.