...

[kano]

Meanwhile

https://bitcointalk.org/index.php?topic=1156489.msg12216919#msg12216919

A few have discussed flagging blocks with /BIP100/ in the last day or so
(yep my pool got one in the last day and flagged it also)

Results:

/BIP100/ already 10%

BIP101 ... about 1% after all this time

damn shame

[HostFat]

@kano
You should pay someone to write the code of the BIP100, because now there isn't.

[kano]

@kano
You should pay someone to write the code of the BIP100, because now there isn't.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010621.html

[sgbett]

Cartoons and graphics sometimes say more than thousand words.
Today I found the truth table in the cyberspace.

paging icebreaker for immediate application of the MP-RDF. These truths cannot be left unFUDed in public!

That yes/no image is incorrect.
If core is the longest chain and someone is stupid enough to mine an XT block that core doesn't allow, then all XT nodes will follow the XT block fork.
Thus if core continues to be the longest chain (which it will) then XT clients will not follow the longest chain possibly until later.

Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume the latter.

BIP101 activates *only* if XT has >75% of hashing power. So once a big block is mined then it doesn't matter if core ignores it, because core doesn't have the hash power to be able to orphan XT blocks by producing a longer chain.

At the point a big block is mined the probability of core being able to produce a longer chain quickly falls to zero. In the first 10 minutes there is a 25% chance, in 20 minutes 6% chance and so on... 1.5%, 0.4%,0.1%. After on hour of XT mining with 75% hashpower there is a 0.02% chance that core has a longer chain. Core is dead in an hour. Thats the real socio-economic incentive, regardless of how many anti-XTers try and claim there isn't one.

If XT doesn't have 75% of hashing power then BIP101 doesn't activate. So both XT and core both continue to mine small blocks and nothing changes.

The chart is quite correct.

[kano]

Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume your stupid.
A few things:
1) blocks can be anywhere from a second to well over an hour, so no, your stats are only theoretical expectations.
2) XT being 75% doesn't mean it can't lose - there's a reason why core uses higher than 75% ...
3) 'XT' have stated they will use block markers to force people to stay on XT and not switch to Core, if however, Core is above 50% and gets ahead of XT, everyone on XT will be royally screwed
4) It only takes one 'XT only' block to be mined to keep everyone using XT off Core

but more importantly, XT wont happen.

[JorgeStolfi]

Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume your stupid.
A few things: [ ... ] but more importantly, XT wont happen.

It is irrelevant which version of the software is being used (Core, XT, or other).  What happens after the first big block is mined depends only on how many miners accept big blocks.  ("Small block" = at most 1 MB; "big block" = more than 1 MB but not more than 8 MB.  See below for BIP100, BIP102, and other complications.)  Note that even the Core version is trivially patched to accept 8 MB blocks.

The chain will (theoretically) split once the first big block B(N) gets mined.  There will be a "big-block" branch that grows on top of that block, containg perhaps other big blocks; and a "small-block" branch that starts with an alternative small block C(N) with the same block number and contains only small blocks.

If, at that moment, more than 50% of the miners accept big blocks, the big-block branch (mined by them) will eventually grow faster than the small-block branch (mined by the rest of the miners).  The split will be permanent and the big-block branch will grow faster.

If, at that moment, less than 50% of the miners accept big blocks, the small-block branch will eventually grow longer.  Then the big-block miners will stop mining their branch, which will be orphaned, and they will start mining the small-block branch too.  If someone mines another big block, the chain will split again.  This situation will repeat over and over, as long as some miner happens to mine a big block.  There will be a single small-block chain with recurrent big-block side branches that are orphaned sooner or later.

Sane bitcoiners should want the first case to happen, and as cleanly as possible: namely, with almost all the miners accepting big blocks.  Then if someone mines a big block, the few stubborn miners who refuse to accept big blocks will be left mining a slow chain with a huge and growing backlog.   In this case, clients who accept big blocks will be fine, while clients who reject them will not be able to use bitcoin until they upgrade.

Blockstream fans who are not totally stupid will want the second case to happen, but also as cleanly as possible: namely, with almost all miners rejecting big blocks.  Then, if someone mines a big block, the few miners who accept it will waste time mining on top of it, only to have that branch orphaned right away.   In this case, all clients will be fine, except that clients who accept big blocks will see occasional big orphans.

Bitcoiners who are stupid, or are into financial sado-masochism (like those who are planning to sabotage the blockchain voting), will try to get some intermediate situation when the miners who accept bitcoin are neither the vast majority nor a small minority.  In this case, the situation will be highly confusing either to the clients who accept big blocks, or tho those who reject them, or possibly for both.

The competing BIPs with other notions of "big block" will make the situation more confusing.  Unless Jeff is into sado-masochism too, he should retract his "compromise" 2 MB proposal.  It is obvious by now that the Blockstream devs will never accept any compromise solution.

[kano]

So you completely missed the entire point of what I said ... the issue is they are using a too low 75% ...

...
BIP101 activates *only* if XT has >75% of hashing power.
...

False.

Bitcoin mining is random statistics.
It's not 10 minutes per block, every block.

Edit: and to give an example:
My pool mined 17 blocks at under 30% difficulty - yep luck was on a roll when that happened.
At the time, if there was any voting happening, for that period of time my pool would have effectively voted at over 300% of it's hash power.

[tvbcof]

Not sure if you are being disingenuous or you really don't understand. I'll give you the benefit of the doubt and assume your stupid.
A few things: [ ... ] but more importantly, XT wont happen.

It is irrelevant which version of the software is being used (Core, XT, or other).  What happens after the first big block is mined depends only on how many miners accept big blocks.  ("Small block" = at most 1 MB; "big block" = more than 1 MB but not more than 8 MB.  See below for BIP100, BIP102, and other complications.)  Note that even the Core version is trivially patched to accept 8 MB blocks.

The chain will (theoretically) split once the first big block B(N) gets mined.  There will be a "big-block" branch that grows on top of that block, containg perhaps other big blocks; and a "small-block" branch that starts with an alternative small block C(N) with the same block number and contains only small blocks.

If, at that moment, more than 50% of the miners accept big blocks, the big-block branch (mined by them) will eventually grow faster than the small-block branch (mined by the rest of the miners).  The split will be permanent and the big-block branch will grow faster.

If, at that moment, less than 50% of the miners accept big blocks, the small-block branch will eventually grow longer.  Then the big-block miners will stop mining their branch, which will be orphaned, and they will start mining the small-block branch too.  If someone mines another big block, the chain will split again.  This situation will repeat over and over, as long as some miner happens to mine a big block.  There will be a single small-block chain with recurrent big-block side branches that are orphaned sooner or later.

Sane bitcoiners should want the first case to happen, and as cleanly as possible: namely, with almost all the miners accepting big blocks.  Then if someone mines a big block, the few stubborn miners who refuse to accept big blocks will be left mining a slow chain with a huge and growing backlog.   In this case, clients who accept big blocks will be fine, while clients who reject them will not be able to use bitcoin until they upgrade.

Blockstream fans who are not totally stupid will want the second case to happen, but also as cleanly as possible: namely, with almost all miners rejecting big blocks.  Then, if someone mines a big block, the few miners who accept it will waste time mining on top of it, only to have that branch orphaned right away.   In this case, all clients will be fine, except that clients who accept big blocks will see occasional big orphans.

Bitcoiners who are stupid, or are into financial sado-masochism (like those who are planning to sabotage the blockchain voting), will try to get some intermediate situation when the miners who accept bitcoin are neither the vast majority nor a small minority.  In this case, the situation will be highly confusing either to the clients who accept big blocks, or tho those who reject them, or possibly for both.

The competing BIPs with other notions of "big block" will make the situation more confusing.  Unless Jeff is into sado-masochism too, he should retract his "compromise" 2 MB proposal.  It is obvious by now that the Blockstream devs will never accept any compromise solution.

Weren't you supposed to be some sort of a comp-sci professor?  I don't know how to be kind about it, but your students are getting screwed...your whole post is chock-full-o'-fail.

Note that to a satoshi-based cyrpto-currency solution the proper terminology is 'longest valid chain'.  Bloat-blocks or any other illegality is simply ignored.  It doens't matter if the chain stretches from here to China.  What this means is that Core would keep right on chunking away even if it got 1% of the hashing (excepting problems with difficulties and absent attacks.)

As for mining, I supposed and Meni Rosenfeld (who, unlike you, actually does understand Bitcoin and algorithms generally) confirmed that the mining effort will be primarily driven by the market value of the product.  I would add that when transaction fees become a factor (hopefully some time before the earth stops cooling on core) they would be added to 'market value.'  Thus, the trajectory of any XT-like alt forked off the Bitcoin blockchain would have to command a high market value relative to Bitcoin in order to attract mining.  It's actually no different than any other sha256 alt (if there are any which still survive.)

The best hope the XT attackers have would be to subsidize the shit out of XT (and probably attack Bitcoin as well) in order to try to get the flame started on mopping up sha256 hashes.  I hope like hell they do because I plan to split my coins and sell XT like hell when the opportunity arises.  With luck it IS the govt spooks who are behind XT and Gavin's various malfeasance because they have deep pockets to do this subsidization and it would be an opportunity to get some of my tax dollars back.

[sAt0sHiFanClub]

So you completely missed the entire point of what I said ... the issue is they are using a too low 75% ...

...
BIP101 activates *only* if XT has >75% of hashing power.
...

False.

Bitcoin mining is random statistics.
It's not 10 minutes per block, every block.

Edit: and to give an example:
My pool mined 17 blocks at under 30% difficulty - yep luck was on a roll when that happened.
At the time, if there was any voting happening, for that period of time my pool would have effectively voted at over 300% of it's hash power.

But that's possible, isn't it? I mean hashing rate is probabilistic.  If you take a narrow sample you can easily find boundary cases proliferate. But then if you take the sample as a whole, then the 'averages' will dominate. While your pool did well for that run of blocks, there had to be another n blocks where the difficulty was over 200%.

So its not random overall.  But any sample will appear to be.

[JorgeStolfi]

Weren't you supposed to be some sort of a comp-sci professor?  I don't know how to be kind about it, but your students are getting screwed...

Indeed. Students who are used to uncritically memorize and repeat what the textbooks say often get screwed in my courses.

Note that to a satoshi-based cyrpto-currency solution the proper terminology is 'longest valid chain'.  Bloat-blocks or any other illegality is simply ignored.

No.  Chains that cointain illegal blocks are ignored only by software that considers such blocks illegal.  But, for players that are running software that accepts big blocks, big blocks are legal.  Is it clear now?

Core would keep right on chunking away even if it got 1% of the hashing (excepting problems with difficulties and absent attacks.)

No, it is not "Core" that will do that, but "any miner who is running software that does not accept big blocks".  That software can be the current Core version, or XT minus the 8 MB patch, or any other independent code with a 1 MB block size limit.  Miners that accept big blocks may be running the current XT (with or without the other patches), or the current Core with an 8 MB patch (by repentant Blockstream devs, or by someone else), or any other version that accepts 8 MB blocks.

That is the main point: the "Core vs XT" and "Blockstream vs Hearn&Gavin" issues are red herrings.  The only thing that really matters is how many miners will accept big blocks at some point in the future.

Ideally, whenever a big block is actually solved and posted, either almost all miners (counted by hashpower) should be accepting big blocks, or almost all miners should be rejecting them.  

If, at some point, 75% of the miners suddenly start accepting big blocks, the other 25% had better start accepting them too.  Ditto if, after every miner is accepting big blocks, 75% suddenly decide to start rejecting them.

If the miners are mostly in agreement about accepting or rejecting big blocks, but a majority changes their mind, in either direction, they had better all change together, before someone posts another big block.  

As long as all miners are mostly in agreement, it is safer for all clients to accept big blocks than to reject them.

If the miners ever get into a messy state, with significant percentages of both big-block acceptors and big-block rejectors, all clients had better stop using bitcoin until the mess gets cleared up, and almost all miners have again converged to the same policy.

the mining effort will be primarily driven by the market value of the product.

The preferences of the "economic majority" will surely influence the miners' decisions.  But, once a significant majority of the miners has decided that they will accept big blocks, after the first big block gets mined the "economic majority" had better be already accepting them too, or start accepting them right away.  While the miners can wait a few weeks before selling their mined coins, the "economic majority" cannot stop using bitcoin for a week, in the hope of winning the strong-arm duel.

Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.

[marcus_of_augustus]

^^^ "Very skeptical of bitcoin's long term success" ^^^ (i.e. actively trolling for it's demise since learning of bitcoin)

... pushing for divisive XT, nuf said.

[kano]

...
Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.
...

Mining has no economic reason to accept unlimited bigger blocks since that represents a loss of income contrary to the design of Bitcoin.

Bitcoin is designed to shift from block reward to transaction fee reward.
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.

The BIP101 hard coded block size growth is also based on an invalid extrapolation, due to insufficient data.

[erik777]

Curious as I am not a coder:

How can we stop DDOS attacks on BTC without blacklisting the DDOS servers (or however this is actually being done)?

There must be a better way than putting in what I can only describe as 1984 Code.

You have to block bad IPs by IP.  The question is HOW you determine what a bad IP is.  If that is a pre-defined list you are asked to "trust", you've introduced discrimination and trust into the network at the same time, both principles counter to Bitcoin freedom -- which is designed to be TRUSTLESS.  This foundational concept is very clear in Satoshi's paper:

"the main benefits are lost if a trusted third party is still required"    

You can, however, detect malicious traffic in real-time, and temporarily lower the priority of that IP.  In this case, you do not trust any third-party to provide IPs, or discriminate against any externally defined group of IPs.  Rather, like "intrusion detection", you trust only what your eyes see right in front of you -- clear evidence that an IP that is currently behaving abusively.  There is no reason bitcoin cannot use intrusion detection techniques to detect malicious traffic. 

Considering it may be a proxy used by legitimate users, you only temporarily lower its priority to permit the misbehaving source to possibly drop off, permitting healthy traffic to be prioritized again once the malicious source drops off.  

We do not need to trust blacklists, whitelists, or any other list in order to combat DDos.  Bitcoin is and must remain a trustless network.

 

[madjules007]

Curious as I am not a coder:

How can we stop DDOS attacks on BTC without blacklisting the DDOS servers (or however this is actually being done)?

There must be a better way than putting in what I can only describe as 1984 Code.

You have to block bad IPs by IP.  The question is HOW you determine what a bad IP is.  If that is a pre-defined list you are asked to "trust", you've introduced discrimination and trust into the network at the same time, both principles counter to Bitcoin freedom -- which is designed to be TRUSTLESS.  This foundational concept is very clear in Satoshi's paper:

"the main benefits are lost if a trusted third party is still required"    

You can, however, detect malicious traffic in real-time, and temporarily lower the priority of that IP.  In this case, you do not trust any third-party to provide IPs, or discriminate against any externally defined group of IPs.  Rather, like "intrusion detection", you trust only what your eyes see right in front of you -- clear evidence that an IP that is currently behaving abusively.  There is no reason bitcoin cannot use intrusion detection techniques to detect malicious traffic. 

Spot on. That's what I see -- there is nothing wrong with deprioritizing traffic that is mounting a DDOS attack. There is something wrong with coding a centralized blacklist into the protocol. Play with semantics all you want, and rationalize how its intent may be noble -- it is a blacklist.

I'm a bit ignorant to the technicals. Does anyone know how much it might cost to mount a somewhat permanent DDOS attack on bitcoin nodes from TOR nodes? Is it conceivable that if the XT fork prevails, under these conditions, that TOR nodes could effectively be blocked from propagating bitcoin transactions? Could this be used to prevent access to dark markets?

Pardon my ignorance if I am being foolish......

[erik777]

I'm a bit ignorant to the technicals. Does anyone know how much it might cost to mount a somewhat permanent DDOS attack on bitcoin nodes from TOR nodes? Is it conceivable that if the XT fork prevails, under these conditions, that TOR nodes could effectively be blocked from propagating bitcoin transactions? Could this be used to prevent access to dark markets?

Even in the best case scenario, if it were used only for DDos, it would effectively shut down shared IPs including Tor exit nodes and proxy servers, impairing innocent users from being able to use them.  

The attraction to TRY to use this to shut down dark markets would be very tempting by those trying to do so, creating an incentive to use DDos to blacklist Tor IPs.  Ironically, this incentive would INCREASE DDos attempts, rather than reduce them.  

To the extent that these parties desire to remove anonymity from Bitcoin, this is a very enabling capability. 

While blacklists might appear on the surface to protect miners from DDos, they create a new avenue of DDos where the target becomes shared IP addresses. 

[tvbcof]

No.  Chains that cointain illegal blocks are ignored only by software that considers such blocks illegal.  But, for players that are running software that accepts big blocks, big blocks are legal.  Is it clear now?

Ya, clear that you selectively editing and are talking nonsense to cover up your mistake (or lack of understanding.)

Core would keep right on chunking away even if it got 1% of the hashing (excepting problems with difficulties and absent attacks.)

No, it is not "Core" that will do that, but "any miner who is running software that does not accept big blocks".  That software can be the current Core version, or XT minus the 8 MB patch, or any other independent code with a 1 MB block size limit.  Miners that accept big blocks may be running the current XT (with or without the other patches), or the current Core with an 8 MB patch (by repentant Blockstream devs, or by someone else), or any other version that accepts 8 MB blocks.

That is the main point: the "Core vs XT" and "Blockstream vs Hearn&Gavin" issues are red herrings.  The only thing that really matters is how many miners will accept big blocks at some point in the future.

Ideally, whenever a big block is actually solved and posted, either almost all miners (counted by hashpower) should be accepting big blocks, or almost all miners should be rejecting them.  

If, at some point, 75% of the miners suddenly start accepting big blocks, the other 25% had better start accepting them too.  Ditto if, after every miner is accepting big blocks, 75% suddenly decide to start rejecting them.

If the miners are mostly in agreement about accepting or rejecting big blocks, but a majority changes their mind, in either direction, they had better all change together, before someone posts another big block.  

As long as all miners are mostly in agreement, it is safer for all clients to accept big blocks than to reject them.

If the miners ever get into a messy state, with significant percentages of both big-block acceptors and big-block rejectors, all clients had better stop using bitcoin until the mess gets cleared up, and almost all miners have again converged to the same policy.

Miners will mine where they can make money.  The effort and hence the difficulties will be less on less valuable forks (or core) so they can mine more per unit time.

Your wishful thinking about how 'miners better follow a lead' is nothing more than that and has no basis in reason and no predictive power of future reality.

I suggest that you consult with someone who knows a little about crypto-currencies and try to pick up some clues.  This might allow you to take a position and maybe you will not always be nervous and uptight about your state sponsored mainstream-land pension.  It may help uncloud your analytical abilities.  Even that might not be enough though.  Frankly speaking, I don't really see that you have the mental horsepower to do well in anything which is at all abstract or requires anticipating the future accurately.

the mining effort will be primarily driven by the market value of the product.

The preferences of the "economic majority" will surely influence the miners' decisions.  But, once a significant majority of the miners has decided that they will accept big blocks, after the first big block gets mined the "economic majority" had better be already accepting them too, or start accepting them right away.  While the miners can wait a few weeks before selling their mined coins, the "economic majority" cannot stop using bitcoin for a week, in the hope of winning the strong-arm duel.

Moreover, the "economic majority" does not have any good reason to reject big blocks, and some very good economic reasons to accept them.

"economic majority" is simply a throw-away buzzword invented to impress the mouth-breathers (but it works on comp-sci proffesors also it looks like.)

I will tell you that my own gauge of the value of core Bitcoins will _increase_ if/when the XT drones are led away by some pied piper.  I doubt that I am alone among hodlers in this.  If so, the value of core Bitcoins might hold up surprisingly well and any miners who had been throwing hashes at XT (or some other similar alt fork) will come rapidly back.

[JorgeStolfi]

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.  Then adoption will drop, public image will be in sambles, and the price will probably crash.  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.)

"Big blocks" does not mean unlimited block size.  For practical programming and resource planning reasons, the block size limit must be fairly constant and not too big.  At present, 2 MB would be sufficient to avoid congestion for another year or two, but would offer little protection against spam attacks.  The popular 8 MB limit would be good for several years.

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.

[ ... ] 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.

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.

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

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.

[kano]

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

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 ...

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.

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 ...

[ ... ] 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.

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.

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)

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.

[sAt0sHiFanClub]

We do need to have in place shortly the ability to increase the block size....

And thats what is happening - no argument there.

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.

So its just a question of scheduling? Fair enough. But if the larger portion of Miners and Pools want them sooner than you, you will support them, right?

[favdesu]

locking out people from the blockchain is unbearable. I hope XT won't see consensus...