Gold collapsing. Bitcoin UP.

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
Excellent questions
 

albin

Active Member
Nov 8, 2015
931
4,008
Why are we screwing with Adam Back when we know he is in it for a paycheck right now.
I would argue Back basically started it by putting the concern troll bait out there.

@cypherdoc

His tweet is amazing: "surviving peer review on wizards"?!

This is what peer review on the wizards channel is: they all believe in the same stuff because if you don't you get booted from the irc if there's any vigorous discussion. For every issue, one guy goes off and writes what is more or less a half-baked essay/blog/diary/teenage-angst-poem about it, then everybody else then references that link in perpetuity as the definitive last word.

Tremendous tremendous systemic risks and moral hazard in this Core clique delusion that they have any such thing as peer review or any proposal process whatsoever.
 
Last edited:

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
@YarkoL ironically BU is the only autopilot soln. It does exactly what adam says it does not and it will be the core users who will have to constantly monitor the situation to see if BIP 101 has taken effect and switch their client if it has.
 

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
I know you guys don't think it's worth it to engage on that forum, but it does give an idea of what kinds of misconceptions people will have. It's already now 6 pages long.

Interestingly, every single criticism so far has been a misunderstanding. There are a lot of conflicting messages being sent:
  • "BU is a new kind of consensus via miners"
  • "BU works because of the oversize block acceptance depth"
  • My message: "BU just makes things more convenient to the user"
I suggested originally that the client default to Core settings, and I think the responses bear that out. Having defaults at 1MB with everything turned off by default, preferably with warnings if users changed anything ("WARNING: Experimental feature, advanced users only, do your own research before changing!") would not just help with adoption but with understanding.

This goes with Gavin's comment that BU needs to figure out who its customers are. If they are miners and business nodes, the settings should default to Core or else the user is going to have to mess with them to avoid losing money. The acceptance depth setting is also quite experimental and I don't know how nailed down the theory is. It would vastly simplify debate if it were off by default, because there are a lot of concerns about attack vectors, and beyond that it just adds a lot of confusion right now. Off by default doesn't harm anything, and you can even recommend the user turn it on.

Not having a consistent philosophy, such as by saying we don't want to push things on the user but then pushing things on the user, will make the debate a whole lot harder than it needs to be.

Just some thoughts from the trenches.
 

Inca

Moderator
Staff member
Aug 28, 2015
517
1,679
First off, I want to thank Zangelbert Bingledack for responding
to the bitcointalk thread that Adam Back started. It has sparked
off some lively discussion and so far the participants have managed
to keep the gloves on.

The criticisms offered by Core supporters set me thinking.
I haven't read all the threads on this forum, so apologies if what I'm about
to propose is already chewed over.

From what I have understood so far, It seems that the way to determine the
"good" block size in order to avoid being ending up on an isolated fork is to
constantly monitor what other users are doing.
Presumably this means taking part in discussions and following media, and
these activities incur a cost. Not all users will have the time. It ought to be
possible to optionally put the block size limit on "autopilot", so that it
dynamically changes without the user intervention. AFAICS this can be
accomplished by making the client advertise its preferred block size limit
to the network and then give some recommendation to the user based on data
it has encountered. There might be several recommendations based on different
statistical methods. (edit: of course this approach could be thwarted by sybil
attack, and using the excessivedepth already gives information about other
users. Oh well I keep learning)
But don't forget out the box it supports up to 16mb Max blocksize so it isn't really an issue regarding the upper bound. I thought the idea was to keep the maximum blocksize well above economic demand. Most users are unlikely to need to fine tune these settings and nor should we expect them to! It is about the principle and ethos of bitcoin as originally envisioned by Satoshi.

@Zangelbert Bingledack

Whilst it is important to offer user configurability (and we should), what is more important is offering a node solution which supports >1mb blocks out of the box (that isnt XT).

I personally would be very strongly against setting defaults identical to Core. That is not why BU is popular and is certainly not a draw to crowd out Core nodes over the next few months. I think this is a critical point really.
 
Last edited:

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
Guys if i have any influence here please let the trollfest in bitcointalk.org proceed on its own. Dont swallow the bait! Don't give that forum legitimacy via your participation. Delete all you posts and copy them over here.

Endlessly repeat this:
You are guessing at how BU works and are wrong. Read BUIP001, www.bitcoinunlimited.info/1txn, www.bitcoinunlimited.info/faq.html. when you understand how it works and have concerns come to bitco.in or reddit /r/btc to voice them.
 

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
@Zangelbert Bingledack Just had a read through your valiant efforts at clarifying some of the Bitcoin Unlimited concepts in the thread over in the other forum.

Even though there are many misunderstandings and quibbles about technical specifics, it does seem like the concepts around decentralized development, and the futility of Core maintaining and "iron grip", are gaining some traction.

Bang Bang ;)
 

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
On censorship at BCT, think about the situation. Adam set the thread up. I'm responding with perfect 120% civility and not promoting it other than saying what the advantages are. Even if they try to ban or delete for promotion, any even remotely objective observer would have to agree that would be a real trap and sham since basically the point of the thread is to critique BU, so someone has to respond against the critiques.

 

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
8 hours and 34 posts later... They're not so bad, I've been treated well. Sorry @theZerg I just can't delete all that work and the post quality is too slap-dash to be presentable here; don't worry, I didn't engage with any rude people.

I've made it clear several times in that thread that my views are mine alone. I'm telling people to come here or to /r/btc for the real scoop. I'm just focusing on my one area, the user-configurable blocksize and its wider implications - and not making it really BU-specific, though I'm answering some of the obvious questions.

My guess is that when Adam returns he'll say, "I just want to know about the technical aspects, not that econ stuff" - or he may label it politics. So probably nothing will happen, but I could get lucky. In the meantime, got some people interested, got a lot of people thinking I suppose, and set some misconceptions straight.
 
Last edited:

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
I personally would be very strongly against setting defaults identical to Core. That is not why BU is popular and is certainly not a draw to crowd out Core nodes over the next few months. I think this is a critical point really.
It seems to me that people who want bigger blocks won't care what the defaults are because they'll be eager to customize them anyway, whereas people who want small blocks or like BU's neutrality will be put off and suspicious of the default setting being something that would be foolish to mine on, etc. Maybe a "Core Unlimited" version could be made, where the only difference is the defaults are like Core, just to silence those who worry about the defaults being important, while BU defaults can reflect members' preferences.

Note that LukeJr is neutral on BU, as he should be since he can set a 250kB cap :)
 
Last edited:

lunar

Well-Known Member
Aug 28, 2015
1,001
4,290
https://medium.com/@barmstrong/scaling-bitcoin-the-great-block-size-debate-d2cba9021db0#.4j3x0nngr

Brian Armstrong's Latest Blog

Scaling Bitcoin: The Great Block Size Debate
I think BitcoinXT is one of several good proposals that we’d be happy with, but people shouldn’t read much into it beyond that (we are running a variety of node types in production including bitcoin core, XT, a custom node we wrote which works at our scale, and we will probably add others in the future like BU).

There is a healthy market dynamic where miners trade off the additional transaction fee they get vs the delay in relaying a larger block (which reduces their chances of winning that block). In other words, no matter that the cap is on the block size, miners may choose to mine much smaller blocks until transaction fees go up, and this is 100% their choice (as it should be).
  • Mining profitability is closely linked to the price of bitcoin. The best way I can think of to make the price of bitcoin go up long term is to ensure it can scale to approach the levels of Paypal or Visa. This will make bitcoin more valuable.
  • The block size debate is just one issue today. We should be more concerned with choosing the right team with the right leader (or decision making framework) than any particular block size solution. The right team will have many decisions like this to make over the years.
 

Zangelbert Bingledack

Well-Known Member
Aug 29, 2015
1,485
5,585
we will probably add others in the future like BU
-Brian Armstrong, Coinbase CEO
[doublepost=1451801425][/doublepost]
What’s happening right now is an election in the bitcoin space, and like all elections (the U.S. presidential race being one prime example) things can get a bit heated even if they are overall a good thing.
It's an election, but it doesn't have to be only two candidates: Core and XT, or even three (Core, XT, BU), but actually many so that the market can find the optimal choice. On that, here's bit of new angle from my foray into BCT today:

Quote from: BitUsher on Today at 02:41:37 AM
I personally believe XT's (and as suggested here BU) 75% threshold to be dangerously low as well. A 95% supermajority with a minimum 2 week grace period and alerts sent should be the default for hardforks.
I think 60% is fine. Just kidding. Or am I? I say it doesn't matter what I think. The market will make the choice anyway. The only thing devs can do by locking the consensus parameters down in each implementation is force the market to make a less granular choice.

For example, if the market wants a 90% supermajority, and the options are Core at 98% and XT at 75%, maybe the market will be forced to go with 75%, which the market deems dangerously low but better than an impossible 98%, or it will be forced to go with 98%, causing a lot of unreasonable delay.

Or maybe it's Core with 95% and a three-day grace period, and XT with 75% and a three-week grace period. Gotta choose the lesser of two evils, not a happy place to be.

When choices are not granular, consensus cannot find its optimum level. This is the kind of friction that can be removed by unbundling the consensus-parameter-setting service from the rest of the roles the devs play.
and

Quote from: smooth on Today at 02:19:21 AM
"We would be trying to predict what the market would decide, "

@Zangelbert Bingledack, I'm somewhat sympathetic to your cause but I don't really see how the market mechanism operates here, outside of a very broad definition of "market" which encompasses politics. Node voting doesn't work at all. Without that you are still reduced to politics and whoever shouts the loudest in trying to convince miners what block size they should use.
Well that's how it is anyway, and even now the market does decide. My point is that there's market friction in the inconvenience barrier of users not being able to set the blocksize cap themselves. That gives artificial solidity to the Schelling point set by Core (as well as the one set by XT). If Core is doing the correct thing, it shouldn't mind putting it to the market test more fully, by taking its finger off the scale.

How much is Core's finger really on the scale here? Well, for example, how many reasons are there to mistrust Mike Hearn? Some would say a lot. That means, as things stand now, even if you want BIP101, you can't really have it if you have a problem with Mike, because XT isn't an option for you. And because other people feel that way, you're further limited. The way Core (and XT) does it now makes it a power struggle, a popularity contest, and a package deal. Maybe Core could stall for a long time before people would finally give up and go with Mike. That's a lot of friction in the market.

And small block adherents, imagine the reverse, if it were Mike and Gavin were running Core and Pieter, Wlad, and Maxwell had broken off and started their own implementation, with maybe Jeff going between. And people were sticking with Core and its giant block plan, heading for catastrophe. You might notice the market friction then.

BU eliminates the power struggle by unbundling the setting of consensus parameters from the rest of the Code. It also of course makes for a lot more choices. If 1MB is too small and 8MB too big, what recourse is there? Roll your own and try to popularize it? Very hard. But propose 4MB and try to get people to agree? More doable. Or what if, like some Chinese miners were saying, 8MB is fine but the scaling to 8GB is ridiculous. What do you do? You have two options, and they are bundled up tightly with all the other aspects of the code and why you choose Core or XT. That's again a lot of market friction.
 
Last edited:

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,693
8 hours and 34 posts later... They're not so bad, I've been treated well. Sorry @theZerg I just can't delete all that work and the post quality is too slap-dash to be presentable here; don't worry, I didn't engage with any rude people.
That thread is drawing attention so I thought I would make just one contribution. If anyone wants to learn more they can come here.