(closed, passed) BUIP001: "Unlimited" inspired extensions to the Bitcoin Client

[cypherdoc]

if this vote is about adding all the extensions listed in the OP, i vote "no".

i think BU should be just Core+no limit for maximum chances of acceptance.

the blocksize limit is a red herring to further BS goals. once the limit is removed, it still remains a non-issue.

 

[VeritasSapere]

Yes!

though cypherdoc has given me pause for thought. I also favor a more minimalist approach, However traffic shaping and a GUI for these Bitcoin unlimited options do make sense to me and seem to necessarily go along with the increased blocksize limit.

Are there any features in particular you think we should not implement that are listed here cypherdoc? Since it does seem like this is essentially core+increased blocksize, since these other features like traffic shaping are more necessitated by the increase.

I suppose the GUI fix would not be within this category, then that could then be removed based on that reasoning, though that little feature does seem to make sense to me though, seems useful.

 

[steffen]

I vote YES. You have done a great job. No need for bikeshedding.

 

[chriswilmer]

Yes!

 

[lunar]

YES - but share the KISS concerns, consider defaults as close to Core as possible? Like @solex perhaps a simple option dialogue at startup?

Great work.

 

[AdrianX]

Re point 5.
I think nodes should be limited by the available technology, and not limited by a setting someone sets to limit bandwidth and forgets to change. I am a typical internet user and setting QoS on my router to optimize my personal usage and paid for service is my preferred solution.

I'd like to see the Code be as simple as possible. KISS

No.
otherwise less .5 yes.

 

[solex]

Qualified "yes". Similar view to comments above. While traffic-shaping is desirable, perhaps in the first instance it could be missing or defaulted to "no" to minimise a FUD attack vector.

The key is to get BU on as many nodes as possible before noticeable divergence from Core on anything other than the block limit. If and when Core gets marginalized then new features can be added to BU in the manner in which this community think is best.

 

[Melbustus]

Yes, but "qualified" similar to @solex's notes below; ie, I think that for now (to minimize potential FUD vectors), the defaults should be set to mimic Core except for items pertaining to blocksize...

Qualified "yes". Similar view to comments above. While traffic-shaping is desirable, perhaps in the first instance it could be missing or defaulted to "no" to minimise a FUD attack vector.

The key is to get BU on as many nodes as possible before noticeable divergence from Core on anything other than the block limit. If and when Core gets marginalized then new features can be added to BU in the manner in which this community think is best.

 

[VeritasSapere]

@Melbustus I agree. It would be good if the default settings on BU are mostly identical to Core, except for the blocksize increase.

 

[Peter R]

Yes, with the same qualifiers as Melbustus, Solex and others.

 

[theZerg]

Guys. How come this thread sat here for 2 weeks and only after the vote do you choose to start discussion on it? What am I supposed to do with a qualified "yes" vote? When you voted for the president did you write in "Mickey Mouse, so long as he supports equal rights for cats?"

And what is the vote counter supposed to do with a vote like that?

I literally posted a few days ago on GCBU something along the likes of "will someone please discuss this over in the BUIP001 thread and if there is any discussion, we'll make a counter BUIP". No discussion. No counter BUIP.

So in the interest of making this happen, I'm going to simply act like a machine and take whatever you voted as "yes" or "no". If you really want to drop traffic shaping or whatever, I recommend that someone write that up and post a BUIP suggesting it.

You don't have to be gentle if you don't agree with me; I won't give up in a hissy fit -- but of course keep on subject not ad-hominem. Present your opinion and let the members decide. But please follow the system so I don't end up in these situations that both take up a lot of time AND force me to basically judge what to do, ultimately forcing me into the role of "benevolent dictator", and irritating those people who disagree.

 

[Bloomie]

@theZerg I know you wanted a separate sub-forum for proposals, but could this be a visibility issue for forum visitors? If they are already reading Bitcoin Unlimited topics, it may be easier to present them with the BIPs right there. I would try moving all Bitcoin Unlimited topics to a separate subforum, and keeping all current BIPs pinned at the top of that subforum.

 

[theZerg]

Yes, let's try that. I think that pinning current BIPs will address my issues.

However, I don't really think that that's the issue here. I have been cross-posting to GCBU and regular readers waited until the vote to express their opinion. We just need people to become more actively involved. BU can become what YOU want it to be. I'm the dev and as cypherdoc says "devs gotta dev". I need to hear from you all about what should go in in a timely and formal fashion. Check out this Maxwell quote from the bitcoin-dev mailing list:

My message lays out a plan for several different complementary
capacity advances; it's not referring to the current situation--
though the current capacity situation is no emergency.

I believe it already reflects the emerging consensus in the Bitcoin
Core project; in terms of the overall approach and philosophy, if not
every specific technical detail. It's not a forever plan, but a
pragmatic one that understand that the future is uncertain no matter

What "emerging consensus"? Its like he's trying to make it happen by pretending that its happening.

Or its like a Roman emperor with a token senate: he gets to wrap a veneer of "consensus" onto the issue but the truth is that "consensus" only happens when he sees it as such.

I want to show how different and fair the BU process is compared to that. But I can't if people "vote" "yes but"... That kind of vote forces me to decide whether the vote is really a "yes" or not, forcing me into the exact role I'm trying to show does not exist in BU.

 

[Bloomie]

Administering a people's movement is a big undertaking and I personally wouldn't want you to be burdened with it. Does BU have a secretary yet?

 

[VeritasSapere]

If they say yes then it is a yes vote. I said yes, I was just responding to the post by cypherdoc which has since been removed.

In regards to that quote by gmaxwell, "emerging consensus in the Bitcoin Core project". See what he is doing here, he is talking about "Core" or "developer" consensus, an entirely different concept to Bitcoin consensus. No doubt for many people this conflates the issue and understanding of what true consensus even means within Bitcoin.

 

[Zangelbert Bingledack]

@VeritasSapere

Exactly, it's a politician's trick to equivocate on terms that way. The only way to beat it is to demand clarity in definitions. Consensus on what precisely? It becomes a weakness they can be called out on painfully, but not if it slips by unnoticed.

 

[cypherdoc]

Yes, let's try that. I think that pinning current BIPs will address my issues.

However, I don't really think that that's the issue here. I have been cross-posting to GCBU and regular readers waited until the vote to express their opinion. We just need people to become more actively involved. BU can become what YOU want it to be. I'm the dev and as cypherdoc says "devs gotta dev". I need to hear from you all about what should go in in a timely and formal fashion. Check out this Maxwell quote from the bitcoin-dev mailing list:



What "emerging consensus"? Its like he's trying to make it happen by pretending that its happening.

Or its like a Roman emperor with a token senate: he gets to wrap a veneer of "consensus" onto the issue but the truth is that "consensus" only happens when he sees it as such.

I want to show how different and fair the BU process is compared to that. But I can't if people "vote" "yes but"... That kind of vote forces me to decide whether the vote is really a "yes" or not, forcing me into the exact role I'm trying to show does not exist in BU.

please don't get discouraged Andrew. i, for one, think you're doing great work even if i disagree with the roll out of the extensions. open source is messy and filled with ppl who only want to talk and not do. i sure hope my mainnet and testnet nodes are helping you as i haven't gotten any feedback or further requests from you. let me know if i can do anything else. like i said, i have 4 more nodes for you if you want.

if it's any conciliation, you appear to be the only one, besides maybe Toomim, coding anything up that is a substantive alternative and that has a chance to be accepted. in fact, i think BU is ultimately where we want to get altho we may have to go thru 101 first.

one warning; the sloppiness of the "yes" votes in this thread is a harbinger of bad things to come from Blockstream. that sloppiness of opinion, while being nice here, is exactly what they are going to use, while not being nice, to obfuscate and criticize the extensions. and once you think you've answered one question about traffic shaping, then they'll be off to criticizing the user config. and on and on and on. you see, everyone has their preference or opinion. which is exactly why i'm voting "no" b/c it simplifies the solution down to a single concept that is irrefutable and has already been debated to death with a generally agreed upon and accepted answer; we all want bigger blocks.

 

[Zangelbert Bingledack]

I voted yes because long term I have a hard time seeing "give users a choice" lose out to "don't give users a choice."

Freedom is popular. The anti-choice position ultimately comes down to the silly stance that what is saving Bitcoin from failure is the barrier of inconvenience of having to download a different implementation that has the settings the user wants. That is such a week reed to lean on. For now it's a little less cut and dried because vetted implementations with all different settings aren't on offer (that I know of), but that is almost trivial to change. Once there are versions with all different settings available, that weak argument will be all that's left. We can just say, "If you don't like traffic shaping or don't trust it or think it will blow up your computer, don't enable it. It's off by default and you definitely won't accidentally enable it."

If and only if it does end up causing problems for people who enable it will there be an issue. The problem there is that even though people can leave it off, the failure would reflect poorly on the rest of the code, since from the lay user's perspective there's no way to know who is a really a good coder and which implementations are really safe other than track record.

 

[awemany]

@theZerg: As you can see, you are herding cats here (its a good thing: we all have our own opinion). Keep up the good work!

 

[Zangelbert Bingledack]

And @theZerg, I'd chalk most of this one up to people not being familiar with the system. Next time we'll know to argue more. I think "let's not bikeshed this" sounded a bit like "let's not really discuss this," so anyway, next time should be easier.

Also, I don't see why two versions couldn't be made, one with only the blocksize stuff and one with the extras (still off by default). That should make the public relations aspect easier: "If you REALLY don't like the traffic shaping even as an option, we have a version where it's not even possible to enable it."