Gold collapsing. Bitcoin UP.

[iCEBREAKER]

Misrepresenting my position then arguing against that isn't going to cut it.

I said the problem is that the block size is too small, and that the solution is to make the block size bigger. That doing this requires no additional functionality. I contrasted this to the sidechain solution which does require additional functionality. As you rightly say nobody is claiming that is entirely the solution, but that is irrelevant, the point is that this or other solution(s) that require extra functionality are the very thing that your Tanenbaum quote warns against.

All that stuff you said about how we need to change TX size, thats some other thing. Either you are intentionally conflating the two, which is disingenuous or you really can't tell the difference, which I doubt is the case.

It looks to me like your emotional attachment to your position is causing your reasoning to become irrational. I don't think anyone's argument is absurd. I can see how enforcing higher fees benefits some parties, I think that misses the big picture which is that it *requires* additional functionality.

I'm not frightened of pissing contests, I think they are childish. You don't need to "fight" anything. As a smart human being we all need to listen, think and reason. Not inject hyperbole, and inflammatory language into posts to try and bully your opposition. Your argument should stand on its own merit and not the vehemence with which it is delivered.

We do need to "fight" features.  Tannenbaum's maxim is a restatement of the KISS principle.  I don't care if you can't see or won't accept that because of your economic illiteracy and a priori attachment to the absurd Red Queen interpretation.  The fight is happening (with your participation) whether you like it or not, mooting your objections.

I'm not "misrepresenting" your position.  The problem is that you don't understand your own position.   

"Contrived" 1MB tx bog down the network and present an attack vector.  8MB tx would 8^2 times worse, and thus the added complexity/functionality of larger blocks is demonstrated (your feeble speculative whining about my "emotional attachment" notwithstanding).

This is Sergio's conclusion; and Gavin's (present) ad hoc workaround is to marry (IE "conflate") a 100k tx size limit to any blocksize increase. 

Let me be clear because you are a slow learner: The intentional conflation of 100k tx size limits and larger blocks is Gavin's quasi-solution to the additional functionality/complexity required by larger blocks, not my "disingenuous" personal interpretation.  You were completely wrong about that (among other things).

What frightens me is that the whole thing seems to have turned into a pissing contest.

I'm not frightened of pissing contests

If you could stop contradicting yourself, that would be great. 

[1713594478]

1713594478

[1713594478]

1713594478

[1713594478]

1713594478

[Ivanhoe]

What frightens me is that the whole thing seems to have turned into a pissing contest.

I'm not frightened of pissing contests

If you could stop contradicting yourself, that would be great.  

He isn't contradicting himself.

[thezerg]

Unfortunately for money to have store of value efficiency it must ultimately have value which with bitcoin rests again on its currency efficiency.

Miners could only store non dust UTXOs in easily accessible storage and ignore incoming txns that spend them unless the fee is worth the cost to look the UTXOs up. There are so many possibilities.   Your problem is that you are a central planner even tho you dont know it -- you are forcing a particular solution (expensive limited txns) onto the network as a whole.

Gold's example disagrees with your assertion.  Gold used to be an efficient currency, and is now a store of value.  Bitcoin is, by design, following this path.

I am in no position to "force" anything onto the network has a whole, especially not a particular solution.  You need to calm down and stop exaggerating.  

Gold is unique and was the most efficient soln for thousands of years cementing its social perception of value.  Bitcoin at 1mb is more like the iphone.  It will be outcompeted in price (efficiency) before the majority of the world was even introduced to smartphones with the obvious result that the majority of phones are android.

Obviously I know you are not in a position to effect change.   But my point is that if you were your decision to force a fee market is a centralized solution.   Real markets evolve spontaneously and in a P2P manner to address real issues.

[smooth]

decision to force a fee market is a centralized solution

On it's face this is a nonsense argument since any development decisions are centralized in the same manner.

Increase the blocksize, decrease the blocksize, or leave it alone, they are all (centralized) development decisions.

It's also false that anything is really centralized about it because if there were truly a consensus for change (over the objections of the 'centralized' developers) there would be a successful fork.

[brg444]

Unfortunately for money to have store of value efficiency it must ultimately have value which with bitcoin rests again on its currency efficiency.

Miners could only store non dust UTXOs in easily accessible storage and ignore incoming txns that spend them unless the fee is worth the cost to look the UTXOs up. There are so many possibilities.   Your problem is that you are a central planner even tho you dont know it -- you are forcing a particular solution (expensive limited txns) onto the network as a whole.

Gold's example disagrees with your assertion.  Gold used to be an efficient currency, and is now a store of value.  Bitcoin is, by design, following this path.

I am in no position to "force" anything onto the network has a whole, especially not a particular solution.  You need to calm down and stop exaggerating.  

Gold is unique and was the most efficient soln for thousands of years cementing its social perception of value.  Bitcoin at 1mb is more like the iphone.  It will be outcompeted in price (efficiency) before the majority of the world was even introduced to smartphones with the obvious result that the majority of phones are android.

Obviously I know you are not in a position to effect change.   But my point is that if you were your decision to force a fee market is a centralized solution.   Real markets evolve spontaneously and in a P2P manner to address real issues.

I assume from this post you are for completely lifting the limit, are you?

[iCEBREAKER]

Unfortunately for money to have store of value efficiency it must ultimately have value which with bitcoin rests again on its currency efficiency.

Miners could only store non dust UTXOs in easily accessible storage and ignore incoming txns that spend them unless the fee is worth the cost to look the UTXOs up. There are so many possibilities.   Your problem is that you are a central planner even tho you dont know it -- you are forcing a particular solution (expensive limited txns) onto the network as a whole.

Gold's example disagrees with your assertion.  Gold used to be an efficient currency, and is now a store of value.  Bitcoin is, by design, following this path.

I am in no position to "force" anything onto the network has a whole, especially not a particular solution.  You need to calm down and stop exaggerating.  

Gold is unique and was the most efficient soln for thousands of years cementing its social perception of value.  Bitcoin at 1mb is more like the iphone.  It will be outcompeted in price (efficiency) before the majority of the world was even introduced to smartphones with the obvious result that the majority of phones are android.

Obviously I know you are not in a position to effect change.   But my point is that if you were your decision to force a fee market is a centralized solution.   Real markets evolve spontaneously and in a P2P manner to address real issues.

Gold is not unique.  Silver.  QED.

Why do you speak of "fee market" in the singular?

Do you not understand  on- and off-chain fee markets will exist at Layers 1 and 2+, competing to be more efficient at bundling tx for eventual reconciliation with and inclusion into the Mother Blockchain?

You seem to, with the reference to the fact that "real markets evolve spontaneously and in a P2P manner to address real issues."

How does simply staying at 1MB (and rejecting the Red Queen interpretation) preclude such real markets' spontaneous evolution?

By what logic do you conflate a dearth of consensus for increased blocksize with "a centralized solution?"

[iCEBREAKER]

decision to force a fee market is a centralized solution

On it's face this is a nonsense argument since any development decisions are centralized in the same manner.

Increase the blocksize, decrease the blocksize, or leave it alone, they are all (centralized) development decisions.

It's also false that anything is really centralized about it because if there were truly a consensus for change (over the objections of the 'centralized' developers) there would be a successful fork.

Your mistake here is assuming the Gavinistas have any interest in, much less the ability to, participate in an honest debate, whereby they apply the same criticisms and expectations they put upon Team Core to themselves and their own goal of larger blocks.

They have yet to demonstrate any such interest, nor the ability in terms of intellectual consistency required to develop one.

Instead we get the exquisite hypocrisy of selective outrage (aimed only at Team Core), Chicken Little Sky-Is-Falling panic, and endless exaggeration.  Not to mention the near-daily Two Minutes Hate directed at the devs responsible for scaling Bitcoin all the way up to 1MB.

[OROBTC]

...

iCEBREAKER

Gold <> silver for many reasons.  Examples:

-- Silver is heavily used in a huge variety of industries and products (what, 50 ounces per Tomahawk missile as an example)
-- The central banks do not store silver
-- Even in the Bible gold signifies power, silver signifies money
-- People fleeing across borders carry gold, not silver

And:

In a SHTF, silver will buy you bread.  Gold will buy you the bakery.

[iCEBREAKER]

Gold <> silver for many reasons.  Examples:

-- Silver is heavily used in a huge variety of industries and products (what, 50 ounces per Tomahawk missile as an example)
-- The central banks do not store silver
-- Even in the Bible gold signifies power, silver signifies money
-- People fleeing across borders carry gold, not silver

And:

In a SHTF, silver will buy you bread.  Gold will buy you the bakery.

I like your pithy last two sentences, and so am willing to go out into the weeds with you.   

I know gold <> silver.  They are, of course, different elements (though in the same periodic column as copper for some ineffable, though demonstrably elegant, reason).

My point is that gold's role as a currency-cum-store-of-value is not *absolutely* unique.  Indeed, silver pre- (or co-) dates gold as the favorite metal which meets Artistotle's 'good money' criteria.

People fleeing across borders carry whatever hard assets are available, be it gold, silver, diamonds, goats, art, Bitcoin, or Monero.  I concede gold is the canonical example, but not any kind of singular status for it.

Central banks used to store silver, and I find the current situation anomalous.  In Mother India (and other Buddhist lands like Vietnam and Thailand) silver never lost its role in wealth preservation (despite the best efforts of the NY/London/Paris/Basel banksters and their standing armies).

[solex]

Your mistake here is assuming the Gavinistas have any interest in, much less the ability to, participate in an honest debate, whereby they apply the same criticisms and expectations they put upon Team Core to themselves and their own goal of larger blocks.

They have yet to demonstrate any such interest, nor the ability in terms of intellectual consistency required to develop one.

This is a blatant rewrite of history. Misrepresenting opposing positions is your speciality.
Gavin did a series of blog posts about why on-chain scaling is necessary, and the pros and cons of the change to make this feasible.
Satoshi made it perfectly clear in several posts that he wanted VISA-scale volumes on-chain, and the limit was temporary.
Jeff has written a blog post to go with BIP 100 explaining his perspective. Rusty Russell and David Hudson have also made it clear how scaling is needed and why.

It is Core Dev who take the position that it is premature, too risky, want to force higher fees (too bad for ordinary users) etc etc.
They offer no alternative which is viable before the 1MB causes major problems to the ecosystem growth. LN is complex and too late, and unanswered questions remain about how decentralised its servers will be.

1MB will cripple Bitcoin. The Chinese miners know this and that is why we have >50% of the hashing power behind an open letter saying blocks up to 8MB are OK.
The 1MBers stick their heads into the sand by pretending that a problem of the near future does not exist.

It is also hypocritical to pump Monero based on it able to scale by supporting blocks >1MB. And it is irrelevant what year someone learned about Bitcoin to their being able to execute a trade on the knowledge of one coin potentially having crippled volumes and another not.

IBLT is a known change which can help a lot with decentralised scaling.

IBLT is still somewhere between whitepaper and prototype, and won't really help scale until blocks are ~100s of MB.

According to Gavin, the relay network already plucked the low-hanging fruit for the short and medium term future:

TODO: measure Matt's approach against an IBLT approach. My guess is at small block sizes the simpler approach works better, but at some point IBLTs win.

Gavin says "Network usage should get cut in half as soon as we stop doing the simplest thing and re-broadcasting transactions twice."
http://gavintech.blogspot.co.nz/?view=classic

He means using IBLT, and IBLT is so powerful that it can squeeze a 100MB new block announcement into 1MB, the size in use today. It is also less work overall than LN or SC. i.e. simplest.

It does need prototyping, testing and benchmarking, and the breakeven point is unknown. But like JR's node services payment channels, it is a Cinderella of software where the focus of attention is mostly elsewhere.

[iCEBREAKER]

Satoshi made it perfectly clear in several posts that he wanted VISA-scale scaling on-chain, and the limit was temporary.

Satoshi's role(s) predated the point at which (big-B) Bitcoin-the-currency and (small-b) bitcoin-the-technology bifurcated.  It is crucially important to read his Holy Words in that context.  His Holy Comments on dot.bit/Namecoin ("Piling every proof-of-work quorum system in the world into one dataset doesn't scale.") are instrumental in such an exercise.

LN is complex and too late, and unanswered questions remain about how decentralised its servers will be.

You are assuming condemnatory facts not in evidence (a discourtesy you most pointedly do not extend to IBLT vaporware).

1MB will cripple Bitcoin.

You are assuming condemnatory facts not in evidence (a discourtesy you most pointedly do not extend to IBLT vaporware).

IBLT is so powerful that it can squeeze a 100MB new block announcement into 1MB, the size in use today. It is also less work overall than LN or SC. i.e. simplest.

You are assuming exculpatory facts not in evidence (a courtesy you most pointedly extend solely to IBLT vaporware).

[justusranvier]

It is also hypocritical to pump Monero

Allowing altcoin discussion on bitcointalk is one of the two biggest reasons this forum is largely unusable (the other one being signature ads).

[gmaxwell]

Gavin says "Network usage should get cut in half as soon as we stop doing the simplest thing and re-broadcasting transactions twice."
http://gavintech.blogspot.co.nz/?view=classic

He means using IBLT, and IBLT is so powerful that it can squeeze a 100MB new block announcement into 1MB, the size in use today. It is also less work overall than LN or SC. i.e. simplest.

It does need prototyping, testing and benchmarking, and the breakeven point is unknown. But like JR's node services payment channels, it is a Cinderella of software where the focus of attention is mostly elsewhere.

We have the block relay network protocol already. It avoids repetition of data for anyone who wants to use it (each already known transaction is replaced with a two byte reference. A 1MB block takes about 4000 bytes at relay time when all the transactions were well broadcast in advance.

Gavin's own comments was that IBLT probably doesn't not make sense with blocks under "hundreds of megabytes":
09:49 < gavinandresen> morcos: e.g. the IBLT work really doesn’t make any sense until blocks are in the hundreds of megabytes size range.
Given my expirence with an attempted implementation of the earlier block network coding proposal, I wouldn't be shocked to find there was no size at which using set reconciliation over the whole block was a win for normal connectivity and normal CPU speeds (as opposed to things like sattelite connectivity) though we won't know for sure until its implemented.  

Regardless, the data still has to be sent a first time-- which is why in terms of overall capacity (rather than latency) the greatest improvement available from fancier relay is a doubling of capacity from eliminating double transmission-- and this is the case with both IBLT and the relay network protocol. The relay network protocol reduces some bad incentives in mining (e.g. mining without validating or mining empty blocks for faster relay) but it not a silver bullet, nor is IBLT. (Though it does have the advantage of being simple, already existing, avoids some bad incentives against including censored transactions, and likely being much faster than IBLT for current block sizes: Already the relay network protocol is CPU bottlenecked with much of its delay just computing the hashtree (even with a fancy AVX sha256 implementation in the client)).  (At least for large block reed solomon codes, it appears even highly optimized implementations cannot run faster than a few megabits per second on current CPUs... the fountain code like IBLTs should be somewhat faster, but it's unclear how much, especially when operating at near their recovery limit--- the IBLT also requires a CreateNewBlock in the reciever which is currently slower than the whole block-relay-network-process...)

Lightning network and sidechains are not magical things, they're orthorgonal and not alternatives to relay improvements. But since you bring them up: They're both at a _futher_ level of development than IBLT at the moment; though given the orthogonality it's irrelevant except to note how misdirected your argument is...

[iCEBREAKER]

It is also hypocritical to pump Monero

Allowing altcoin discussion on bitcointalk is one of the two biggest reasons this forum is largely unusable (the other one being signature ads).

Yes, all of Satoshi's posts about dotbit/Namecoin are 100% OFF-TOPIC and should be moderated.   

*makes justusranvier a copy of the Butthurt Report Form*

[solex]

Lightning network and sidechains are not magical things, they're orthorgonal and not alternatives to relay improvements. But since you bring them up: They're both at a _futher_ level of development than IBLT at the moment; though given the orthogonality it's irrelevant except to note how misdirected your argument is...

I appreciate the further detail that you describe regarding the relay situation. So it seems that you are not optimistic that block propagation efficiency can have a major benefit for all full-nodes in the near future. Yet block propagation overhead is probably the single biggest argument for retaining the 1MB as long as possible. To cap volume growth to a certain extent.

I know that Lightning network and sidechains are orthogonal and not alternatives to relay improvements. However, I did not bring them up as a solution to dealing with the 1MB. Mentioning LN just now was prompted by Icebreaker's opinion that the prospect of LN is part of the reason why the 1MB should be left in place for some more years.
For the record. I like LN, I like its potential and I hope it succeeds.

what's your position on block size limit, never change it or change (in the way you like the most) in the future?

I agree with Satoshi, change it "eventually" sometime in the next ~5 years (after optimization by sidechains/LN and fee markets mature).

"Eventually" will be when we see actual congestion (competitive fees no longer prioritizing tx) or the network otherwise being harmed by the Holy 1MB crapflood regulator.

Accommodating more 'cosmic background spam' with a permanent home in the Mother Chain is the worst reason ever for increasing blocksize.

BTW. Well done implementing BIP 66 the way you did.

[domob]

Lightning network and sidechains are not magical things, they're orthorgonal and not alternatives to relay improvements. But since you bring them up: They're both at a _futher_ level of development than IBLT at the moment; though given the orthogonality it's irrelevant except to note how misdirected your argument is...

I appreciate the further detail that you describe regarding the relay situation. So it seems that you are not optimistic that block propagation efficiency can have a major benefit for all full-nodes in the near future. Yet block propagation overhead is probably the single biggest argument for retaining the 1MB as long as possible. To cap volume growth to a certain extent.

I'm not sure about that.  My opinion is that the biggest argument for retaining the cap (or, at least, not introducing a 20x plus exponential increase or something like that) is the burden on full nodes due to (cumulated) bandwidth, processing power and, last but not least, disk space required.  Of course, for miners the situation may be different - but from my own point of view (running multiple full nodes for various things but not mining) the block relay issue is not so important.  As gmaxwell pointed out, except for reducing latency when a block is found it does only "little" by, at best, halving the total bandwidth required.  Compare this to the proposed 20x or 8x increase in the block size.

[solex]

Lightning network and sidechains are not magical things, they're orthorgonal and not alternatives to relay improvements. But since you bring them up: They're both at a _futher_ level of development than IBLT at the moment; though given the orthogonality it's irrelevant except to note how misdirected your argument is...

I appreciate the further detail that you describe regarding the relay situation. So it seems that you are not optimistic that block propagation efficiency can have a major benefit for all full-nodes in the near future. Yet block propagation overhead is probably the single biggest argument for retaining the 1MB as long as possible. To cap volume growth to a certain extent.

I'm not sure about that.  My opinion is that the biggest argument for retaining the cap (or, at least, not introducing a 20x plus exponential increase or something like that) is the burden on full nodes due to (cumulated) bandwidth, processing power and, last but not least, disk space required.  Of course, for miners the situation may be different - but from my own point of view (running multiple full nodes for various things but not mining) the block relay issue is not so important.  As gmaxwell pointed out, except for reducing latency when a block is found it does only "little" by, at best, halving the total bandwidth required.  Compare this to the proposed 20x or 8x increase in the block size.

Bandwidth is always a much bigger concern than blockchain usage on disk. TB disks are very cheap, v0.11 has pruning.

[domob]

Lightning network and sidechains are not magical things, they're orthorgonal and not alternatives to relay improvements. But since you bring them up: They're both at a _futher_ level of development than IBLT at the moment; though given the orthogonality it's irrelevant except to note how misdirected your argument is...

I appreciate the further detail that you describe regarding the relay situation. So it seems that you are not optimistic that block propagation efficiency can have a major benefit for all full-nodes in the near future. Yet block propagation overhead is probably the single biggest argument for retaining the 1MB as long as possible. To cap volume growth to a certain extent.

I'm not sure about that.  My opinion is that the biggest argument for retaining the cap (or, at least, not introducing a 20x plus exponential increase or something like that) is the burden on full nodes due to (cumulated) bandwidth, processing power and, last but not least, disk space required.  Of course, for miners the situation may be different - but from my own point of view (running multiple full nodes for various things but not mining) the block relay issue is not so important.  As gmaxwell pointed out, except for reducing latency when a block is found it does only "little" by, at best, halving the total bandwidth required.  Compare this to the proposed 20x or 8x increase in the block size.

Bandwidth is always a much bigger concern than blockchain usage on disk. TB disks are very cheap, v0.11 has pruning.

This may be true in general, but for the particular hosting company where I run my VPS, disk is the limiting factor in the decision when I have to upgrade to a more expensive plan.  With pruning, you can not fully support the network and you have to be careful with your wallet handling, as rescanning is not possible.  That's actually what I do on one of the VPS exactly because the blockchain is already too big for the plan I use there, but I would have preferred to run an unpruned full node if I could.  Increasing the block size makes this issue larger by orders of magnitude.

Furthermore, as stated above already, block relay optimisations also help only "little" with bandwidth.  (At best a factor of two in comparison to a much bigger increase in block size being discussed.)

[sgbett]

Misrepresenting my position then arguing against that isn't going to cut it.

I said the problem is that the block size is too small, and that the solution is to make the block size bigger. That doing this requires no additional functionality. I contrasted this to the sidechain solution which does require additional functionality. As you rightly say nobody is claiming that is entirely the solution, but that is irrelevant, the point is that this or other solution(s) that require extra functionality are the very thing that your Tanenbaum quote warns against.

All that stuff you said about how we need to change TX size, thats some other thing. Either you are intentionally conflating the two, which is disingenuous or you really can't tell the difference, which I doubt is the case.

It looks to me like your emotional attachment to your position is causing your reasoning to become irrational. I don't think anyone's argument is absurd. I can see how enforcing higher fees benefits some parties, I think that misses the big picture which is that it *requires* additional functionality.

I'm not frightened of pissing contests, I think they are childish. You don't need to "fight" anything. As a smart human being we all need to listen, think and reason. Not inject hyperbole, and inflammatory language into posts to try and bully your opposition. Your argument should stand on its own merit and not the vehemence with which it is delivered.

We do need to "fight" features.  Tannenbaum's maxim is a restatement of the KISS principle.  I don't care if you can't see or won't accept that because of your economic illiteracy and a priori attachment to the absurd Red Queen interpretation.  The fight is happening (with your participation) whether you like it or not, mooting your objections.

I'm not "misrepresenting" your position.  The problem is that you don't understand your own position.   

"Contrived" 1MB tx bog down the network and present an attack vector.  8MB tx would 8^2 times worse, and thus the added complexity/functionality of larger blocks is demonstrated (your feeble speculative whining about my "emotional attachment" notwithstanding).

This is Sergio's conclusion; and Gavin's (present) ad hoc workaround is to marry (IE "conflate") a 100k tx size limit to any blocksize increase. 

Let me be clear because you are a slow learner: The intentional conflation of 100k tx size limits and larger blocks is Gavin's quasi-solution to the additional functionality/complexity required by larger blocks, not my "disingenuous" personal interpretation.  You were completely wrong about that (among other things).

What frightens me is that the whole thing seems to have turned into a pissing contest.

I'm not frightened of pissing contests

If you could stop contradicting yourself, that would be great. 

The introduction of sidechains, LN and whatever other solutions is a complicated solution. It's also a solution motivated by a desire to fix a perceived economic issue, rather than sticking to the very simple issue at hand. It is the very opposite of what you are claiming to be important, that software should be kept simple.

That is a contradiction.

The simple solution is to remove the artificial cap. A cap that was put in place to prevent DDOS.

Your reference of CVE-2013-2292 is just distraction. It is a separate issue, one that exists now and would continue to exists with a larger block size.

Great job on affirming your emotional attachment by posting inflammatory content, irrational argument and personal insults.

[smooth]

Misrepresenting my position then arguing against that isn't going to cut it.

I said the problem is that the block size is too small, and that the solution is to make the block size bigger. That doing this requires no additional functionality. I contrasted this to the sidechain solution which does require additional functionality. As you rightly say nobody is claiming that is entirely the solution, but that is irrelevant, the point is that this or other solution(s) that require extra functionality are the very thing that your Tanenbaum quote warns against.

All that stuff you said about how we need to change TX size, thats some other thing. Either you are intentionally conflating the two, which is disingenuous or you really can't tell the difference, which I doubt is the case.

It looks to me like your emotional attachment to your position is causing your reasoning to become irrational. I don't think anyone's argument is absurd. I can see how enforcing higher fees benefits some parties, I think that misses the big picture which is that it *requires* additional functionality.

I'm not frightened of pissing contests, I think they are childish. You don't need to "fight" anything. As a smart human being we all need to listen, think and reason. Not inject hyperbole, and inflammatory language into posts to try and bully your opposition. Your argument should stand on its own merit and not the vehemence with which it is delivered.

We do need to "fight" features.  Tannenbaum's maxim is a restatement of the KISS principle.  I don't care if you can't see or won't accept that because of your economic illiteracy and a priori attachment to the absurd Red Queen interpretation.  The fight is happening (with your participation) whether you like it or not, mooting your objections.

I'm not "misrepresenting" your position.  The problem is that you don't understand your own position.   

"Contrived" 1MB tx bog down the network and present an attack vector.  8MB tx would 8^2 times worse, and thus the added complexity/functionality of larger blocks is demonstrated (your feeble speculative whining about my "emotional attachment" notwithstanding).

This is Sergio's conclusion; and Gavin's (present) ad hoc workaround is to marry (IE "conflate") a 100k tx size limit to any blocksize increase. 

Let me be clear because you are a slow learner: The intentional conflation of 100k tx size limits and larger blocks is Gavin's quasi-solution to the additional functionality/complexity required by larger blocks, not my "disingenuous" personal interpretation.  You were completely wrong about that (among other things).

What frightens me is that the whole thing seems to have turned into a pissing contest.

I'm not frightened of pissing contests

If you could stop contradicting yourself, that would be great. 

The introduction of sidechains, LN and whatever other solutions is a complicated solution. It's also a solution motivated by a desire to fix a perceived economic issue, rather than sticking to the very simple issue at hand. It is the very opposite of what you are claiming to be important, that software should be kept simple.

That is a contradiction.

The simple solution is to remove the artificial cap. A cap that was put in place to prevent DDOS.

Your reference of CVE-2013-2292 is just distraction. It is a separate issue, one that exists now and would continue to exists with a larger block size.

Great job on affirming your emotional attachment by posting inflammatory content, irrational argument and personal insults.

LN isn't really about fixing a perceived economic issue, it is about secure instant payments, something Bitcoin by itself can't do at all. The observation may be that if many routine/small transactions move to such a system, the need for such transactions on the main chain is reduced, but that is secondary. Even if the main chain had infinite capacity Lightning would still be extremely useful.