BUIP0**: Remove "Bitcoin" from user agent string assigned in BUIP001

[bitPico]

The user agent field defined in BUIP001 is non-standard (almost no bitcoin nodes use Bitcoin in their user agent field). It is also Redundant in that we already know we are on the Bitcoin network protocol and it makes it unnecessarily long for UI and readability purposes.

This "unnumbered" BUI proposal is to remove the "Bitcoin" portion from the user agent field and leave it simply "Unlimited".

Rational: Non-Standard, Redundant, Unnecessarily Long

Please consider this proposal. Kind Regards.

 

[freetrader]

I think the suggestion has technical merit, but in the current climate such a BUIP would be exploited politically by BU's opponents.

Rather than completely drop the 'Bitcoin', I would prefer shortening 'BitcoinUnlimited' to 'BU', as it's already a well-known acronym, and 'Bitcoin' is an integral component of the project name which I believe should be retained even if abbreviated.

 

[bitPico]

Using BU is still non-standard (see browser user agents and the http standard). The proposal is correct as-is. In regards to "BU's opponents" we shouldn't let paranoid thinking make things non-standard. There was once a war between all web browsers just like with Bitcoin node implementations today. The web browsers that did things non-standard all lost.

 

[freetrader]

I didn't say your proposal is incorrect. Please do not put words in my mouth, nor simply ascribe the political consideration to 'paranoid thinking'.
Your claim that 'using BU is still non-standard' merits further examination. Who sets this standard?

no other bitcoin nodes uses Bitcoin in their user agent field

This is simply false. Look at the user agents at https://bitnodes.21.co/nodes/ .
You will find

• BitcoinHK
  
• Bitcoin XT
• libbitcoin
• bitcoin-ruby

The user agent field defined in BUIP001 is non-standard

If there is a standard for user agent strings that BU is not compliant with, could you link to that please.

 

[bitPico]

These node implementations are almost nonexistent, declining in use or abandoned so lets be a bit more open minded than boolean it would be appreciated.

• BitcoinHK - Rank 85
• Bitcoin XT - Rank 42
• libbitcoin - Rank 69
• bitcoin-ruby - Rank 92

The minority of nodes don't define a "standard". Using "BU" over "Unlimited" due to the vaugeness it is only useful in internet discussions where the topic is known.

Please let others give some input so we don't have a two person back and forth non-progressing conversation. Thanks.

 

[Peter R]

I think this would be a good idea, but let's work on it after we get our first 1.1 MB block in the chain.

 

[AdrianX]

This is a bike shed project - I'd think it may become more relevant once the bitcoin network has accepted the notion of a user adjustable soft fork block limit.

 

[bitPico]

I think this would be a good idea, but let's work on it after we get our first 1.1 MB block in the chain.

This won't be too far away.

 

[solex]

Welcome to the forum @bitPico
Your BUIP has reasoned arguments, and although technically small it will have an impact on project visibility. As you are not a member it will require one to sponsor this, and if so, then it will be assigned a number for an upcoming vote.

 

[bitPico]

We don't agree with the "membership" aspect of Unlimited because this is supposed to be open source. We feel memberships will lead to a Core-like situation and in general turn off expert bitcoin developers like ourselves. If everybody cannot freely play then it is 3rd party controlled like you say "it will require one to sponsor this". A proposal in and of itself should be the first sponsor. Bitcoin needs a standards path that ALL IMPLEMENTATIONS MUST FOLLOW like Gnutella it worked very well in scaling the network with decentralized development and massive number of different implementations.

 

[AdrianX]

Hey @bitPico thanks for the input. I'd like to address some of your points.

We don't agree with the "membership" aspect of Unlimited because this is supposed to be open source.

BU is open source - The BU governing process, the process that is used to determine what gets merged into BU does not fit that traditional model. - this is very different from both Core and Bitcoin XT, for good or bad that's what it is.

We feel memberships will lead to a Core-like situation and in general turn off expert bitcoin developers like ourselves

XT has a valid governing model it has a benevolent dictator (and its problems)
Core has another it's governing process you are familiar with (and its problems)
BU has a federation of voting members, mostly non developers with experiences in other fields and an history in bitcoin (and its problems ;-)

It's the general feeling among members here that bitcoin development should be diversified and we need to enable more competent developers to rise to the top unsuppressed. It's with more competing implementations using different methods competing in a free market that ensures diversity, that's one way bitcoin code evolves, it's the way general supported by BU membership.

I have a suspicion that there may be a better way to govern what changes gets merged and what doesn't but I don't know what that is - I am eager to contribute to the process and like most would encourage a competing implementation with a different process.

The goal is healthy competition and the sharing of the good ideas with the autonomy to reject the bad and have the free market pick the winners. We bereave that will make for a better environment than what has evolved around Core.

I suspect there is an optimal number of developers that can work efectivly on any one project I also suspect its probably a lot less than Dunbar's number. I am confident that Core has superseded that number and the governing process in Core is left to incumbents who got in early.

I would encourage you to apply for membership and to partake in all discussions here, if you have an identity with a history in bitcoin - preferably dating back to before BIP101 please share it and apply. @solex is about to cut of new membership applications - next opportunity is Q2.

Not having any support for your BUIP is not a bad thing it's saving work up front, you can still discuss it, develop it and submit it yourself if you are a member, it will be discussed, but may not get voted on if you are not.

 

[solex]

@bitPico
Further to @AdrianX's explanation, anyone is welcome to contribute to directly to BU on github by raising a pull request. Of course it means writing the change first. @theZerg is the elected Developer which means he decides whether a change is functionally significant leading to a possible change in the BU client behaviour which then requires membership approval. In that case a BUIP is required to progress the change.
BU has 50 members, many of them active, so getting sponsorship for a non-member BUIP is a litmus test for whether the change itself has any likelihood of getting passed by the membership.

 

[bitPico]

So this is a top-down vertically integrated development team? It's easier to create our own fork than beg "some guy" on GitHub.

https://www.bitco.in/forum/threads/tx-malleability.1859/page-2#post-35573

 

[freetrader]

It's easier to create our own fork than beg "some guy" on GitHub.

Yeah, it really is. Everyone can be the king in their castle, that's the magic of open source.

I'd like to add on to what @solex mentioned about just doing a PR (which is a totally feasible way to get code into BU even if you're not a member).

The point I'd like to add is that if your code is contentious, a member could raise a BUIP to put the matter to a vote. That's why it makes sense to apply for membership if you're really interested in the project.
The part I like about BU is that there is a clear process that determines which code makes it into the client. One may disagree with decisions, and have one's own preferences, but in the end, a small minority would not obstruct progress.

As with all open source, people are free to maintain their own patched versions of the software, which may find adherents if they offer features that people like.

 

[Roy Badami]

I'm not sure web browser user agent strings are the pinnacle of protocol best practice - witness pretty much every browser since Mozilla still reporting itself as Mozilla and then putting the real user agent in parentheses.

Sometimes protocol development history is ugly, but the "BitcoinUnlimited" user agent string is established now, and I'd be resistant to changing it.