Add statement

[btcdrak]

No description provided.

[CodeShark]

ACK statement

[jonasschnelli]

ACK statement.

[laanwj]

ACK statement 5debf84

[jgarzik]

NAK - Propaganda that does not speak plainly to the user, nor give the user a full picture.

For example: "believes it should be each user’s choice not to upgrade the rules of their current Bitcoin software"

Soft forks forcibly downgrade not-upgrading users to lower security if they do not agree.

The only "choices" offered to the user are upgrade, or reduce your security below standard full-node trustless level.

[btcdrak]

Eric Lombrozo
9:46 PM Dec 22
ACK

Bryan Bishop
10:32 PM Dec 22
ACK

Adam Back
10:35 PM Dec 22
ACK

Greg Sanders
11:13 PM Dec 22
ACK, nice and short

Wladimir van der Laan
9:23 AM Dec 23
ACK, good and clear write-up

Jonas Schnelli
3:14 PM Dec 23
ACK

Alex Morcos
5:03 PM Dec 23
ACK

Matt Corallo
9:02 PM Dec 23
ACK

[luke-jr]

Showing 0 changed files with 0 additions and 0 deletions.

?????

[harding]

@luke-jr weird; I don't know why that happened. Here's the merge: 162e7cf

[luke-jr]

ACK English statement 162e7cf

[gavinandresen]

NAK statement.

And strongly NAK merge/close only 8 hours after opening, with discussion happening days before Christmas.

[bitcartel]

Statement should be fixed to include signatories otherwise it falsely implies that all project contributors stand behind the statement.

[ChainQuery]

Who the hell is "We" as described in the statement?

NAK

[petertodd]

ACK

[maaku]

Please provide in the future more than 4 hours for people to review such statements.

[harding]

@maaku I think that is reasonable. My apologies.

[tobypinder]

NACK statement as a consumer mislead by the implied developer consensus and lack of attribution.

[maddenw]

NACK - false and misleading statements, for example:

"Hard forks break compatibility of all previous Bitcoin software and require every participant to upgrade to the same rules by a deadline or risk losing money."

Soft forks also create the risk of losing money, and do it silently without any notice to users. RFB forced every wallet client to look for RFB flag, and if the expensive coding and testing is not done on every wallet implementation, users now risk double spend theft when they used to have high confidence in 0 conf. Many more examples.

[jameshilliard]

ACK

@maddenw RBF is local policy not a consensus rule and 0-conf already has a high double spend risk under adversarial conditions.

[randy-waterhouse]

ACK

[hrishikeshio]

NACK

[jonasschnelli]

If it was merged to quick (and I guess it was), we could revert it and give it a bit more time to discuss. But please no ACK/NACK from non bitcoin-core contributors without an explicit and well explained reason.

[petertodd]

Given we have ACKs from almost all active core contributors - and in particular the lead maintainer, Wladimir - I don't see any reason to think this isn't an official statement of the direction of the Bitcoin Core project.

Keep in mind this is a statement saying what an particular software development team's goals and values are. This does not necessarily apply to Bitcoin as a whole, nor does it prevent different development teams from adopting different goals and values - just like the statement says.

On 8 January 2016 00:37:11 GMT-08:00, Jonas Schnelli notifications@github.com wrote:

If it was merged to quick (and I guess it was), we could revert it and
give it a bit more time to discuss. But please no ACK/NACK from non
bitcoin-core contributors without an explicit and well explained
reason.

---

Reply to this email directly or view it on GitHub:
#1194 (comment)

[jonasschnelli]

Agree with @petertodd. Correcting/withdraw my statement that it was merged to quick.

[Aquentus]

@petertodd Given that two of the most senior contributors to Core, Gavin and Jeff, NACK-ed the statement, it can not by any means be said that this is in any way a statement from "Bitcoin Core".

The title is deeply misleading, not in the least because it purports to speak on behalf of bitcoin, which is an abhorrent aberration of all principles bitcoin was founded upon.

Moreover, not sure why @laanwj the maintainer all the sudden finds himself interested in engaging in petty PR. One would think he would like to keep his reputation rather than tarnish it by backing what is a very misleading title and in the process seeming to condone the centralisation of bitcoin.

[davedx]

Wow. I'm watching the Bitcoin community I used to love tear itself apart in a slow motion Internet-drama trainwreck. I hope you guys feel good about yourselves for all the damage and loss of goodwill you are causing in the wider Bitcoin community.

[mmitech]

Bitcoin have so many spoiled developers with uber inflated egos, these developers went through all red lines to make bitcoin works for their personal agendas...
Maybe this is what will eventually kill Bitcoin and not the hard fork.

[benjyz]

This is one of the poorest decisions in Bitcoin development since I'm following it, and a disaster for the development process. Those who ack'ed this have treated this decision with very little care and really lack professional behaviour.

• Who does "we" refer to in this statement?
• What is the precise dev voting procedure? don't merge with NACK's!
• What is the procedure for "becoming a core developer"? Peter Todd referred to "almost all active core contributors". This is getting absurd.
• since when does bitcoin make PR?
• who makes these decisions and how - what is the process behind it?
• no timeline and pushed through in a few hours. completely unprofessional. I suggest this statement being annulled and an explanation added.
• also please make public potential conflict of interest with blockstream and bitcoin-org.

[MarcoFalke]

Who does "we" refer to in this statement?

Bitcoin Core developers, maybe?

What is the precise dev voting procedure? don't merge with NACK's!

There is rarely a pull with no NIT or NACK. If the majority agrees, it is usually ok to merge.

What is the procedure for "becoming a core developer"? Peter Todd referred to "almost all active core contributors . This is getting absurd.

There is no procedure. I'd say, as soon as you contribute code or just generally participate in https://github.com/bitcoin/bitcoin you become a core dev.

since when does bitcoin make PR?

There is a subpages reserved for bitcoin core things on bitcoin.org. (c.f. https://github.com/bitcoin-dot-org/bitcoin.org/labels/Core)

who makes these decisions and how - what is the process behind it?

Everyone can? Pulls are always welcome.

no timeline and pushed this through in a few hours.

Agree.

[MarcoFalke]

Also, I don't get the "drama". This is basically an ELI5 softforks vs hardforks and the opinion of the core devs.

To cite @petertodd :

Keep in mind this is a statement saying what an particular software development team's goals and values are. This does not necessarily apply to Bitcoin as a whole, nor does it prevent different development teams from adopting different goals and values - just like the statement says.

[MarcoFalke]

Concept ACK 162e7cf

[benjyz]

@MarcoFalke nope, you're wrong. the concepts soft-fork and hard-fork are not well defined and this is misleading. e.g. SegWit is planned as soft-fork but changes completely the fundamental architecture (even new scripting language). Soft-forks can destroy the system. Given that those who proposed Side-chains, which is a totally failed project, propose similar methods for the production system this is strongly misleading with regards to the potential risks of these changes.

Bitcoin = core. Doesn't look like @petertodd understands this, but he should. The statement is also misleading in this regard. There is no competition and different development teams.

Everyone can? Pulls are always welcome.

Software is not just a collection of random patches. Without proper architecture a system like Bitcoin can't function.

[sDessens]

Also, I don't get the "drama". This is basically an ELI5 softforks vs hardforks and the opinion of the core devs.

I think you meant "The opinion of some core devs". The 'ELI5' is also opinionated enough for some core devs to complain.

If i was a long-time maintainer of an open source project and some nonsensical statement was uploaded pretending i agreed with it, i wouldn't be happy. Please stop pretending all core devs agree with these statements unless they actually do agree.

[MarcoFalke]

Please stop pretending all core devs agree with these statements unless they actually do agree.

I never said that. I appreciate that @gavinandresen and @jgarzik raised valid concerns.

[DaSpawn]

NAK

the appearance of a choice is no choice at all and serves to reinforce propaganda. further reinforcing these actions as propaganda is rushing merge/close during holidays in the hopes of limiting discussion as there is no reason to rush a change like this otherwise

[luke-jr]

Correcting/withdraw my statement that it was merged to quick.

@jonasschnelli We didn't at the time this was initially merged.

Who does "we" refer to in this statement?

@ChainQuery @benjyz Obviously it refers to "the undersigned"...

What is the procedure for "becoming a core developer"?

Develop code for Bitcoin Core, and maintain it (address problems found in peer review) enough that it gets accepted. Tada! You're now a core developer. Keep it up to remain active.

since when does bitcoin make PR?

This post is really more of public education, than PR.

also please make public potential conflict of interest with blockstream and bitcoin-org.

There are none that I am aware of.

@MarcoFalke nope, you're wrong. the concepts soft-fork and hard-fork are not well defined and this is misleading.

@benjyz On the contrary, softfork/hardfork are indeed very well-defined. A softfork is any change which adds new rules to the consensus protocol, without breaking backward compatibility with preexisting non-miner software. A hardfork is any change which removes or changes existing rules in the consensus protocol, thereby breaking backward compatibility with all preexisting full node software.

Bitcoin = core. Doesn't look like @petertodd understands this, but he should. The statement is also misleading in this regard. There is no competition and different development teams.

This isn't quite true. @petertodd maintains a derivative of Core with full unconditional RBF policies; @btcdrak maintains a derivative with an "address index"; I myself maintain an alternative with a wide array of assorted improvements. While we are all Core developers, there is no strict development monopoly. The fact that there is overlap is due to Bitcoin development being understaffed, and not something any of us can do anything about.

[ChainQuery]

Obviously it refers to "the undersigned"...

@luke-jr That would be fine, however their is no "undersigned", or any attribution to anyone in the document.

Furthermore, I believe that the editorial "we" should only be used by editors, leaders of nations, pregnant woman, and those with a tapeworm. @btcdrak Do you have a tapeworm? ;)

[btcdrak]

I think there is a lot of misunderstanding here.

Firstly, bitcoin.org, (like bitcoin.com) is a privately owned website where the owners are entitled to do whatever they want with them and enact whatever policies they like. While I hope the owners of both sites will always work in what is considered as the best interests of Bitcoin, they are in fact not obligated to anyone.

Secondly, bitcoin.org is not the Bitcoin Core project. The pull-request process on bitcoin.org has no relation with how Bitcoin Core, the project, comes to consensus. Bitcoin Core historically has had content published here as explained by https://bitcoin.org/en/bitcoin-core/about-site and it also explains the separation of concerns.

As such, content published in this section is done as a courteous extended by bitcoin.org towards Bitcoin Core and the submission here as a pull-request is simply part of the review process - like making sure the content will render properly and there are no broken links.

Furthermore, Bitcoin Core not the mouthpiece of the Bitcoin Community nor Bitcoin consensus rules: It is a project that ultimately has to come to it's own decisions about what it thinks is right for it as a project, taking various factors into account as explained by the statement.

I am disappointed at attempts by people to turn this into something political by diverting attention away from the content of the message. The statement simply represents the views of current major contributors of Bitcoin Core project and helps clarify the overall, general viewpoint. For what it's worth it was going to be published along with the FAQ and worked on by multiple people to ensure the wording and messaging expressed the view of the project and then translated into 5 languages. It was published here in co-ordination with the maintainers of this site. There is no requirement to have a "we the undersigned" for a project statement. It is enough that "we" generally agree and publish the content. It is enough that internally there was agreement on the wording. This is not a lawyering process, and verbal ACKs are also perfectly fine. There's no harm in the greater community adding ACKs and NACKs here to show their support or otherwise, but it doesnt change the viewpoint of the project.

For clarity the roadmap signatures were a good opportunity to show the community individual developers who explicitly were behind the roadmap and willing to work together to fulfilling it. It also gave an opportunity for the greater community to add their signatures. It was a statement of "we agree with this, we'll work together to make it happen" because the Capacity Increase roadmap requires co-operation from many parties both from Bitcoin Core and wallet developers and providers in order to be fulfilled.