Topic: Gold collapsing. Bitcoin UP. - page 92. (Read 2032247 times)

Finally!

Sure.  Everyone is concerned about the transaction rate.  SC and LN do not obviate the need for performing on-chain transactions.  They simply make it possible to do lesser importance transactions without bloating the Blockchain or trying to morph Bitcoin into a real-time system.

From an operational perspective everyone benefits from a higher transaction rate.  The main thing is that if the higher transaction rates in Bitcoin results in subversion of if as the core value store then everything goes up in smoke and we've got to start over from scratch (which, as I've said, is not without it's own set of pros and cons.)

That's exactly what Pierre Rochard demostrated whith his replies when I criticized Peter Todd during the "network stress test":

if memory serves both Adam Back and Joseph Poon said that SC and LN respectively needed a bigger block in any case.

(I'm actually in a hurry as soon as I've time I'll post reference to the source)

Yes I exaggerated.  Its a good book.  But that quote probably directly refers to his infamous criticism of linux.

Whoah, that's a bit harsh. I wouldn't agree on saying minix is Tanenbaun only contribution, there's so much more from him, despite being proven "wrong" on the specific monolithic/microkernel debate.

Apart from that, I agree with you on SC and LN (currently mostly vaporware) being an essential part of a 1MB chain in order to make it valuable.

And now icebreaker is quoting a guy who's only contribution is a failed OS architecture, probably typing it from his incredibly successful linux android or windows monolithic kernel.  And yes I tried minix.  It crashed after a few hours.

And to add irony on top the argument actually adds ammo to block size increase crowd because lightning or sidechains will be an ESSENTIAL part of a 1MB chain.  There won't be any value to users if BTC is running if lightning or SC fails because there isn't space on the chain for users.

I'm guessing ice is still in school regurgitating here the garbage his professors (who likely never worked on a million+ LOC project in their lives) feed him.

EURO countries as a whole have not as much government debt and deficit as Japan and the US. Current account looks also much better than in the US.

Gold collapsing. Bitcoin UP.

Reread the original quote. The way to make software small is to have components there are small. That doesn't mean you can't many other components. Ultimately they're just applications on top of the core.


On the surface that would be true, and it is mostly true in reality for small increases. But when big increases are introduced that creates a requirement for more complexity to cope with massive scaling and deal with the sheer volume of data and potentially more attack vectors. Algorithms and implementations (and deployments) that just work fine with 1 MB blocks won't necessarily work with blocks many times that size (or especially many, many times that size).

I don't really have a dog in this fight. I think the block size should be raised, but only modestly. From a software design point of view I do think that a simple core (that lacks requirements for massive scaling) along with independent applications is a "work smarter not harder" way to go. That's one reason I would limit the increases to a modest size.

But at the same time I don't think we know how well sidechains (which I'm deeply skeptical about) or lightning network (which I'm less skeptical about) will work out in actual practice. So it may turn out that massively increasing the block size (and coping with the scaling challenges of that) is indeed the way to go. But let's be cautious and try smarter approaches before we just throw the bigger hammer at it.

But if the claim is that sidechains are the 'solution' to the 'problem'. Then you are saying they are part of bitcoin [the ecosystem] whether they are part of core or not.

Increasing block size does not add features *and* it 'solves' the 'problem'. Without introducing any other layers of complexity, or attempting to artificially manipulate the fee economy that is growing organically just as it was always intended.

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

The fee market isn't a problem right now, the block size is. So why are people trying to pre-emptively fix the fee market in an ass backwards way to address the block size problem.

Only 2 nodes here but as soon as we get an XT block size fork I'm in. I sincerely hope that it doesn't come to that though, and the opposing core devs see sense and pull one of the recent BIPS (preferably the 8 meg one, but the 2 would do) straight to core. A complicit hard for will go over much more smoothly I feel.

Well I guess it depends where you live, since every country/region has it's own cycle. There are multiple cycles that converge this time and it will be scary.

For example look at the Middle East & North Africa - total chaos and destruction in the past years. They are effectively in the Dark Ages and will stay there for decades.

Then you can look at EU where around 50% of the economy is governments spending (debt + taxation). Debt in most EURO countries is at 100% of GDP or more. Taxation is very high - in some countries 50% of you paycheck goes directly to your government + VAT is at 20-30%. Can you imagine how even small economic downturn can tear apart thin social justice bullshit when you are starving or cannot pay your bills. Remember that EURO countries cannot manage their level of debts via inflation as they used to do with their own currencies.

I kind of agree with solex that the medicine (rate increase, even if symbolic, just so they can say they did) will come with a spoonful of sugar (QE of some sort, or something similar) to avoid crushing the markets.

But I wouldn't be terribly surprised to see rate increases continually delayed either. It's the US version of extend and pretend.

To the extent those build on top of Bitcoin they aren't adding features to it or making the the core code bigger. If they require changes to the core code or adding new features to it, that's a different matter that needs to be considered carefully.

No, and those features should be fought just like any others.  The adversarial process is valuable in assuring they do not compromise security or reliability.

Fighting features doesn't mean never accepting them no matter what.

Not really. Only a little bit of misery ahead; and then, acccording to his model: Roaring Twenties reloaded:

http://i1.wp.com/armstrongeconomics.com/wp-content/uploads/2012/08/ecconf-maa-clr.jpg?resize=584%2C449

Even Armstrong said this. Don't expect some market to crash on that day, but it will be important turning point that indicates years of misery ahead (countries going bankrupt, companies going bankrupt, more civil unrests, wars, migrations, viruses).

Oh yeah? So adding complicated stuff like sidechains and lightning network is making bitcoin code smaller?

Armstrong will be wrong again. Nothing special will happen Oct 2015.

Yup.