Gold collapsing. Bitcoin UP.

[Zangelbert Bingledack]

The same worries about difficulty death spiral were raised in the 2011 price crash from $32 to $2. I don't think you can get anywhere near that extreme by difficulty adjustment alone.

 

[sickpig]

@cypherdoc
He really thinks segwit can be rolled out quickly. He is going to roll out segwit just as blocks fill up and claim success. But everyone else will see that their wallets can't use segwit, popular websites don't use it, merchants can't recognize segwit payments, exchanges and merchants are incompatible, POS hardware doesn't work, etc, etc. It is going to be the biggest mess imaginable. And all because they insist on living in their own bubble safe from viewpoints that differ from theirs and might educate them.

@rocks SegWit is the perfect example of a feature that should be deployed using an hard-fork.

SegWit to be effective need awareness of all the parts of the ecosystem: wallets, nodes, exchanges, payments processor, you name it.

To achieve such awareness you need a non backward compatible change to trigger a mandatory update across all the infrastructure.

By definition this is an hard-fork.

So I really do not understand the reasoning behind the proposal of deploying SegWit through a soft-fork. For sure it suits the narrative of smallblockists, i.e. hard-forks are dangerous and must not be used.

Back to the software changes: they are complex, full stop.

We're going to change the very way we used to store data into the "holy" Blockchain, for god's sake.

It took more a multi year, multi steps effort to ditch libopenssl in favour of libsecp256k1, it has been an herculean work. I dare saying the effort needed to implement SegWit is on the same league.

I'm not against SegWit per se, I'm extremely doubtful of the way the have decided to deploy it.

Lastly SegWit will solve a lot of problems. Among all malleability and fraud proofs are the one that come to mind. Nevertheless it does not solve the one for which it has been introduced.

edit: grammar

 

[awemany]

@Zangelbert Bingledack :

Oh I am not talking about the death spiral. I rather think about a forced 'hiccup'.

 

[theZerg]

You can run it. I think (unfortunately) they have done more than just removing the limit, at least they have planned fancy stuff for later. I think that was premature. Anyway, it is out there, you can run it. It should really be counted with the BIP101 nodes on xtnodes, but currently only two nodes are active.

Nope its basically just the limit removed. There is also opt-in traffic shaping (its off by default) so the client won't suck away all the bandwidth on your network.

However, it hasn't been officially released yet. I hope more people use it when that happens.

 

[Erdogan]

^ What about the fancy "jump to other branch if ... after 4 ..." stuff? I admit I don't follow the technicals too closely.

 

[Inca]

It looks like most of this debate is now going to go 'backroom' with /r/bitcoin etc now off limits for reasoned discussion.

Very damaging for bitcoin with such enormous proposed changes.

Come on Gavin, announce something to stop Maxwell et al. dead in the water.

 

[theZerg]

^ What about the fancy "jump to other branch if ... after 4 ..." stuff? I admit I don't follow the technicals too closely.

Bitcoin clients already "jumps to other branch...". If the core/xt client found another branch with higher work it would switch to it. This is how fork resolution works. So this isn't BU specific.

The only thing that IS BU specific is first rejecting a block bigger than X but then eventually accepting it. This is not a big change. Yes, if we wanted BU to just set the block size limit to another hard-coded higher value, we would not even need to do that. But BU let's you select the limit, so it is needed. Its not rocket science.

 

[sickpig]

Jeff Garzik have just posted this on btc dev ml:

Block size: It's economics & user preparation & moral hazard

All,

Following the guiding WP principle of Assume Good Faith, I've been trying to boil down the essence of the message following Scaling Bitcoin. There are key bitcoin issues that remain outstanding and pressing, that are orthogonal to LN & SW

This is an extreme moral hazard: A few Bitcoin Core committers can veto increase and thereby reshape bitcoin economics, price some businesses out of the system. It is less of a moral hazard to keep the current economics [by raising block size] and not exercise such power.

Core recommendations:

1) "Short term bump" Block size increase to maintain buffer. I've no special BIP preference.
...
2) If block size stays at 1M, the Bitcoin Core developer team should sign a collective note stating their desire to transition to a new economic policy, that of "healthy fee market" and strongly urge users to examine their fee policies, wallet software, transaction volumes and other possible User impacting outcomes.
...
3) Even if can is kicked down the road, Fee Event will come eventually. Direct research, testing and simulations into the economics and user impact side of the equation. Research and experiment with pay-for-burst (pay to future miner), flexcap and other solutions ASAP.

a must read IMHO

 

[rocks]

@sickpig
Yes Jeff sums it up well. Not doing anything is a hard fork in itself because that decision (and it is a decsion) changes bitcoin economics.

This is what is upsetting the ecosystem and Maxwell is tone deaf to. If you are going to do this you need to state your intention to do so.

 

[Melbustus]

@sickpig - Nice - Jeff being reasonable as usual. He's taking a middle ground, but critically is correctly and strongly pointing out several things:

It is less of a moral hazard to keep the current economics [by raising block size]

*It is a valid and rational economic choice to subsidize the system with lower fees in the beginning*

Without exaggeration, I have never seen this much disconnect between user wishes and dev outcomes in 20+ years of open source.

Higher Service prices can negatively impact system security

Markets function best with maximum knowledge - when they are informed well in advance of market shifting news and events, giving economic actors time to prepare.

It is more conservative to preserve current economics than to change to a new system with new economic

A lot of that hasn't been directly discussed, to my knowledge, to core-dev, at least not so strongly/clearly. These points should all be part of the discussion and part of peoples' wider understanding of the implications of blocksize.

[edit: typos]

 

[awemany]

Sounds like Jeff is getting unnerved as well.

A lot of that hasn't been directly discussed, to my knowledge, to core-dev, at least not so strongly/clearly. These points should all be part of the discussion and part of peoples' wider understanding of the implications of blocksize.

I disagree. It is quite the contrary, I think. Those things have been discussed to death for months on reddit and neither nullc nor adam3us can say they didn't hear us. They clearly did interact with us.

nullc:

... and I think things are gelling nicely around a productive path forward for the project.

They are actively ignoring us. Jeff is basically just saying what 80%+ of redditors and BCTlers have been saying all along.

I am doubtful whether he'll change anything by voicing his opinion. One thing could IMO change the situation though: If he says 'scrap BIP100' and starts backing BIP101, too.

Oh, and I like the acronym FFM he introduced: Let me just make it the correct backronym: "forced fee market".

 

[Melbustus]

@awemany - Yeah, sorry - definitely agree that these points have all been made *a lot* across various media, but I like the fact that Jeff is strongly bringing them up, with some formality, on the dev mailing list.

 

[awemany]

Yes. And he's trying to make it sound very technical.

I really can't get a grasp on what is going on with Jeff, though. He seems to be flip-flopping in a way. It is not really that he's just observing without acting - after all he did introduce BIP100, and that is/was quite an action.

He also agreed to put in the ridiculous 32MB (Remember why! - Because Blockstream wanted so!) cap into it.

Now he sounds like he's inching towards maybe just saying: "Screw it, BIP101 and a soft fork down if things get out of hand".

But it is really hard to tell. He sounds like he's keeping his options open, on which side to align with.

 

[Melbustus]

@awemany - Sounds to me like he doesn't particularly care *how* blocksize rises, as long as it rises *enough* to keep the current economic model (of cheap blockspace) intact.

That's more or less my position as well. I just consider BU to really be the only thing that lets that happen rationally longterm (ie, via a *natural* fee market). BIP101 is a good multi-year compromise, though.

Jeff seems more willing to go with short-term solutions which keep the current economic model intact, even if it means having this fight every year or two. Maybe he thinks most people will come around if given enough time?

 

[cypherdoc]

Jeff Garzik have just posted this on btc dev ml:

Block size: It's economics & user preparation & moral hazard







a must read IMHO

thanks for the heads up on this.

yes, Jeff has it right. i noticed a few subtle things: at least he's not pumping 100 now. he's open. also this:

"In a $6.6B economy, it is criminal to let the Service undergo an ECE
without warning users loudly, months in advance"

that's pretty heavy language. and it's quite clear this is directed at Maxwell. i pretty much agree at this pt that Maxwell is criminal; his $21M investment is forcing him to be so. this is the immorality of financial COI that i have been going on about for a year and a half now.

it's pretty clear to me that a hard fork implementation needs to happen w/o those guys. they need to be forked out of Bitcoin. @Gavin Andresen needs to coordinate a new github Core+101 ASAP. time has run out.

 

[rocks]

Another interesting back and forth between Gavin and Maxwell that I think shows the stalemate well, with Maxwell thinking he can take the authority position simply because he has check in control (for now).

Gavin:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011903.html
"RE: emerging consensus of Core:
I think it is a huge mistake not to "design for success" (see http://gavinandresen.ninja/designing-for-success ).
I think it is a huge mistake to pile on technical debt in consensus-critical code. I think we should be working harder to make things simpler, not more complex, whenever possible.
And I think there are pretty big self-inflicted current problems because worries about theoretical future problems have prevented us from coming to consensus on simple solutions."

Maxwell's reply:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011904.html
"I believe we've suffered delays because of a strong desire to be inclusive and hear out all ideas, and not forestall market adoption, even for ideas that eschewed pragmatism and tried to build for forever in a single step and which in our hear of hearts we knew were not the right path today. It's time to move past that and get back on track with the progress can make and have been making, in terms of capacity as well as many other areas. I think that is designing for success."

To summarize, Maxwell has been very patient and waited and waited listening to ideas to expand capacity that will never work. This is because he is very open minded. That patience of his has caused delays. From here on he is not going to engage with those ideas and pursue development around a small 1MB direction. Everything else if off the table.

Question to @Justus Ranvier since you participate in the dev mailing list. Has it always been like this? In this thread and a few others I've poked in I don't see any real discussion about what bitcoin should be and what to prioritize (for example IBLT, thin blocks are high on my list because they solve the propagation delay problem, segwit solves a storage problem which should be lower priority IMHO).
Instead what I see is Maxwell dictating direction and a few people very polity suggesting maybe that direction is wrong (I assume out of fear of being banned) and everyone else just discussing technical details to implement that direction.

I'm now no longer surprised that no real improvements have been made in the past year that solve the current next set of challenges for scaling.

 

[cypherdoc]

One thing could IMO change the situation though: If he says 'scrap BIP100' and starts backing BIP101, too.

yes, he should do this.

 

[cypherdoc]

heads up guys. big tweet coming from jgarzik.
[doublepost=1450288101][/doublepost][doublepost=1450288139][/doublepost]"Implies BIP 100 on ice."

 

[Zangelbert Bingledack]

Greg sounds increasingly like he's going for broke. I guess we'll know if he's really going whole hog if Jeff and Luke get pushed out to help that consensus gel by removing the last remaining flies in the ointment.

Good to see Jeff has a spine, even while seeming to identify with the "middle ground." He also looks in better shape than a few years ago.

 

[Justus Ranvier]

since you participate in the dev mailing list. Has it always been like this? In this thread and a few others I've poked in I don't see any real discussion about what bitcoin should be and what to prioritize

As long as I can remember, there's been tension caused by participants having diametrically opposed to the question of what Bitcoin should be.

That tension has never been resolved - instead there's been an unspoken mandate to not broach the subject and pretend the problem doesn't exist.