.

[blunderer]

...
I'll tell you a little secret: Blocks will never be full on average. Even if we cap it to 100KB.

If you think that means we don't have a problem then there's not much more to say.

You mean roads are often widened *before* there's a traffic jam 24/7/365? But until all the lanes are bumper-to-bumper 24/7/365, the road isn't even at 100% capacity yet

[figmentofmyass]

So tell me, Bitcoin: The Peer-to-Peer Electronic Cash System was designed to "cut out third party middleman (e.g. Visa)" out of WHAT?
Clearly not shopping, because a single suburban shopping mall would overload the network, so it's not suitable for shopping.
At least, according to you.

it was designed to "cut out third party middleman (e.g. Visa)" from transactions between two parties. satoshi put it this way: "the main
benefits are lost if a trusted third party is still required to prevent double-spending."

Let me simplify this for you:
"Transactions between two parties" in which a "third party middleman (e.g. Visa)" may be involved, are CALLED "SHOPPING" by normal people. Possibly "paying Bills," if you're dead broke.
What else do you do with Visa?
A suburban shopping mall's worth of transactions is enough to overwhelm the Bitcoin network in its current state, so 3 "transactions  between two parties" per second is clearly not enough.
What is it that you object to?

i'm not sure what the definition of "shopping" has to do with the statement that bitcoin was intended to cut third parties out value transactions.

clearly not enough for what? what is the basis for comparison? is there another decentralized p2p system that eliminates third party trust, because that would be a more adequate comparison than a shopping mall.

i'm perfectly content to keep using Visa to go shopping.

Visa DOES lend me the money, regardless of where the money comes from. If Visa chooses to reverse the payment I've made when I filled my tank & paid with Visa, explain to me what happens?

the merchant (the gas station) gets screwed out of their money. the point of irreversible payments is to prevent this.

Has Visa ever reversed the payment you've made with (your own, not carded) Visa? How did that go?

i've charged back against a merchant that did not provide the contracted services and refused to issue a refund. he'd rather i was unable to do that.

if "letting bitcoin grow" =/= sacrificing decentralization, i'm with ya. but there have been compelling arguments made that increasing block size with the current infrastructure will sacrifice decentralization.

If by "compelling arguments" you mean inane drivel & blatant lies, I'm with ya too.

okay. i'll match your opinion with the opinion that the Classic camp has only brought "inane drivel & blatant lies."

[figmentofmyass]

I'll tell you a little secret: Blocks will never be full on average. Even if we cap it to 100KB.

If you think that means we don't have a problem then there's not much more to say.

average is simply a metric to filter out noise. by your logic, increasing the block size was urgent years ago when the first nearly-full block was mined. yet, we've continued to have a robust system that keeps chugging along, and fees are still cheap as fuck.

what proof do you have that there is actually an urgent problem?

[figmentofmyass]

You mean roads are often widened *before* there's a traffic jam 24/7/365? But until all the lanes are bumper-to-bumper 24/7/365, the road isn't even at 100% capacity yet

what proof do you have that there will be "a traffic jam 24/7/365?" because there's a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks?

the horror!

[blunderer]

You mean roads are often widened *before* there's a traffic jam 24/7/365? But until all the lanes are bumper-to-bumper 24/7/365, the road isn't even at 100% capacity yet

what proof do you have that there will be "a traffic jam 24/7/365?" because there's a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks?

the horror!

Where have I suggested there'll be "a traffic jam 24/7/365"?
On the contrary, my point was such traffic jams are almost impossible, and the most congested of roads, the ones where you sit in traffic for hours during rush hours? Those roads are, on the average, operating at less than 50% capacity.

Thus, 50% average doesn't imply that the traffic is not at a standstill during rush hours, that the road has 50% excess capacity, or that it doesn't need to be widened.

This should be obvious to an average 7-year-old, so assuming you're trolling.

[figmentofmyass]

You mean roads are often widened *before* there's a traffic jam 24/7/365? But until all the lanes are bumper-to-bumper 24/7/365, the road isn't even at 100% capacity yet

what proof do you have that there will be "a traffic jam 24/7/365?" because there's a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks?

the horror!

Where have I suggested there'll be "a traffic jam 24/7/365"?

you said, "You mean roads are often widened *before* there's a traffic jam 24/7/365?" suggesting that this might actually happen.

On the contrary, my point was such traffic jams are almost impossible, and the most congested of roads, the ones where you sit in traffic for hours during rush hours? Those roads are, on the average, operating at less than 50% capacity.

Thus, 50% average doesn't imply that the traffic is not at a standstill during rush hours, that the road has 50% excess capacity, or that it doesn't need to be widened.

what do your musings about traffic jams have to do with bitcoin transactions? how does "a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks" = a traffic jam? if it does, what's the problem?

This should be obvious to an average 7-year-old, so assuming you're trolling.

nope, just think you should justify the comparison. youre suggesting that there is some urgent problem with bitcoin, but you can't seem to provide any evidence of it aside from irrelevant comparisons to traffic jams

[blunderer]

You mean roads are often widened *before* there's a traffic jam 24/7/365? But until all the lanes are bumper-to-bumper 24/7/365, the road isn't even at 100% capacity yet

what proof do you have that there will be "a traffic jam 24/7/365?" because there's a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks?

the horror!

Where have I suggested there'll be "a traffic jam 24/7/365"?

you said, "You mean roads are often widened *before* there's a traffic jam 24/7/365?" suggesting that this might actually happen.

On the contrary, my point was such traffic jams are almost impossible, and the most congested of roads, the ones where you sit in traffic for hours during rush hours? Those roads are, on the average, operating at less than 50% capacity.

Thus, 50% average doesn't imply that the traffic is not at a standstill during rush hours, that the road has 50% excess capacity, or that it doesn't need to be widened.

what do your musings about traffic jams have to do with bitcoin transactions? how does "a bunch of unconfirmed transactions that are eventually cleared from the mempool and included in blocks" = a traffic jam? if it does, what's the problem?

This should be obvious to an average 7-year-old, so assuming you're trolling.

nope, just think you should justify the comparison. youre suggesting that there is some urgent problem with bitcoin, but you can't seem to provide any evidence of it aside from irrelevant comparisons to traffic jams

Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!
TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

[Cuidler]

We can wait for Bitcoin to become very hard to use when people constantly sends more transactions than can even be included in blockchain, also know as denial of service attack, but this will erode a lot of trust in Bitcoin as well, very likely beyond repair. So not much safer choice eighter - unless you believe people will be happy to use Bitcoin with 1) huge fees, 2) long 1st confirmation times 3) never confimed transactions. I dont know of any coin with restricted blocksizes so people can hardly use it, yet very popular and people eager to use this coin 

any evidence for this "sky is falling" attitude? any evidence of huge fees? what is "huge?" i've always been able to get my transaction in the next block for minimal fees.

bitcoin has "restricted blocksizes" yet, it is "very popular and people [are] eager to use this coin."

I see common mistake of small blockers to dont have any imagination at all what future might look like. With "restricted blocksizes" I obviously meant artifically restricted blocksize way below constant demand.

[figmentofmyass]

Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!
TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

[jonald_fyookball]

Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!
TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

Lets say for the sake of argument that you're right.

Transactions are still growing.  Do we really need an "urgent problem"?  Why not be prudent and increase the blocksize already?
Feel like im taking crazy pills here.

[AliceWonderMiscreations]

Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!
TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

Lets say for the sake of argument that you're right.

Transactions are still growing.  Do we really need an "urgent problem"?  Why not be prudent and increase the blocksize already?
Feel like im taking crazy pills here.

Increasing transaction rate is what is needed. Increasing block size is one way to do that, but not the only way to do that.

Why do you feel increasing block size is better than the solution that core developers have actual working code for, currently in testing, that does not require a hard fork?

[jonald_fyookball]

Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!
TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

Lets say for the sake of argument that you're right.

Transactions are still growing.  Do we really need an "urgent problem"?  Why not be prudent and increase the blocksize already?
Feel like im taking crazy pills here.

Increasing transaction rate is what is needed. Increasing block size is one way to do that, but not the only way to do that.

Why do you feel increasing block size is better than the solution that core developers have actual working code for, currently in testing, that does not require a hard fork?

I agree its not the only way to do it.

To answer your question, its better because its simpler and more robust. Faster and easier to implement.
A blocksize increase will be required sooner or later so the fact that a hard fork is part of it, is not a reason not to do it (since its necessity is inevitable).

And a question to you: Why NOT do it now, since an increase to 2MB is likely harmless, and
the community is loudly demanding it, to the point where contentious forks are possible.

[AliceWonderMiscreations]

I would prefer to not do it now because increasing the block size requires a hard fork and hard forks should only happen when there really isn't another solution.

Yes at some point it will be needed even with SegWit - do it then. There is no point to doing it now, most blocks are not full and it is cheap to get your TX seen quickly.

[blunderer]

Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!
TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

You were "referring to the actual growth in transaction volume (therefore block size) over time"? How does the fact that "blocks aren't actually full on average" figure into this? Taking into account that it's as likely for blocks to be "full on average" as it is for the busiest road to be bumper-to-bumper jammed, on the average, which is to say "not at all"?
Why bring up a meaningless metric?
At the risk of belaboring the obvious: Blocks will never be "full on average." Don't wait for blocks to be full on the average.

>since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
If you're stuck in traffic for 6 hours on your way back from work, what's the problem? I mean, you get home eventually, every day, amirite?
The road is clearly of sufficient capacity, no one *never* gets home. In other words, "traffic jams transactions backlogs are always cleared."

[jonald_fyookball]

I would prefer to not do it now because increasing the block size requires a hard fork and hard forks should only happen when there really isn't another solution.

Yes at some point it will be needed even with SegWit - do it then. There is no point to doing it now, most blocks are not full and it is cheap to get your TX seen quickly.

There is absolutely a point to doing it now.

here's why:

1. Look at the graph.  We've went from .3 to .65 in 12 months.
https://blockchain.info/charts/avg-block-size?timespan=1year&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

Assuming Bitcoin is the awesome distrupting technology a lot of say it is, and want it to be,
we should be expecting exponential growth.  Could quadruple in the NEXT 12 months.

2. It takes many months to safely do a hardfork.

So, given those two  points, really makes sense to do it now.

Plus consider this:

You can make the argument that segwit is going
to buy us plenty of time (questionable), but that I don't see
any benefit of waiting to fork.   Why is doing it later better or
less risky than doing it now?  If anything its going to
be much more risky to rush the hard fork by waiting
till its an urgent problem.  Don't you agree?

[David Rabahy]

As confirmation times and fees rise adoption stalls or worse declines leading to less workload; self-regulation.  The appearance will be that we're ok and in a sense we are but is this our vision?

Hurry up and get SegWit out *but* that fundamentally cannot be the end of the story, right?

Perhaps we should practice hard forking, e.g. 1.1MB, just to get use to it.  Hmm, or are we saying we never want a hard fork ever again?

[David Rabahy]

Whatever; I've installed classic -- whee.

[VeritasSapere]

Before this deteriorates any further, try to stay focused.
Don't break this up into a zillion sub-topics, with each word I type addressed in a separate catty comeback.
inb4 not a zillion: no. stay focused. resist. We want one cogent, cohesive response, even if you miss out on a few snark opportunities.

Now then: My traffic analogy.
It's fucking great, no sense being coy about it. Unoriginal, sure -- network traffic is typically visualized/modeled/ in terms of everyday meatspace traffic.b What don't you like about the analogy?

it's not that i don't like it. it's that you haven't shown how it's applicable. what evidence do you have that there is such a "traffic jam" or if there is, that it is an actual problem?

Which seamlessly segues us to the main thrust of this opus. Pay attention, 'coz what's coming up is the only important bit. Up 'til now, it was fluff, sort'a like what you did to me with your gudxillion sub-quotes.
Enough! Reader, follow me!
TehGist:
1. You made a claim that "blocks aren't actually full on average."
2. I replied that while this is the case, it is impossible for things to be otherwise -- blocks *can never be 100% full on the average*.
3. If analogies are a strain (abstract thought could be a bitch for some), here's the actual mechanics: as long as a miner is able to mine an empty block, the average can't be 100% full blocks. Because that's how averages fucking are. That's how they work.

I hope this helps.

i was referring to the actual growth in transaction volume (therefore block size) over time. i'd have thought this would be obvious. seems relevant to your suggestion that capacity is insufficient. there is a tendency to point to short term batches of 9xx kb blocks, then to ignore the 400-600 kb blocks that come after the backlog has cleared.

the network actually isn't under the constant load that some suggest, and during the times that it temporarily is, paying an extra tiny fraction of an mBTC in fees alleviates the issue.

anyway, this has nothing to do with evidence of your suggestion that there is an urgent problem here. since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?

You were "referring to the actual growth in transaction volume (therefore block size) over time"? How does the fact that "blocks aren't actually full on average" figure into this? Taking into account that it's as likely for blocks to be "full on average" as it is for the busiest road to be bumper-to-bumper jammed, on the average, which is to say "not at all"?
Why bring up a meaningless metric?
At the risk of belaboring the obvious: Blocks will never be "full on average." Don't wait for blocks to be full on the average.

>since the transactions backlogs are always cleared and fees are miniscule, what's the problem again?
If you're stuck in traffic for 6 hours on your way back from work, what's the problem? I mean, you get home eventually, every day, amirite?
The road is clearly of sufficient capacity, no one *never* gets home. In other words, "traffic jams transactions backlogs are always cleared."

I like the analogy, however in the case of Bitcoin there is simply not enough capacity for everyone to get "home", regardless of the fee that is payed.

Furthermore as a counter argument, if we imagine this road being like a toll road, then we can say that other roads exists, in the form of potential Bitcoin forks and altcoins. If the other roads are both faster and cheaper then I think people will choose to drive on those alternative roads instead, the economics of it all are quite simple really when it comes down to it. I think that if we allow the Bitcoin network to become overloaded making transacting much more expensive and unreliable then I think Bitcoin will simply be outcompeted and obsolesced.

I am glad you installed Bitcoin Classic David Rabahy, that is the solution to this existential crisis after all.

[David Rabahy]

I am glad you installed Bitcoin Classic David Rabahy, that is the solution to this existential crisis after all.

It's good to know someone around here has a sense of humor.  I was almost inspired to run both Classis and Core at the same time.  Almost.  I'd like a version which alternates between them. 

[VeritasSapere]

I am glad you installed Bitcoin Classic David Rabahy, that is the solution to this existential crisis after all.

It's good to know someone around here has a sense of humor.  I was almost inspired to run both Classis and Core at the same time.  Almost.  I'd like a version which alternates between them.  

You can always run Bitcoin Unlimited as well, it is my preferred implementation, it is compatible with any block size increase or decrease depending on how the user configures the node. On the default setting it will simply follow the longest chain. That way you could switch between different blocksize policies within the same node if you would like as well.

http://www.bitcoinunlimited.info/