<unnamed>

Public Key

npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wt

Profile Code

nprofile1qqspk2wefm5pu8hqg703md9uftygwsrm63c2p4cxpem032e8lh2hu5qprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvym2wfm

Publishing to

relay.snort.social

Last Notes

2023-06-07 19:42:51 CEST

- reply

📅 Original date posted:2015-10-06
📝 Original message:Maybe you are confused with a compilation notice that would say "All
Content Copyright and other rights reserved by its Respective Owners" or
something similar. That is not the same thing as claiming ownership
using the "c" inside the circle.
There is also a difference between claiming a copyright for individual
works as part of a compilation as opposed to claiming a copyright on the
compilation itself (which is what the current notice is).
Russ
On 10/6/2015 1:08 AM, Milly Bitcoin wrote:
>> The copyright notice refers to the fact that each contributor owns
>> copyright
>> to his own contributions. There is no legal group that owns copyright
>> to the
>> entirety of the code.
>>
>
> No, that is not what such a notice means. The part after the "c" in the
> circle is the legal owner. If the legal owners are not properly
> identified then the notice is not valid.
>
> ---
> From Nolo:
>
> What is a valid copyright notice?
>
> A copyright notice should contain:
> •the word "copyright"
> •a "c" in a circle (©)
> •the date of publication, and
> •the name of either the author or the owner of all the copyright rights
> in the published work.
>
> For example, the correct copyright for the fourth edition of The
> Copyright Handbook, by Stephen Fishman (Nolo), is Copyright © 1998 by
> Stephen Fishman.
>
> ---
> from USPTO:
>
> Use of the notice informs the public that a work is protected by
> copyright, identifies the copyright owner, and shows the year of first
> publication.
> ---
>
> Russ
>

2023-06-07 19:42:50 CEST

- reply

📅 Original date posted:2015-10-06
📝 Original message:> The copyright notice refers to the fact that each contributor owns copyright
> to his own contributions. There is no legal group that owns copyright to the
> entirety of the code.
>
No, that is not what such a notice means. The part after the "c" in the
circle is the legal owner. If the legal owners are not properly
identified then the notice is not valid.
---
From Nolo:
What is a valid copyright notice?
A copyright notice should contain:
•the word "copyright"
•a "c" in a circle (©)
•the date of publication, and
•the name of either the author or the owner of all the copyright rights
in the published work.
For example, the correct copyright for the fourth edition of The
Copyright Handbook, by Stephen Fishman (Nolo), is Copyright © 1998 by
Stephen Fishman.
---
from USPTO:
Use of the notice informs the public that a work is protected by
copyright, identifies the copyright owner, and shows the year of first
publication.
---
Russ

2023-06-07 19:42:50 CEST

- reply

📅 Original date posted:2015-10-06
📝 Original message:> I believe we should work to deprecate the idea that Core is somehow the “core of Bitcoin,"
I never did understand the terminology. There were "core developers"
which i understood to mean the primary developers of the Bitcoin
software. Then, suddenly, the software's name was changed from QT to
"Core." That seemed to me to be different meaning of the word "Core"
yet it was often treated as the same. So a developer who is not one of
the anointed 5 is a "Core developer" because they work on Bitcoin Core.
The anointed 5 would be "Core Core Developers?"
In any case if I could get a list of "Core Developers" as referenced in
the copyright notice that would also be good since that is a legal notice.
Russ

2023-06-07 19:42:49 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:On 10/5/2015 5:30 PM, Gregory Maxwell via bitcoin-dev wrote:
> On Mon, Oct 5, 2015 at 9:27 PM, Peter R via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Once again, let’s use the current gridlock
>
> there is no gridlock here and an effort to manufacturer
> one for political reasons will not be successful.
Worthless discussion over the definition of "gridlock."
Russ

2023-06-07 19:42:48 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:> Regular contributor?
>
> Please explain how for a fork in the protocol should you only listen to
> regular Bitcoin Core contributors?
This is an artifact of a small centralized group of developers that
wants to hold on to power. This is why there is so much objection to
documenting some sort of process since that would highlight issues such
as this.
Russ

2023-06-07 19:42:44 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:On 10/5/2015 4:05 PM, Steven Pine via bitcoin-dev wrote:
> It's pretty clear Mike has turned into concern troll and bully.
"troll" and, even worse, "concern troll" are terms generally used by
teenagers on places like Reddit to complain about someone who doesn't
agree with them. It is not rally a valid term to use in technical
discussions. Several of the developers on here act as bullies by
wielding power they have accumulated in a a system which they claim is
decentralized. It is not clear at all so your premise is faulty.
>has stated numerous times in other forums he has no
> interest in building consensus changes he doesn't agree with himself.
What exactly do you expect? Bitcoin is not a charity, it is built on
incentives.
> He's lost his integrity and trust and why the core developers
Only a very small minority of the developers have "integrity and trust."
Most are pretty irrational and untrustworthy if you look at their
discussions outside of their technical expertise. Bitcoin is not
supposed to have a model where users are not forced to trust a small
group such as the core developers. It sounds to me like you suggest
giving that up the idea of decentralization so you can gain control over
the "official" software releases.
Russ
Russ

2023-06-07 19:42:39 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:On 10/5/2015 6:56 PM, Btc Drak via bitcoin-dev wrote:
> There is no development gridlock. Look at the IRC logs for core-dev;
> Please desist from this intellectual dishonesty and toxicity.
A system where anyone can veto a change promotes gridlock. Most people
not on the devlpoment team see the block size debate as "gridlock."
Much like "spam" "attack" and "decentralized" everyone has their own
definition so arguing over it is generally pointless.
Russ

2023-06-07 19:40:36 CEST

- reply

📅 Original date posted:2015-09-20
📝 Original message:>Some of us have also been actively working towards developing
> a more modular, layered architecture and better implementations that
> will afford greater decentralization in software development with less
> need for critical code reviews, less pushback from downstream developers
> who must continuously rebase, a better process for building consensus in
> the community, and simpler app migration.
It sounds more efficient but it is not clear to me that it would change
the level of centralization of how the final decisions are made.
One threat to Bintcoin involves incentive for companies to hire
developers. The only reason is to change (or not change) Bitcoin Core
so it is beneficial to their interests. I am not sure anything can be
done about that risk but it needs to be understood and considered and
not just ignored.
> We need to increase the basic infrastructure nodes by a factor much
> larger than 2 or 3...more like 100 or 1000...and it's entirely doable
> with properly aligned incentives.
I assume that would mean fees that hike transaction fees and make
Bitcoin more expensive?
Russ

2023-06-07 19:40:34 CEST

- reply

📅 Original date posted:2015-09-20
📝 Original message:> Until this is settled, Bitcoin has no clear direction and developers cannot make effective decisions:
How exactly do things set "settled" in this environment?
People looking at Bitcoin think a small group of developers and miners
"control" these decisions. Not sure if "control" is the right word but
that is the perception.
Russ

2023-06-07 19:40:32 CEST

- reply

📅 Original date posted:2015-09-19
📝 Original message:> Government is the group of people that does things ...
Governments (note the plural) are a collection of entities made up of
people that do all sorts of things both good and bad. Attaching your
political agenda to Bitcoin with the hopes people will agree with it
after using Bitcoin is not a viable plan to promote your agenda nor is
it a plan for mass adoption.
Russ

2023-06-07 19:38:19 CEST

- reply

📅 Original date posted:2015-08-27
📝 Original message:> So where is the solution? What to do?
AML-KYC is mostly something that sits on top of the Bitcoin protocol.
Take Coinase, inc. as an example. They check bank accounts before they
open your account and they link your Bitcoin address to your account in
their database. Then they ask for an explanation of why you are using
the account. Then they track your coins to a certain extent once you
actually buy Bitcoins. None of these activities are directly involving
the protocol or would require changes to the Bitcoin system.
What you can do is develop standards for using Bitcoin and entities that
need to follow AML-KYC can choose to follow those standards if they want
when they conduct business using Bitcoin. You can add a small amount of
extraneous data to transactions that could show you followed some
AML-KYC procedure. If you did that you could have a "white list" of
complaint transactions rather than a "black list" of non-compliant
transactions as you seem to be proposing. I am not sure how you would
actually do something like that or how it would work but it is an
interesting concept (not necessarily good, but interesting).
Russ

2023-06-07 19:35:23 CEST

- reply

📅 Original date posted:2015-08-15
📝 Original message:> Baseless accusations also have no place on this mailing list. They are
> unprofessional, and poisonous to the consensus-building process we all
> seek to engage in.
I didn't see any baseless accusations in the message. I saw a
discussion of possible conflicts of interest. Your reply seems to
indicate that somehow conflicts of interest don't exist with the
developers or that the developers are somehow above everyone else. The
fact is the developers on this list discuss conflicts of interest all
the time as it relates to things like mining. Conflicts of interest are
going to be a regular part of Bitcoin development so you should start
getting used it because it is only going to increase as the value increases.
It is your messages attacking people who raise legitimate issues that is
poisonous. It tries to prevent discussions of the risks associated with
the code development. It creates an atmosphere where people are
blackballed if they discuss these issues. This is what happens in
religions all the time and it is time to start treating Bitcoin like the
technology that it is rather than some cult religion.
For all I know is that a hard fork controversy is going to cause the
price to drop temporarily so for all I know this is a scheme to buy some
cheap coins just like when hackers used to attack exchanges and
bitcointalk at the same time to get the price to drop. (I don't think
it is a scheme to do that but such a scheme is certainly possible in the
future and things like that should be expected to happen).
Russ

2023-06-07 19:35:13 CEST

- reply

📅 Original date posted:2015-08-15
📝 Original message:> So if you want a user vote, that's an issue that'd have to be tackled:
> the people who admin the main communication channels Bitcoin users have
> vowed to censor any program that doesn't slavishly follow 51%+ hash
> power. That attempt to control the conversation is certainly not
> libertarian or democratic in nature, but there you go.
These types of actions are immediately apparent to anyone who looks at
the Bitcoin ecosystem (Bitcoin.org, Githib, Wiki, bitcointalk, etc.) and
were readily apparent long before any block size debate. It is almost a
taboo subject and anyone who raises these types of issues is immediately
labeled as a "troll." These are the people who used to run around
saying that Bitcoin development is "decentralized" because anyone can
fork the code and now many of the same people claim a fork will destroy
everything.
The problem is that a small group of highly irrational and inexperienced
people (outside of the small and unusual Bitcoin ecosystem) have control
over the majority of the resources. I think over time the problem will
even itself out but currently it is an obstacle in moving Bitcoin forward.
Russ

2023-06-07 19:35:13 CEST

- reply

📅 Original date posted:2015-08-15
📝 Original message:> You may be misremembering; nobody has ever disagreed that you can fork a
> source code repository. Perhaps you are thinking instead about the
> concerns regarding "asymmetric" rule incompatibilities?
I am not "misremembering" anything. Some people have claimed for years
that Bitcoin development is "decentralized" because anyone can fork the
code. I have often pointed out to them that such a process is not
decentralization similar to the process of Bitcoin mining. It is
probably closer to checks and balances you see in political systems. The
response is usually that I am "troll" or that I am somehow attacking the
developers by simply describing the system. The result is that the
issues and risks associated with development are often not properly
evaluated. It is the same sorts of problems you have when a central
bank or Fed is controlled by a small group. It is just human nature and
Bitcoin is not immune.
Russ

2023-06-07 17:47:59 CEST

- reply

📅 Original date posted:2015-08-20
📝 Original message:The idea is to come up with some sort of standardized metric so as the
tools and issues come up you are comparing similar things.
The first thing you have to do is link "centralization pressure" and
(pressure to merge with a big miner) to some sort of overall
decentralization metric. For instance, how much do big miners reduce
decentralization to begin with? That is a complicated analysis on its
own. Then you can measure specif use cases with a tool like that.
the idea at least is that the metrics do not "take sides" on any issue
and just provide a measure of whatever it is you are measuring.
most of the references have to do with measuring decentralization in
political systems so a system would need to be developed to apply to
software projects like Bitcoin:
http://www.sscnet.ucla.edu/polisci/faculty/treisman/Papers/defin.pdf
http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf
Russ
>
> Pieter built a nice simulation tool and posted some results.
>
> I tweaked the parameters and ran the tool in a way that tested ONLY for
> hashrate centralization effects, and did not conflate these with network
> partitioning effects.
>
> I found that small miners were not at all disadvantaged by large blocks.
>
> The only person who commented on this result agreed with me. He also
> complimented Pieter's insight (which is entirely appropriate since
> Pieter did the hard work of creating the tool).
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:47:59 CEST

- reply

📅 Original date posted:2015-08-20
📝 Original message:Yes, I am familiar with the process as i spent years doing it. Many
here are familiar with the Bitcoin issues but they are not familiar with
addressing risk in a systematic way. There are many good posts but they
are dispersed among thousands of messages and the discussions are in a
variety of contexts. As a result, the same things are often argued over
and over and much time is wasted. Note that knowing a technical area
and knowing a process to analyze metrics are two different things.
I am glad you want to participate in such a process. Several developers
on this list have mentioned the need for a decentralization metric so i
think that is a good place to start. I suggest getting the other
developers/experts together and send me the various into and tools you
have and I will put it together into a useable format. The idea is to
create a living document so people can discuss changes in a similar
context.
Russ
On 8/20/2015 8:58 PM, Peter Todd wrote:
> On Thu, Aug 20, 2015 at 08:45:53PM -0400, Milly Bitcoin via bitcoin-dev wrote:
>
> You know, I've noticed you've spent a tremendous amount of time and
> energy on this list promoting these kinds of metrics; obviously you're
> somewhat of an expert on this compared to the rest of us.
>
> Why don't you look into spearheading one of these analyses yourself to
> show us how it's done?

2023-06-07 17:47:20 CEST

- reply

📅 Original date posted:2015-08-20
📝 Original message:> The same with -XT, nobody should be able to affect the entire bitcoin
> ecosystem regardless how many miners or bitcoin companies you can lobby.
> If this is possible, then Bitcoin is not as secure as we thought.
Bitcoin is only as secure as the developers, users, and miners allow it
to be. If you can get the majority of developers, users, and miners to
do insecure things then Bitcoin will be insecure.
Russ

2023-06-07 17:47:20 CEST

- reply

📅 Original date posted:2015-08-20
📝 Original message:> Security is provided via POW.
POW is only one aspect of security and that algorithm was created by
developers and adopted by miners. Developers provide security by
creating an algorithm and miners provide security by adopting it. If
the developers and miners decided to do something insecure then Bitcoin
will be insecure. POW is not some outside force.
The security of Bitcoin as a system is a very complex subject that
involve a number of factors that are the result of actions by humans.
Russ

2023-06-07 17:47:12 CEST

- reply

2023-06-07 17:47:04 CEST

- reply

2023-06-07 17:47:04 CEST

- reply

2023-06-07 17:43:49 CEST

- reply

📅 Original date posted:2015-07-30
📝 Original message:These are the types of things I have been discussing in relation to a
process:
-A list of metrics
-A Risk analysis of the baseline system. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.
-A Road map for each goal that lists the changes or possible avenues to
achieve that goal.
Proposed changes would be measured against the same metrics and a risk
analysis done so it can be compared with the baseline.
For example, the block size debate would be discussed in the context of
a road map related to a goal of increase scaling. One of the metrics
would be a decentralization metric. (A framework for a decentralization
metric is at
http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf).
Cost would be one aspect of the decentralization metric.
Russ
On 7/30/2015 7:33 PM, Eric Lombrozo via bitcoin-dev wrote:
>
>> On Jul 30, 2015, at 5:29 AM, Gavin <gavinandresen at gmail.com
>> <mailto:gavinandresen at gmail.com>> wrote:
>>
>> it is hard to have a rational conversation about that when even simple
>> questions like 'what is s reasonable cost to run a full node' are met
>> with silence.
>
> Some of the risks are pretty hard to quantify. But I think this misses
> the bigger point - it very well *might* be possible to safely raise this
> limit or even get rid of it by first fixing some serious issues with the
> protocol. But over six years into the project and these issues continue
> to be all-but-ignored by most of the community (including at least a few
> core developers). I don’t think it’s really a matter of whether we agree
> on whether it’s good to raise the block size limit, Gavin. I think it’s
> a matter of a difference in priorities.
>
> - Eric
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:43:42 CEST

- reply

📅 Original date posted:2015-07-29
📝 Original message:> GUYS, WE’VE KNOWN ABOUT THESE PROBLEMS AND HAVE TALKED ABOUT THEM FOR
> YEARS ALREADY…AND IT SEEMS PRACTICALLY NOTHING HAS HAPPENED…
What is the incentive for someone with high level technical skills to
spend all their time developing and testing code? Especially since the
code is generally the boring task of "fixing the plumbing" and won't
benefit the developer directly ... except they will be blamed if
something goes wrong.
Russ

2023-06-07 17:43:06 CEST

- reply

📅 Original date posted:2015-07-27
📝 Original message:> The ugly thing is I think everyone in this process recognises the
> meta-consensus nature of the debate already. Notice how Gavin Andresen's
> initial blocksize posts were in the form of a non-technical blog, making
> non-technical arguments to the public - not the Core dev team - in ways
> not conducive to open response. A rather annoying example is Jeff
> Garzik's recent efforts: a fundementally broken troll pull-req raising
> the blocksize to 2MB that simply can't be merged for reasons unrelated
> to the blocksize, followed by very public and loud efforts to spin a
> non-issue - closing a pull-req that had no real impact on blockchain
> capacity - into a broader reddit furor over a "changed" policy on
> scaling. As a PR effort to the public this was fairly effective: framing
> the Core dev team's actions as a change and raising the blocksize as a
> default action puts the team on the defensive. As a way of building
> consensus among the Core dev team, Garzik's actions are very
> counterproductive.
You are correct. It is also counterproductive to take cheap shots at
vendors in order to garner consulting revenue. Measuring risk in a
systematic way against known metrics is the way to go. Tweeting,
blogging, and drama are generally counterproductive.
When the issue is raised most of the developers shun the idea so until
some of the developers become mature and experienced you will be left
with all this teenager nonsense where everybody calls each other
"trolls" on Reddit instead of engaging in real risk analysis.
Russ

2023-06-07 17:42:49 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:>default in case of controversy is no change.
I think the result of this would probably be that no controversial
changes ever get implemented via this process so others will hard fork
the code and eventually make this process irrelevant. Since you need
close to 100% agreement the irrelevance would have to come as a step
function which will manifest itself in a rather disruptive manner.
The question is really is this hark-forking disruption worse than coming
up with some kind of process to handle controversial changes.
Russ

2023-06-07 17:42:23 CEST

- reply

📅 Original date posted:2015-07-15
📝 Original message:> (note how Chainalysis's actions were
> described(1) as a sybil attack by multiple Bitcoin devs, including
> Gregory Maxwell, Wladimir van der Laan, and myself)
As far as I know none of those people are security experts nor do they
engage in systematic risk and threat analysis. Simply because they are
experts in Bitcoin development does not make them expert in other areas.
Many of those involved in Bitcoin think that because they know Bitcoin
that they somehow have become experts in other areas. That is one
reason why so many Bitcoin companies have been hacked.
An "attack" according to ISO/IEC 27000 "is any attempt to destroy,
expose, alter, disable, steal or gain unauthorized access to or make
unauthorized use of an asset." The situation you are describing is not
an "attack," they are providing a service. Satoshi Dice is also not
"spam," it is again providing a service within the rules set forth in
the software. The people going around claiming these are "spam" and
"attacks" spend too much time of Reddit or they have an ulterior motive.
In any case these baseless accusations and arguments waste inordinate
amounts of time.
Russ

2023-06-07 17:42:22 CEST

- reply

📅 Original date posted:2015-07-15
📝 Original message:Below are 2 examples why a systematic risk analysis needs to be used.
The current situation is that you have developers making hyperbolic,
demonizing statements that users are "spammers" and engaged in Sybil
"attacks." Characterizing these activities as spam and Sybil attacks is
not a systematic analysis, it is closer to the process used at the Salem
Witch trials.
If this process of demonetization is to take its natural course then
these statements are "developer attacks" from a developer system that
lacks proper incentives and is rife with conflicts of interest.
Russ
>... they need to
> connect to a large % of nodes on the network; that right there is a
> sybil attack. It's an approach that uses up connection slots for the
> entire network and isn't scalable; if more than a few services were
> doing that the Bitcoin network would become significantly less reliable,
> at some point collapsing entirely.
...
> Spammers out there are being very disrepectful of my fullnode resources

2023-06-07 17:41:01 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:>Also decentralisation is key, and that is something we can improve
with pooling protocols to phase out the artificial centralisation.
So how is the level of decentralization measured? I see many claims on
this list that such-and-such action will increase or decrease
centralization and sometimes people talk in absolutes such as something
being decentralized or centralized. Some of the arguments seem to make
claims without providing any kind of analysis or explanation.
Nothing is truly decentralized and decentralization is just an
approximation of having a collection of centralized systems interact in
some way. I would suggest coming up with some sort of metric so these
discussions can start from a baseline when discussing changes.
Russ

2023-06-07 17:40:28 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:> Proposing inaction is not the way you convince people that bitcoin can
> scale.
>
> People and businesses cannot perform any capacity planning and future
> projections under the proposal of "economic change through inaction."
>
> There will be no growth, by your argument, until there is fee
> pressure. And what happens then?
It is not clear he is proposing "inaction." I am not sure what he is
proposing other than being against knee-jerk reactions. He has also
said he doesn't want to take on the responsibility of deciding on
whether to approve hard fork changes which is understandable considering
all the other things he is doing. Such a responsibility is probably too
much of a burden to put on any one individual no matter who it is. The
next step is to come up with a process to handle proposed hard-fork
changes other than just to ask the Core maintainer to do it.
Russ

2023-06-07 17:40:27 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:>None of this is a reason why the size can't increase. However, in my
opinion, we should do it because we believe it increases utility and
understand the risks; not because we're afraid of what might happen if
we don't hurry up. And from that point of view, it seems silly to make a
huge increase at once...
Yes. I think people/businesses want some kind of assurance that there
is a path to get things done when needed rather than immediate changes.
Since there is currently no clear path/schedule to get any changes
accomplished they gets anxious.
Russ

2023-06-07 17:40:18 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:The core maintainer has always been in control of the consensus rules.
Satoshi came up with the rules and put them in there. Since then any
changes to any part of the code go through the core maintainer. It
looks to me as if people are saying it somehow changed along the way
because they don't want to hurt people's feeling, upset up, get them to
quit, etc. Sure there are checks and balances and people don't have to
use the main code base but if they change the consensus rules they are
incompatible.
The notion that because people can download different rules and run them
is interesting from a theoretical perspective but that is constrained by
the network effect. I can say the US government is not the "decider" of
laws because I can vote them out, recall them, challenge things in
court, or secede and start my own country. You can also say the
judge/jury in a criminal court case is not a "decider" because the
president can always issue a pardon. But those points are generally not
useful in a practical sense.
The issue about the developers is the tremendous influence they have to
veto any changes. I don't have veto power yet I have more bitcoins than
garzik says he has. The whole Bitcoin software development system is
subject to attack from just a couple of people who have this veto
power. With all the crying and moaning about centralization on this
list I would think that would be a concern.
Russ
On 6/28/2015 11:35 AM, Jorge Timón wrote:
> On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
>> I never said something was approved by garzik added something after it was
>> opposed. What I said was a proposal was made and 4 people commented on the
>> Github. He then tweeted there was near universal approval before most
>> people even heard about the subject. It was not controversial but i was
>> pointing out the arrogance of some of the developers. He considers the
>> entire universe of Bitcoin stakeholders to be a very small group of
>> insiders, not the entire universe of Bitcoin users. Another thing I have
>> seen on Github for bitcoin.org is how some the maintainers change the rules
>> on the fly. Sometimes they say a proposal had no objections so it is
>> approved. Other times they say a proposal has no support so it is rejected.
> Ok, I misunderstood.
> Well, the fact is that the number of capable reviewers is quite small.
> If more companies hired and trained more developers to become bitcoin
> core developers that situation could change, but that's where we are
> now.
>
>> You are also trying to say that the core developers actually have little
>> influence and are not "deciders" because anyone can fork the code. That has
>> already been discussed at length and such an argument is faulty because
>> there is a constraint that your software is incompatible with everyone else.
> Only if you change the consensus rules (which are, in fact, a
> relatively small part of the code).
> Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
> with the replace by fee policy, libbitcoin also changes many
> non-consensus things, there's code written in other languages...
> There's multiple counter-examples to your claim of that argument being faulty.
> Seriously, forking the project is just one click. You should try it
> out like at least 9627 other people have done.
> >From there, you can pay your own developers (if you don't know how to
> code yourself) and maybe they're also fine being insulted by you as
> part of the job.
> What you still can't do is unilaterally change the consensus rules of
> a running p2p consensus system, because you cannot force the current
> users to run any software they don't want to run.
>
>> The issue is that there is no way right now to change the consensus rules
>> except to go through the core maintainer unless you get everybody on the
>> network to switch to your fork. People who keep repeating that the software
>> development is "decentralized because you fork the code" without explaining
>> the constraints are just cultists.
> Please, stop the cultist crap. Maybe insulting people like that is how
> you got people to call you a troll.
> But, yes, you are right: there's no known mechanism for safely
> deploying controversial changes to the consensus rules
>
>> The discussion has nothing to do with who has the position now and I never
>> said he has "control over the consensus rules." The maintainer has a very
>> large influence way beyond anyone else. As for your claim that I want
>> someone hurt because I am explaining the process, that is ridiculous. If
>> the Core maintainers did not have significant influence to change the
>> consensus rules then everybody would not be spending all this time lobbying
>> them to have them changed.
> Well, if you don't think he has control over the consensus rules we're
> advancing.
> I think that was implied from some of your previous claims. He is no
> "decider" on consensus changes.
> Insisting on it can indeed get him hurt, so I'm happy that you're
> taking that back (or clarifying that really wasn't your position).
> Influence is very relative and not only core devs have "influence".
> Maybe Andreas Antonopolous has more "influence" than I have because he
> is a more public figure?
> Well, that's fine I think. I don't see the point in discussing who has
> how much influence.
>
>> The outside influences and stake of the developer is a relevant topic. The
>> same types of things are discussed on this list all the time in the context
>> of miners, users, merchants, and exchanges. Again, the developers try to
>> place themselves on some kind of pedestal where they are the protectors and
>> pure and everyone else (miners, users, merchants) are abusers, spammers,
>> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made an
>> issue of how many bitcoins he holds and he made that issue in the same place
>> where he announces many of the technical issues. It is very relevant that
>> he has a minimal stake in Bitcoin holdings yet he goes around making major
>> decisions about Bitcoin and trying to dictate who is allowed to participate
>> in discussions. If a core developer has minimal stake in Bitcoin yet has
>> major veto power over code change that is a problem.
> Please, don't generalize. I don't think I put myself in any kind of pedestal.
> That is insulting to me and many others (you may not even know and
> you're insulting them).
> And I think my Bitcoin holdings are completely irrelevant when judging
> my contributions to the software: either they're good or not, and who
> I am or how many Bitcoins I have at any given time shouldn't matter.
> Again, nobody forces you to use our software, as said there's
> alternatives (including forking the project right now).
>
>> You are correct that you cannot give power to any person over the Internet
>> which is why some kind of process needs to be developed that does not
>> involve trying to convince one person to make the changes or a system that
>> depends on unwritten, ever-changing rules maintained by a handful of people.
> Well, for now the process we have is seeking consensus, and although
> our definition of "uncontroversial" is very vague, I think it is quite
> obvious when a proposed change is not "uncontroversial" (like in the
> block size debate).
> It seems to me that any other "formal process" would imply
> centralization in the decision making of the consensus rules (and from
> there you only have to corrupt that centralized organization to
> destroy Bitcoin).
>

2023-06-07 17:40:17 CEST

- reply

📅 Original date posted:2015-06-28
📝 Original message:I never said something was approved by garzik added something after it
was opposed. What I said was a proposal was made and 4 people commented
on the Github. He then tweeted there was near universal approval before
most people even heard about the subject. It was not controversial but
i was pointing out the arrogance of some of the developers. He
considers the entire universe of Bitcoin stakeholders to be a very small
group of insiders, not the entire universe of Bitcoin users. Another
thing I have seen on Github for bitcoin.org is how some the maintainers
change the rules on the fly. Sometimes they say a proposal had no
objections so it is approved. Other times they say a proposal has no
support so it is rejected.
You are also trying to say that the core developers actually have little
influence and are not "deciders" because anyone can fork the code. That
has already been discussed at length and such an argument is faulty
because there is a constraint that your software is incompatible with
everyone else. The issue is that there is no way right now to change
the consensus rules except to go through the core maintainer unless you
get everybody on the network to switch to your fork. People who keep
repeating that the software development is "decentralized because you
fork the code" without explaining the constraints are just cultists.
The discussion has nothing to do with who has the position now and I
never said he has "control over the consensus rules." The maintainer
has a very large influence way beyond anyone else. As for your claim
that I want someone hurt because I am explaining the process, that is
ridiculous. If the Core maintainers did not have significant influence
to change the consensus rules then everybody would not be spending all
this time lobbying them to have them changed.
The outside influences and stake of the developer is a relevant topic.
The same types of things are discussed on this list all the time in the
context of miners, users, merchants, and exchanges. Again, the
developers try to place themselves on some kind of pedestal where they
are the protectors and pure and everyone else (miners, users, merchants)
are abusers, spammers, attackers, scammers, cheaters, etc. It is Garzik
who voluntarily made an issue of how many bitcoins he holds and he made
that issue in the same place where he announces many of the technical
issues. It is very relevant that he has a minimal stake in Bitcoin
holdings yet he goes around making major decisions about Bitcoin and
trying to dictate who is allowed to participate in discussions. If a
core developer has minimal stake in Bitcoin yet has major veto power
over code change that is a problem.
You are correct that you cannot give power to any person over the
Internet which is why some kind of process needs to be developed that
does not involve trying to convince one person to make the changes or a
system that depends on unwritten, ever-changing rules maintained by a
handful of people.
Russ
On 6/28/2015 8:30 AM, Jorge Timón wrote:
> On Sat, Jun 27, 2015 at 2:50 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
>> On 6/27/2015 7:28 AM, Jorge Timón wrote:
>> I have seen things like a Github discussion between 3 or 4 people
>> and then Garzik send out a tweet that there is near universal approval for
>> the proposed change as it nobody is allowed to question it. After watching
>> the github process for a couple years I simply don't trust it because the
>> developers in charge have a dictatorial style and they shut out many
>> stakeholders instead of soliciting their opinions.
>> [...]
>>
>> I saw this problem first hand when Andreas Antonopolis got into a big
>> dispute with some of the core developers over the press contacts. The
>> github made up their rules as they went along and simply ignored input from
>> anyone outside their inner circle. Since that time several people have told
>> me they dropped out of participating in the github process. The maintainers
>> deleted some of my messages and I have been told I am banned form github.
> I wasn't asking for an example of something that was rejected, there's
> plenty of those.
> You were saying people were opposing a change and jgarzik unilaterally added it.
> When did that happen?
>
>> As for your proclamation at Bitcoin core != Bitcoin consensus rules, that is
>> simply not true in practice. There is one piece of software with one
>> maintainer. If you want it changed you have to convince that one person to
>> approve the change.
> There are many pieces of software and many maintainers, libbitcoin,
> for example, is another full node implementation different from
> Bitcoin core.
> Also, to change Bitcoin core I don't need to convince anyone, I do it
> all the time here https://github.com/jtimon/bitcoin
>
>> The core developers have the biggest influence by far to decide hard fork
>> changes. There is no other place to go. While anyone can fork the code
>> someone compare it to the river Thames. if you don't like where the river
>> runs you can dig a new one ... here is a spoon. I can vote in elections but
>> that does not mean the US government is "decentralized." The core
>> maintainer has decided on a hard fork change, he has decided not to do it.
> Maybe Bitcoin core devs have more influence, but still, they don't
> have the power to decide for everyone else what the consensus rules
> are.
> Your analogy is ridiculous, it literally takes seconds to fork bitcoin
> and is as simple as clicking a button.
> Wladimir has explained many times that he hasn't decided anything
> because he can't decide that.
> You keep insisting that he has control over consensus rules. Are you
> doing it because you want him to be threaten, tortured, kidnapped or
> killed?
> If you don't, please stop making false claims about powers he doesn't
> have because some bad guy could believe you.
>
>> I am under the
>> impression that at least some of the developers (such as Garzik) don't
>> actually hold that many bitcoins and don't have a large stake in the system
>> yet they have significant control.
> For the last time, they may have control over Bitcoin core (one
> implementation of the Bitcoin protocol), not the consensus rules.
> Why are anyone's bitcoin holdings relevant in any technical discussion?
> Please, keep this kind of offtopic comments out.
>
>> Anyone can attack the system by simply
>> hiring a couple core developers and creating the gridlock we see now.
> As said several times, yes, it is hard to define "uncontroversial"
> without giving veto powers to any random guy on the internet.
> But this is clearly not what is happening now. Most Bitcoin core devs
> are against the current proposals, that cannot be considered
> uncontroversial for any sane definition of it.
>

2023-06-07 17:40:16 CEST

- reply

📅 Original date posted:2015-06-26
📝 Original message:Without looking up specific links I am confident people like Mircea
Popescu will oppose just about any change. Maybe they don't post their
objection to Github but the point I am making is that no matter what
change you make someone, somewhere will be against it. Some of the
developers think that Github is the only place that matters and that the
only opinions that matter is a tiny group of insiders. I don't think
that way which is the reasoning behind my statement.
I am saying that after all the concerns are addressed as far as
reasonably possible someone, somewhere has to decide whether or not to
commit the changes to the official release. Right now the only person
who makes that decision if the version manager. I agree it should not
fall onto the shoulders of one person who is also very busy doing other
things. I am saying there should be some process to move forward and
make decisions when needed.
Also, you already saw one of the Core developers calling me a "troll"
and telling others to ignore my messages. I have heard of several
people who just drop out of the github discussions because of stuff like
that. They also delete message from Gihub discussions so that archive
is not 100% credible. I have seen things like a Github discussion
between 3 or 4 people and then Garzik send out a tweet that there is
near universal approval for the proposed change as it nobody is allowed
to question it. After watching the github process for a couple years I
simply don't trust it because the developers in charge have a
dictatorial style and they shut out many stakeholders instead of
soliciting their opinions. I view the Github system as the biggest
centralized choke-point in Bitcoin and probably its biggest threat to
its continued survival. Anyone can come in and hire a couple core
developers and veto any change they don't want.
Russ
On 6/26/2015 7:13 AM, Jorge Timón wrote:
> On Thu, Jun 25, 2015 at 2:42 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
>> "Cultish" means making claims without any supporting facts.
> On Thu, Jun 25, 2015 at 5:19 AM, Milly Bitcoin <milly at bitcoins.info> wrote:
>> As for developers, the consensus on code changes are almost never 100% and
>> someone has to make the decision about what is an a acceptable consensus.
> This statement seems "cultish" by your own definition.
> I'm going to make the opposite statement: the consensus on code
> changes is almost always 100%.
> Mark has already given a couple examples of changes to consensus rules
> (the most risky type of change), here's a few thousand other examples
> of changes to the bitcoin core's code that had no opposition:
>
> https://github.com/bitcoin/bitcoin/commits/master
>
> Can you please point us to a few examples were changes were made with
> opposition to them?
> In those cases (which you assure is what happens almost always), would
> you say that the result of letting a decider decide instead of fixing
> or addressing all the concerns (either by changing the proposed code
> or explaining it) better in restrospective?
>

2023-06-07 17:40:16 CEST

- reply

📅 Original date posted:2015-06-27
📝 Original message:On 6/27/2015 7:28 AM, Jorge Timón wrote:
> On Fri, Jun 26, 2015 at 2:34 PM, Milly Bitcoin <milly at bitcoins.info> wrote:
>> Without looking up specific links I am confident people like Mircea Popescu
>> will oppose just about any change. Maybe they don't post their objection to
>> Github but the point I am making is that no matter what change you make
>> someone, somewhere will be against it. Some of the developers think that
>> Github is the only place that matters and that the only opinions that matter
>> is a tiny group of insiders. I don't think that way which is the reasoning
>> behind my statement.
> Yes, I understand that it may be difficult to define
> "uncontroversial", as I explain in
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html
>
>> I have seen things like a Github discussion between 3 or 4 people
>> and then Garzik send out a tweet that there is near universal approval for
>> the proposed change as it nobody is allowed to question it. After watching
>> the github process for a couple years I simply don't trust it because the
>> developers in charge have a dictatorial style and they shut out many
>> stakeholders instead of soliciting their opinions.
> Can you provide anything to back your claim?
> Note that even if that's true, still, Bitcoin core != Bitcoin consensus rules.
I saw this problem first hand when Andreas Antonopolis got into a big
dispute with some of the core developers over the press contacts. The
github made up their rules as they went along and simply ignored input
from anyone outside their inner circle. Since that time several people
have told me they dropped out of participating in the github process.
The maintainers deleted some of my messages and I have been told I am
banned form github. Further, as you can see on here Jeff Garzik, a guy
who claims only to hold a few hundred Bitcoin, told people on this list
to ignore my messages. There is also the incident where Gavin lambasted
someone for "hiding behind anonymity" when the whole project is based on
an anonymous contributor. I find it interesting that many developers
who work on a decentralized system. I don't like the general attitude
of the developers that they are the protectors of the system and that
everyone else is trying to exploit or do damage. they often characterize
different users/businesses/miners as abusers, spammers, people trying to
game the system, etc. while they characterize the developers as pure and
good. When the issue comes up about authority over the code (which
includes the consensus rules) they spout all kinds of nonsense about how
they don't have significant control and are not deciders yet they never
point to who does decide. If they weren't the deciders then people
would not be spending all that time lobbying them. just because there
are some checks and balances does not mean it is "decentralized" or they
are not deciders.
As for your proclamation**at Bitcoin core != Bitcoin consensus rules,
that is simply not true in practice. There is one piece of software
with one maintainer. If you want it changed you have to convince that
one person to approve the change.
>> I view the Github system
>> as the biggest centralized choke-point in Bitcoin and probably its biggest
>> threat to its continued survival. Anyone can come in and hire a couple core
>> developers and veto any change they don't want.
> Well, yes, github is centralized and so it is bitcoin core development.
> But bitcoin core developers don't decide hardfork changes.
> So far, softfork changes have been made because they have been
> considered "uncontroversial", not because there's any centralized
> negotiating table or voting process to decide when to force every user
> to adapt their software to new consensus rules.
>
The core developers have the biggest influence by far to decide hard
fork changes. There is no other place to go. While anyone can fork the
code someone compare it to the river Thames. if you don't like where
the river runs you can dig a new one ... here is a spoon. I can vote in
elections but that does not mean the US government is "decentralized."
The core maintainer has decided on a hard fork change, he has decided
not to do it.
In any case what happened in the past does not matter. What is going to
happen now is the question. If nothing happens and everybody sits
around saying they are not in charge of the consensus rules and nothing
ever gets done I see Bitcoin just fading away into oblivion. I am under
the impression that at least some of the developers (such as Garzik)
don't actually hold that many bitcoins and don't have a large stake in
the system yet they have significant control. Anyone can attack the
system by simply hiring a couple core developers and creating the
gridlock we see now.
Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/9e573a71/attachment.html>

2023-06-07 17:40:15 CEST

- reply

📅 Original date posted:2015-06-25
📝 Original message:The more specific answer (from a user's perspective) is that there is
unanimous approval within the constraints of the Bitcoin system. The
constraint is that your software must be compatible with merchants and
exchanges for your coins to have value. Stating "unanimous approval"
without identifying the constraint is misstating the issue.
As for developers, the consensus on code changes are almost never 100%
and someone has to make the decision about what is an a acceptable
consensus. Most of the cultish answers completely overlook this issue
even though it is main point of the question.
Russ
On 6/24/2015 11:00 PM, Raystonn wrote:
>
> > Consensus-code changes are unanimous. They must be.
>
> Excellent. Now we are getting to some actual written rules. How about
> updating the BIP process documentation with this? Everyone should be
> able to read the rules of the coin they are buying.
>
> One moment though. Can you tell me how this particular rule came to
> be? The creator of Bitcoin violated this rule many times. So it must
> have been adopted after his departure. What process was followed to
> adopt this new rule? Was there consensus for it at the time? A huge
> portion of the user community is under the impression that Satoshi's
> written plans, some of which violate this new rule, will be
> implemented. So there certainly would not be consensus for this rule
> today.
>
> On 24 Jun 2015 6:51 pm, Mark Friedenbach <mark at friedenbach.org> wrote:
>
> I'm sorry but this is absolutely not the case, Milly. The reason
> that people get defensive is that we have a carefully constructed
> process that does work (thank you very much!) and is well
> documented. We talk about it quite often in fact as it is a
> defining characteristic of how bitcoin is developed which differs
> in some ways from how other open source software is developed --
> although it remains the same in most other ways.
>
> Changes to the non-consensus sections of Bitcoin Core tend to get
> merged when there are a few reviews, tests, and ACKs from
> recognized developers, there are no outstanding objections, and
> the maintainer doing the merge makes a subjective judgement that
> the code is ready.
>
> Consensus-changes, on the other hand, get merged into Bitcoin Core
> only after the above criteria are met AND an extremely long
> discussion period that has given all the relevant stakeholders a
> chance to comment, and no significant objections remain.
> Consensus-code changes are unanimous. They must be.
>
> The sort of process that exists in standards bodies for example,
> with working groups and formal voting procedures, has no place
> where changes define the nature and validity of other people's
> money. Who has the right to reach into your pocket and define how
> you can or cannot spend your coins? The premise of bitcoin is that
> no one has that right, yet that is very much what we do when
> consensus code changes are made. That is why when we make a change
> to the rules governing the nature of bitcoin, we must make sure
> that everyone is made aware of the change and consents to it.
>
> Everyone. Does this work? Does this scale? So far, it does.
> Uncontroversial changes, such as BIP 66, are deployed without
> issue. Every indication is that BIP 66 will complete deployment in
> the very near future, and we intend to repeat this process for
> more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY.
>
> This isn't about no one stepping forward to be the "decider." This
> is about no one having the right to decide these things on the
> behalf of others. If a contentious change is proposed and not
> accepted by the process of consensus, that is because the process
> is doing its job at rejecting controversial changes. It has
> nothing to do with personality, and everything to do with the
> nature of bitcoin itself.
>
>
> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin
> <milly at bitcoins.info <mailto:milly at bitcoins.info>> wrote:
>
> I have seen this question asked many times. Most developers
> become defensive and they usually give a very vague 1-sentence
> answer when this question is asked. It seems to be it is
> based on personalities rather than any kind of definable
> process. To have that discussion the personalities must be
> separated out and answers like "such-and-such wouldn't do
> that" don't really do much to advance the discussion. Also,
> the incentive for new developers to come in is that they will
> be paid by companies who want to influence the code and this
> should be considered (some developers take this statement as
> an insult when it is just a statement of the incentive process).
>
> The other problem you are having is the lead developer does
> not want to be a "decider" when, in fact, he is a very
> significant decider. While the users have the ultimate choice
> in a practical sense the chief developer is the "decider."
> Now people don't want to get him upset so nobody wants to push
> the issue or fully define the process. Now you are left with
> a broken, unwritten/unspoken process. While this type of
> thing may work with a small group of developers
> businesses/investors looking in from the outside will see this
> as a risk.
>
> Until you get passed all the personality-based arguments you
> are going to have a tough time defining a real process.
>
> Russ
>
>
>
>
>
>
> On 6/24/2015 7:41 PM, Raystonn wrote:
>
> I would like to start a civil discussion on an undefined,
> or at least unwritten, portion of the BIP process. Who
> should get to vote on approval to commit a BIP
> implementation into Bitcoin Core? Is a simple majority of
> these voters sufficient for approval? If not, then what is?
>
> Raystonn
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/db6e451a/attachment-0001.html>

2023-06-07 17:40:14 CEST

- reply

📅 Original date posted:2015-06-25
📝 Original message:I agree with all this. However, as a practical matter the consensus
rules are not separated out so one person decides whether the "rough
consensus" has been reached and if the consensus rules should be
changed. It really has nothing to do with any personality involved or
whether they do a good or bad job. The final decision should probably
not fall into the lap of one person but it does for now and that is just
the way it is because there is no better way to do it if you want to get
things done.
I am also not saying any specific process is good or bad, I am saying
the lack of a defined process causes wasted time and effort. Once you
define the process you have now (the baseline) then you can evaluate
whether parts of it are good or bad.
As the developer system transitions into a paid system where commercial
entities hire developers then there is no incentive for them to do that
if changes can never be made. A defined process will give more
assurance for commercial entities to bring more developers on board.
Russ
On 6/25/2015 9:41 AM, Eric Lombrozo wrote:
> Wladimir is doing an amazing job under difficult circumstances. Give the guy a break, please.
>
> - Eric Lombrozo
>
>> On Jun 25, 2015, at 6:36 AM, s7r <s7r at sky-ip.org> wrote:
>>
>> I guess you mean Wladimir here. You are wrong, Wladimir does decide and
>> if you look at the commit history on github.com for bitcoin core you
>> will see, that he does actually decide and does it really good.
>>
>> He just does not want to decide (and he really should not) on CONSENSUS
>> changes or protocol changes. This is totally different.
>>
>> Stop the analogy with "other open source projects". This is an open
>> source project (the code part) but unlike any other open source projects
>> which can just be forked, without affecting the other users, in bitcoin
>> we need all the users to trust a single blockchain, so it'll have value.
>> If some users fork the blockchain and change consensus rules, they are
>> not just harming themselves, they are affecting ALL the users, since
>> such a thing would have strong impact over the BTC/FIAT rate, affecting
>> everyone in the ecosystem. There is economics involved here and human
>> element, things which are hard to fix via code, even if the code is
>> developed in open source style.
>>
>> It's one thing to decide to merge some patches, improve the code, etc.
>> and another thing to decide for consensus rules when you literary play
>> with 4 billion united states dollars of other people's money. This
>> shouldn't be Wladimir's responsibility, it's just unfair for people to
>> throw this on his shoulders.
>>
>> I do not under any circumstances suggest that the consensus should
>> remain as it is now forever. We need to improve it, but this should not
>> be on the maintainer. I've seen smart suggestions on this mail list
>> where consensus changes can be made during a long period of time,
>> through soft forks, where all users/miners/exchangers/merchants get the
>> chance to choose / take action.
>>
>> On 6/25/2015 3:07 AM, Milly Bitcoin wrote:
>>> I have seen this question asked many times. Most developers become
>>> defensive and they usually give a very vague 1-sentence answer when this
>>> question is asked. It seems to be it is based on personalities rather
>>> than any kind of definable process. To have that discussion the
>>> personalities must be separated out and answers like "such-and-such
>>> wouldn't do that" don't really do much to advance the discussion. Also,
>>> the incentive for new developers to come in is that they will be paid by
>>> companies who want to influence the code and this should be considered
>>> (some developers take this statement as an insult when it is just a
>>> statement of the incentive process).
>>>
>>> The other problem you are having is the lead developer does not want to
>>> be a "decider" when, in fact, he is a very significant decider. While
>>> the users have the ultimate choice in a practical sense the chief
>>> developer is the "decider." Now people don't want to get him upset so
>>> nobody wants to push the issue or fully define the process. Now you are
>>> left with a broken, unwritten/unspoken process. While this type of
>>> thing may work with a small group of developers businesses/investors
>>> looking in from the outside will see this as a risk.
>>>
>>> Until you get passed all the personality-based arguments you are going
>>> to have a tough time defining a real process.
>>>
>>> Russ
>>>
>>>
>>>
>>>
>>>
>>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>>> I would like to start a civil discussion on an undefined, or at least
>>>> unwritten, portion of the BIP process. Who should get to vote on
>>>> approval to commit a BIP implementation into Bitcoin Core? Is a
>>>> simple majority of these voters sufficient for approval? If not, then
>>>> what is?
>>>>
>>>> Raystonn
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:40:12 CEST

- reply

📅 Original date posted:2015-06-25
📝 Original message:I am not giving an opinion on the incentive process for developers. I
am just saying it exists and it needs to be taken into account when
developing a process. Pretending it doesn't exist or taking it as some
kind of personal insult does not do anything to advance the process.
The developer incentives feeds into the consensus process.
Depending on some kind of "rough consensus" with unstated
personality-based rules of the game works fine with small projects. As
the project gets larger that does not scale as can be seen with the
recent events. That is just a taste of what will happen in the future
as new issue arise. Developers will end up spending all day tweeting
and making videos instead of writing code.
The current process does not guarantee changes are approved on technical
merit alone and that is part of the problem. Since there is no defined
process people make claims of all sorts of motives that may or may not
exist. The idea is to get a defined process that gives a certain level
of assurance to outsiders that the process is based on things like
technical merit.
Russ
On 6/24/2015 11:42 PM, Gareth Williams wrote:
> On Thu, Jun 25, 2015 at 10:07 AM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
> <snip>
>> Also, the incentive for new
>> developers to come in is that they will be paid by companies who want to
>> influence the code and this should be considered
> <snip>
>> Now you are left with a broken, unwritten/unspoken process.
> Your former statement is a great example of why "rough consensus and
> running code" is superior to design by committee.
> An argument should be assessed on its technical merit alone, not on
> the number of people advancing it -- a process that would be open to
> exactly the type of external manipulation you say you are concerned
> about.
>

2023-06-07 17:40:11 CEST

- reply

📅 Original date posted:2015-06-25
📝 Original message:That description makes sense. It also makes sense to separate out the
hard fork from the soft fork process. Right now some people want to
use the soft fork procedure for a hard fork simply because there is no
other way to do it.
I am under the impression that most users expect changes/improvements
that would require a hard fork so I think some kind of process needs to
be developed. Taking the responsibility off the shoulder of the core
maintainer also makes sense. The hard fork issue is too much of a
distraction for people trying to maintain the nuts and bolts of the
underlying system.
I saw a suggestion that regularly scheduled hard forks should be
planned. That seems to make sense so you would have some sort of
schedule where you would have cut off dates for hard-fork BIP
submissions. That way you avoid the debates over whether there should
be hard forks to what should be contained within the hard fork (if
needed). It makes sense to follow the BIP process as close as
possible. Possibly adding another step after "Dev acceptance" to
include input from others such as merchants/exchanges/miners/users. It
will only be an approximation of "decentralization" and the process
won't be perfect but if you want to move forward then you need some way
to do it.
Russ
On 6/25/2015 4:05 PM, Tier Nolan wrote:
> On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach
> <mark at friedenbach.org <mailto:mark at friedenbach.org>> wrote:
>
> I'm sorry but this is absolutely not the case, Milly. The reason
> that people get defensive is that we have a carefully constructed
> process that does work (thank you very much!) and is well documented.
>
>
> There is no process for handling hard forks, which aren't bug fixes.
>
> Soft forks have a defined process of something like
>
> - BIP proposal + discussion
> - Proposed code
> - Dev acceptance
> - Release
> - Miner vote/acceptance
>
> The devs have a weak veto. If they refuse to move forward with
> changes, miners could perform a soft fork on their own. They don't
> want to do that, as it would be controversial and the devs know the
> software better.
>
> The miner veto is stronger (for soft forks) but not absolute. The
> devs could checkpoint/blacklist a chain if miners implemented a fork
> that wasn't acceptable (assuming the community backed them).
>
> When ASICs arrived, it was pointed out by some that the devs could hit
> back if ASICs weren't made publicly available. If they slightly
> tweaked the hashing algorithm, then current generation of ASICs would
> be useless. The potential threat may have acted as a disincentive
> for ASIC manufacturers to use the ASICs themselves.
>
> Moving forward with agreement between all involved is the recommended
> and desirable approach.
>
> Consensus between all parties is the goal but isn't absolutely
> required. This escape valve is partly what makes consensus work. If
> you dig your heels in, then the other side can bypass you, but they
> have an incentive to try to convince you to compromise first. The
> outcome is better if a middle ground can be found.
>
> Hard forks are different. The "checks and balances" of weak vetoes
> are not present. This means that things can devolve from consensus to
> mutual veto. Consensus ceases to be a goal and becomes a requirement.
>
> This is partly a reflection of the nature of hard forks. Everyone
> needs to upgrade. On the other hand, if most of the various groups
> upgrade, then users of the legacy software would have to upgrade or
> get left behind. If 5% of the users decided not to upgrade, should
> they be allowed to demand that nobody else does?
>
> There is clearly some kind of threshold that is reasonable.
>
> The fundamental problem is that there isn't agreement on what the
> block size is. Is it equal in status to the 21 million BTC limit?
>
> If Satoshi had said that 1MB was part of the definition of Bitcoin,
> then I think people would accept it to the same extent as they accept
> the 21 million coin limit. It might cause people to leave the coin
> though.
>
> It was intended to be temporary, but people have realized that it
> might be a good idea to keep it. In effect both sides could argue
> that they should be considered the status quo.
>
> I wonder if a coin toss would be acceptable :). "Come to an agreement
> or we decide by coin toss"
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/f1c23619/attachment.html>

2023-06-07 17:40:10 CEST

- reply

📅 Original date posted:2015-06-25
📝 Original message:"Cultish" means making claims without any supporting facts. Labeling
Open Source software as being "decentralized" just because people can
choose which version to run is a "cultish" claim. Just because Bitcoin
uses the mining process to come to consensus over the state of the
ledger that does not mean the software versions have the same level of
decentralization because users can decide which version to run. I am in
the USA and I can vote in elections but I would not call the US
government "decentralized." It is a very complicated issue and cannot
be explained in one or two sentences of hand-waiving arguments like you
often see here.
Russ
On 6/25/2015 3:51 AM, cipher anthem wrote:
> +1 on this!
>
> I have come across Milly a couple of times on reddit and disqus and
> she basically dismisses anyone who doesn't agree with her opinions.
> always labeling them "cultish". Please ignore her so you can stay
> productive.
> *Sent:* Thursday, June 25, 2015 at 5:07 AM
> *From:* "Jeff Garzik" <jgarzik at gmail.com>
> *To:* bitcoin-dev at lists.linuxfoundation.org
> *Subject:* Re: [bitcoin-dev] BIP Process and Votes
> Ladies & gents, please do not feed the troll. This has been explained
> to Milly multiple times in the past, on previous mailing list & github
> with no impact.
> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info>
> wrote:
>
> I'm sorry but that is the kind of defensive, cultish response
> everyone gets when they ask that question. If you had a well
> constructed documented process then you would be able to point to
> it ... but you can't. While there are a few bits and pieces
> scattered about in different places there is no coherent plan or
> process.
>
> It is easy to make statements like "consensus must be unanimous"
> but the issue is that you never have true 100% consensus yet you
> have to move forward in some fashion and everyone has to run
> software with the same consensus rules. The issue is how you move
> forward is the question that nobody wants to answer because (a) it
> is a hard question to answer and (b) developers see it as a threat
> to their authority/position. If people just keep shutting down
> the discussion with a bunch of cultish stock answers then you are
> never going to move forward with developing some kind of process.
>
> >From what I can see much of the discussion is personality-driven
> and not based on Computer Science or and defined process. The
> issue is that a personality has changed so the process is
> perceived to be different and some people want to hard fork.
> Previously, the cultish answer is that Bitcoin development is
> decentralized because people can fork the code. Now that some
> developers want to fork the code suddenly it is a big problem.
> Is forking the code part of the consensus process or is it the
> work of the devil? The fact that there is so much diverse
> opinion on this shows a defined process has never been fully
> vetted or understood.
>
> I have worked on these processes for many years for projects
> orders of magnitudes larger than Bitcoin. I can absolutely assure
> you the current mishmash does not scale and huge amounts of time
> are wasted. That should be readily apparent from the recent
> discussions and the recent concern it has caused from people
> outside the developer's inner circle.
>
> Lack of defined process = high risk and wasted effort.
>
> Russ
>
>
>
>
>
> On 6/24/2015 9:50 PM, Mark Friedenbach wrote:
>
> I'm sorry but this is absolutely not the case, Milly. The
> reason that people get defensive is that we have a carefully
> constructed process that does work (thank you very much!) and
> is well documented. We talk about it quite often in fact as it
> is a defining characteristic of how bitcoin is developed which
> differs in some ways from how other open source software is
> developed -- although it remains the same in most other ways.
> Changes to the non-consensus sections of Bitcoin Core tend to
> get merged when there are a few reviews, tests, and ACKs from
> recognized developers, there are no outstanding objections,
> and the maintainer doing the merge makes a subjective
> judgement that the code is ready.
> Consensus-changes, on the other hand, get merged into Bitcoin
> Core only after the above criteria are met AND an extremely
> long discussion period that has given all the relevant
> stakeholders a chance to comment, and no significant
> objections remain. Consensus-code changes are unanimous. They
> must be.
> The sort of process that exists in standards bodies for
> example, with working groups and formal voting procedures, has
> no place where changes define the nature and validity of other
> people's money. Who has the right to reach into your pocket
> and define how you can or cannot spend your coins? The premise
> of bitcoin is that no one has that right, yet that is very
> much what we do when consensus code changes are made. That is
> why when we make a change to the rules governing the nature of
> bitcoin, we must make sure that everyone is made aware of the
> change and consents to it.
> Everyone. Does this work? Does this scale? So far, it does.
> Uncontroversial changes, such as BIP 66, are deployed without
> issue. Every indication is that BIP 66 will complete
> deployment in the very near future, and we intend to repeat
> this process for more interesting changes such as BIP65:
> CHECKLOCKTIMEVERIFY.
> This isn't about no one stepping forward to be the "decider."
> This is about no one having the right to decide these things
> on the behalf of others. If a contentious change is proposed
> and not accepted by the process of consensus, that is because
> the process is doing its job at rejecting controversial
> changes. It has nothing to do with personality, and everything
> to do with the nature of bitcoin itself.
> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin
> <milly at bitcoins.info> wrote:
>
> I have seen this question asked many times. Most
> developers become defensive and they usually give a very
> vague 1-sentence answer when this question is asked. It
> seems to be it is based on personalities rather than any
> kind of definable process. To have that discussion the
> personalities must be separated out and answers like
> "such-and-such wouldn't do that" don't really do much to
> advance the discussion. Also, the incentive for new
> developers to come in is that they will be paid by
> companies who want to influence the code and this should
> be considered (some developers take this statement as an
> insult when it is just a statement of the incentive process).
>
> The other problem you are having is the lead developer
> does not want to be a "decider" when, in fact, he is a
> very significant decider. While the users have the
> ultimate choice in a practical sense the chief developer
> is the "decider." Now people don't want to get him upset
> so nobody wants to push the issue or fully define the
> process. Now you are left with a broken,
> unwritten/unspoken process. While this type of thing may
> work with a small group of developers businesses/investors
> looking in from the outside will see this as a risk.
>
> Until you get passed all the personality-based arguments
> you are going to have a tough time defining a real process.
>
> Russ
>
>
>
>
>
>
> On 6/24/2015 7:41 PM, Raystonn wrote:
>
> I would like to start a civil discussion on an
> undefined, or at least unwritten, portion of the BIP
> process. Who should get to vote on approval to commit
> a BIP implementation into Bitcoin Core? Is a simple
> majority of these voters sufficient for approval? If
> not, then what is?
>
> Raystonn
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/51d968ab/attachment-0001.html>

2023-06-07 17:40:06 CEST

- reply

📅 Original date posted:2015-06-25
📝 Original message:These are the kind of silly responses you often get when this subject
comes up. Mr. Garzik knows how to ignore messages he doesn't want so I
see no need for him to use the list to attack people he doesn't agree
with and/or try to interfere with discussions of others on the list.
He turns it into a personality discussion rather than a discussion of
Systems Engineering. He also tries to intimate anyone who brings up the
discussion and "punish" them as a lesson to anyone else who may raise
the issue.
It is interesting that people like that are attracted to a decentralized
system. The reply is simply an attempt at protecting turf which is why
Mr. Garzik's vague replies are never taken seriously on the subject of
decision-making process for the software.
Russ
On 6/25/2015 1:07 AM, Jeff Garzik wrote:
> Ladies & gents, please do not feed the troll. This has been explained
> to Milly multiple times in the past, on previous mailing list & github
> with no impact.
>
>
> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info
> <mailto:milly at bitcoins.info>> wrote:
>
> I'm sorry but that is the kind of defensive, cultish response
> everyone gets when they ask that question. If you had a well
> constructed documented process then you would be able to point to
> it ... but you can't. While there are a few bits and pieces
> scattered about in different places there is no coherent plan or
> process.
>
> It is easy to make statements like "consensus must be unanimous"
> but the issue is that you never have true 100% consensus yet you
> have to move forward in some fashion and everyone has to run
> software with the same consensus rules. The issue is how you move
> forward is the question that nobody wants to answer because (a) it
> is a hard question to answer and (b) developers see it as a threat
> to their authority/position. If people just keep shutting down
> the discussion with a bunch of cultish stock answers then you are
> never going to move forward with developing some kind of process.
>
> From what I can see much of the discussion is personality-driven
> and not based on Computer Science or and defined process. The
> issue is that a personality has changed so the process is
> perceived to be different and some people want to hard fork.
> Previously, the cultish answer is that Bitcoin development is
> decentralized because people can fork the code. Now that some
> developers want to fork the code suddenly it is a big problem.
> Is forking the code part of the consensus process or is it the
> work of the devil? The fact that there is so much diverse
> opinion on this shows a defined process has never been fully
> vetted or understood.
>
> I have worked on these processes for many years for projects
> orders of magnitudes larger than Bitcoin. I can absolutely assure
> you the current mishmash does not scale and huge amounts of time
> are wasted. That should be readily apparent from the recent
> discussions and the recent concern it has caused from people
> outside the developer's inner circle.
>
> Lack of defined process = high risk and wasted effort.
>
> Russ
>
>
>
>
>
> On 6/24/2015 9:50 PM, Mark Friedenbach wrote:
>> I'm sorry but this is absolutely not the case, Milly. The reason
>> that people get defensive is that we have a carefully constructed
>> process that does work (thank you very much!) and is well
>> documented. We talk about it quite often in fact as it is a
>> defining characteristic of how bitcoin is developed which differs
>> in some ways from how other open source software is developed --
>> although it remains the same in most other ways.
>>
>> Changes to the non-consensus sections of Bitcoin Core tend to get
>> merged when there are a few reviews, tests, and ACKs from
>> recognized developers, there are no outstanding objections, and
>> the maintainer doing the merge makes a subjective judgement that
>> the code is ready.
>>
>> Consensus-changes, on the other hand, get merged into Bitcoin
>> Core only after the above criteria are met AND an extremely long
>> discussion period that has given all the relevant stakeholders a
>> chance to comment, and no significant objections remain.
>> Consensus-code changes are unanimous. They must be.
>>
>> The sort of process that exists in standards bodies for example,
>> with working groups and formal voting procedures, has no place
>> where changes define the nature and validity of other people's
>> money. Who has the right to reach into your pocket and define how
>> you can or cannot spend your coins? The premise of bitcoin is
>> that no one has that right, yet that is very much what we do when
>> consensus code changes are made. That is why when we make a
>> change to the rules governing the nature of bitcoin, we must make
>> sure that everyone is made aware of the change and consents to it.
>>
>> Everyone. Does this work? Does this scale? So far, it does.
>> Uncontroversial changes, such as BIP 66, are deployed without
>> issue. Every indication is that BIP 66 will complete deployment
>> in the very near future, and we intend to repeat this process for
>> more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY.
>>
>> This isn't about no one stepping forward to be the "decider."
>> This is about no one having the right to decide these things on
>> the behalf of others. If a contentious change is proposed and not
>> accepted by the process of consensus, that is because the process
>> is doing its job at rejecting controversial changes. It has
>> nothing to do with personality, and everything to do with the
>> nature of bitcoin itself.
>>
>>
>> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin
>> <milly at bitcoins.info <mailto:milly at bitcoins.info>> wrote:
>>
>> I have seen this question asked many times. Most developers
>> become defensive and they usually give a very vague
>> 1-sentence answer when this question is asked. It seems to
>> be it is based on personalities rather than any kind of
>> definable process. To have that discussion the personalities
>> must be separated out and answers like "such-and-such
>> wouldn't do that" don't really do much to advance the
>> discussion. Also, the incentive for new developers to come in
>> is that they will be paid by companies who want to influence
>> the code and this should be considered (some developers take
>> this statement as an insult when it is just a statement of
>> the incentive process).
>>
>> The other problem you are having is the lead developer does
>> not want to be a "decider" when, in fact, he is a very
>> significant decider. While the users have the ultimate
>> choice in a practical sense the chief developer is the
>> "decider." Now people don't want to get him upset so nobody
>> wants to push the issue or fully define the process. Now you
>> are left with a broken, unwritten/unspoken process. While
>> this type of thing may work with a small group of developers
>> businesses/investors looking in from the outside will see
>> this as a risk.
>>
>> Until you get passed all the personality-based arguments you
>> are going to have a tough time defining a real process.
>>
>> Russ
>>
>>
>>
>>
>>
>>
>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>
>> I would like to start a civil discussion on an undefined,
>> or at least unwritten, portion of the BIP process. Who
>> should get to vote on approval to commit a BIP
>> implementation into Bitcoin Core? Is a simple majority
>> of these voters sufficient for approval? If not, then
>> what is?
>>
>> Raystonn
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/3deb2320/attachment.html>

2023-06-07 17:40:05 CEST

- reply

📅 Original date posted:2015-06-24
📝 Original message:I'm sorry but that is the kind of defensive, cultish response everyone
gets when they ask that question. If you had a well constructed
documented process then you would be able to point to it ... but you
can't. While there are a few bits and pieces scattered about in
different places there is no coherent plan or process.
It is easy to make statements like "consensus must be unanimous" but the
issue is that you never have true 100% consensus yet you have to move
forward in some fashion and everyone has to run software with the same
consensus rules. The issue is how you move forward is the question that
nobody wants to answer because (a) it is a hard question to answer and
(b) developers see it as a threat to their authority/position. If
people just keep shutting down the discussion with a bunch of cultish
stock answers then you are never going to move forward with developing
some kind of process.
From what I can see much of the discussion is personality-driven and
not based on Computer Science or and defined process. The issue is that
a personality has changed so the process is perceived to be different
and some people want to hard fork. Previously, the cultish answer is
that Bitcoin development is decentralized because people can fork the
code. Now that some developers want to fork the code suddenly it is a
big problem. Is forking the code part of the consensus process or is it
the work of the devil? The fact that there is so much diverse opinion
on this shows a defined process has never been fully vetted or understood.
I have worked on these processes for many years for projects orders of
magnitudes larger than Bitcoin. I can absolutely assure you the current
mishmash does not scale and huge amounts of time are wasted. That
should be readily apparent from the recent discussions and the recent
concern it has caused from people outside the developer's inner circle.
Lack of defined process = high risk and wasted effort.
Russ
On 6/24/2015 9:50 PM, Mark Friedenbach wrote:
> I'm sorry but this is absolutely not the case, Milly. The reason that
> people get defensive is that we have a carefully constructed process
> that does work (thank you very much!) and is well documented. We talk
> about it quite often in fact as it is a defining characteristic of how
> bitcoin is developed which differs in some ways from how other open
> source software is developed -- although it remains the same in most
> other ways.
>
> Changes to the non-consensus sections of Bitcoin Core tend to get
> merged when there are a few reviews, tests, and ACKs from recognized
> developers, there are no outstanding objections, and the maintainer
> doing the merge makes a subjective judgement that the code is ready.
>
> Consensus-changes, on the other hand, get merged into Bitcoin Core
> only after the above criteria are met AND an extremely long discussion
> period that has given all the relevant stakeholders a chance to
> comment, and no significant objections remain. Consensus-code changes
> are unanimous. They must be.
>
> The sort of process that exists in standards bodies for example, with
> working groups and formal voting procedures, has no place where
> changes define the nature and validity of other people's money. Who
> has the right to reach into your pocket and define how you can or
> cannot spend your coins? The premise of bitcoin is that no one has
> that right, yet that is very much what we do when consensus code
> changes are made. That is why when we make a change to the rules
> governing the nature of bitcoin, we must make sure that everyone is
> made aware of the change and consents to it.
>
> Everyone. Does this work? Does this scale? So far, it does.
> Uncontroversial changes, such as BIP 66, are deployed without issue.
> Every indication is that BIP 66 will complete deployment in the very
> near future, and we intend to repeat this process for more interesting
> changes such as BIP65: CHECKLOCKTIMEVERIFY.
>
> This isn't about no one stepping forward to be the "decider." This is
> about no one having the right to decide these things on the behalf of
> others. If a contentious change is proposed and not accepted by the
> process of consensus, that is because the process is doing its job at
> rejecting controversial changes. It has nothing to do with
> personality, and everything to do with the nature of bitcoin itself.
>
>
> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin <milly at bitcoins.info
> <mailto:milly at bitcoins.info>> wrote:
>
> I have seen this question asked many times. Most developers
> become defensive and they usually give a very vague 1-sentence
> answer when this question is asked. It seems to be it is based on
> personalities rather than any kind of definable process. To have
> that discussion the personalities must be separated out and
> answers like "such-and-such wouldn't do that" don't really do much
> to advance the discussion. Also, the incentive for new developers
> to come in is that they will be paid by companies who want to
> influence the code and this should be considered (some developers
> take this statement as an insult when it is just a statement of
> the incentive process).
>
> The other problem you are having is the lead developer does not
> want to be a "decider" when, in fact, he is a very significant
> decider. While the users have the ultimate choice in a practical
> sense the chief developer is the "decider." Now people don't want
> to get him upset so nobody wants to push the issue or fully define
> the process. Now you are left with a broken, unwritten/unspoken
> process. While this type of thing may work with a small group of
> developers businesses/investors looking in from the outside will
> see this as a risk.
>
> Until you get passed all the personality-based arguments you are
> going to have a tough time defining a real process.
>
> Russ
>
>
>
>
>
>
> On 6/24/2015 7:41 PM, Raystonn wrote:
>
> I would like to start a civil discussion on an undefined, or
> at least unwritten, portion of the BIP process. Who should
> get to vote on approval to commit a BIP implementation into
> Bitcoin Core? Is a simple majority of these voters sufficient
> for approval? If not, then what is?
>
> Raystonn
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150624/a0c7ba21/attachment-0001.html>

2023-06-07 17:40:04 CEST

- reply

📅 Original date posted:2015-06-24
📝 Original message:I have seen this question asked many times. Most developers become
defensive and they usually give a very vague 1-sentence answer when this
question is asked. It seems to be it is based on personalities rather
than any kind of definable process. To have that discussion the
personalities must be separated out and answers like "such-and-such
wouldn't do that" don't really do much to advance the discussion. Also,
the incentive for new developers to come in is that they will be paid by
companies who want to influence the code and this should be considered
(some developers take this statement as an insult when it is just a
statement of the incentive process).
The other problem you are having is the lead developer does not want to
be a "decider" when, in fact, he is a very significant decider. While
the users have the ultimate choice in a practical sense the chief
developer is the "decider." Now people don't want to get him upset so
nobody wants to push the issue or fully define the process. Now you are
left with a broken, unwritten/unspoken process. While this type of
thing may work with a small group of developers businesses/investors
looking in from the outside will see this as a risk.
Until you get passed all the personality-based arguments you are going
to have a tough time defining a real process.
Russ
On 6/24/2015 7:41 PM, Raystonn wrote:
> I would like to start a civil discussion on an undefined, or at least unwritten, portion of the BIP process. Who should get to vote on approval to commit a BIP implementation into Bitcoin Core? Is a simple majority of these voters sufficient for approval? If not, then what is?
>
> Raystonn
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:40:03 CEST

- reply

📅 Original date posted:2015-06-24
📝 Original message:>There is no voting in the way you think. Devs commit changes the users
will accept and use. Users "fire" developers by choosing different devs
or different software.
>Standard open source method.
Most open source projects do not require 100% user adoption in order for
other users to be compatible. Very different than most open source
projects. Repeating "stock" answers does nothing to advanced the
discussion.
Russ

2023-06-07 17:39:14 CEST

- reply

📅 Original date posted:2015-06-19
📝 Original message:"prima facie" generally means that in a court case the burden of proof
shifts from one party to another. For instance, if you have a federal
trademark registration that is prima fascia evidence of those rights
even though they could still be challenged. To say a prosecutor would
have prima fascia evidence of a crime because double spend was detected
is quite a stretch.
On 6/19/2015 12:36 PM, Matt Whitlock wrote:
> On Friday, 19 June 2015, at 3:53 pm, justusranvier at riseup.net wrote:
>> I'd also like to note that "prima facie" doesn't mean "always", it means
>> that "the default assumption, unless proven otherwise."
> Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:38:41 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:On 6/18/2015 11:03 AM, Mark Friedenbach wrote:
> On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn <mike at plan99.net
> <mailto:mike at plan99.net>> wrote:
>
> The first issue is how are decisions made in Bitcoin Core? I
> struggle to explain this to others because I don't understand it
> myself. Is it a vote of people with commit access? Is it a 100%
> agreement of "core developers" and if so, who are these people? Is
> it "whoever reverts the change last"? Could I write down in a
> document a precise description of how decisions are made? No, and
> that's been a fairly frustrating problem for a long time.
>
>
> There is a quote from United States Supreme Court Justice Potter
> Stewart to describe his threshold test for obscenity which is relevant
> here: "I know it when I see it."
>
> It is hard certainly, and perhaps even impossible to write down a
> system of rules that is used to resolve every dispute among core
> developers. But that doesn't mean it isn't obvious to all the
> participants what is going on. If a contentious change is proposed,
> and if after sufficient debate there are still members of the
> technical community with reasoned, comprehensible objections who are
> not merely being obstinate in the views -- a neutral observer would
> agree that their concerns have not been met -- then there is a lack of
> consensus.
>
> If there was some sort of formal process however, the system wouldn't
> work. Rules can be gamed, and if you add rules to a process then that
> process can be gamed. Instead we all have a reasonable understanding
> of what "technical consensus" is, and we all know it when we see it.
> Where we do not see it, we do not proceed.
>
There is always a process. Right now the process is haphazard, unclear,
and constantly changing without being written down so people don't
actually know what it is. In fact you do not all have a reasonable
understanding of "technical consensus" because if you did then you could
write it down ... but you can't. The current process is being gamed by
people making tweets, reddit posts, videos, and blog posts. A more
formalized process would channel that activity into a a more usable format.
This kind of thing always happens as projects become larger and more
diverse. Something that was once a small group turns into a big group
of diverse stakeholders. When it gets too big for the informal
processes then some people get upset and defensive. Happens all the time
but it is not really a good excuse to keep doing things in an
inefficient manner. The old ways just don't scale and if you ever
worked on massive projects then you know these formal processes work better.
Russ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/84bd5100/attachment.html>

2023-06-07 17:38:40 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:What is immediately clear to anyone who looks at Bitcoin software
development is that there is no clear process or method to make
changes/updates to the software. When I have questioned this in the
past the response is usually some cultish answer about how some kind of
technical consensus is reached yet nobody can point to an actual
process. If companies are expected to dedicate resources to adopt
Bitcoin there needs to be some type of process spelled out that can give
these entities at least minimal assurance that there is some type of
process in place. I think the whole process is based on how certain
personalities handle issues but as those personalities change the system
changes in unknown ways which equates to risk.
The other thing that is immediately clear is that there is no systems
engineering process in place to make changes. A "risk study" was done
by the Bitcoin Foundation but that is only the first baby step in the
process. It works by defining a set of risks, likelihood, mitigations,
etc. and a risk matrix and maintaining those as living documents.
When changes are proposed alternative scenarios are created and they are
measured against the baseline of what there is now. Standard test plans
are created to measure the changes against defined metrics. It is a lot
of work to define those risks to the level of detail needed for work
like this. However, the amount of time/energy saved in the end is
tremendous. Right now the process is haphazard at best with people
posting random tweets, Reddit posts, blog posts, etc. All this drama
makes Bitcoin look somewhat amateurish and rather risky.
http://www.dtic.mil/ndia/2004cmmi/CMMIT1Mon/Track1IntrotoSystemsEngineering/KISE09RiskManagementv2.pdf
https://bitcoinfoundation.org/wp-content/uploads/2014/04/Bitcoin-Risk-Management-Study-Spring-2014.pdf
Some people also seems to conflates the notion of decentralization of
the state of the ledger by mining/nodes with that of decentralization of
open source software by forking the software. These are very different
problems and I don't think it is possible (or even desirable) to achieve
the same level of decentralization for both things. In any case
"decentralization" for the state of the blockchain is only an
approximation anyway since there are things like 51% attacks and
checkpoints.
Russ
On 6/18/2015 7:14 AM, Wladimir J. van der Laan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote:
>
>> Core is in the weird position where there's no decision making ability at
>> all, because anyone who shows up and shouts enough can generate
>> 'controversy', then Wladimir sees there is disagreement and won't touch the
>> issue in question. So it just runs and runs and *anyone* with commit access
>> can then block any change.
> Bitcoin Core is completely different from your average open source project in one aspect: where it concerns consensus.
>
> Like in any open source project there is lots of decision making ability for code changes. I'd say look at the changelog for e.g. 0.11 https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log, or follow pull requests for a while, to see how many decisions about changes are made from day to day. No, I'm not sitting on my hands, and so is none of the other contributors that you'd like to get rid of.
>
> Consensus changes are *much* more difficult, on the other hand. Even relatively straightforward softforks come with a long discussion process (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone needs to upgrade their software!), and simply not possible if almost the entire technical community disagrees with you.
>
> Bitcoin is supposed to be a robust, global, decentralized network beyond anyone's control. It makes *no sense* to try to run it as a dictatorship. This would create a handy central position where power can be applied, pushing through changes to the behavior of the system, either by force or other ways of motivation. I refuse to take part in that.
>
> Hence, anything that is controversial needs to be considered really carefully. If I suddenly start making changes to the consensus code without full agreement, by all means take away my commit privileges.
>
> (a major reason for the ongoing libconsensus work is to separate "Bitcoin Core, the node software" and "The Bitcoin Consensus" along clear lines, to avoid this kind of nasty confusion)
>
> Wladimir
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJVgqfOAAoJEHSBCwEjRsmmFT8H/Rkm29AhLhT8R1Vx8oKUIzID
> +NB7tOps3lIilkDQIC5zHSknx5iugrrAdRf1w7qPj/o8+xhCZw9ruu8eIq+djkRQ
> tvzbHil2pqgT3VHriRlY4lvlmu2NmBcYrAuX9sDhUHBo6cwGajfKMJPfE0haK3K4
> 7EmfdGXJYJmiBnhE6ikOiU687M2WgsmIGrBDIxeA5wYwVK9Ph8hfcbuj7AHvIMI9
> ZNU/V6uhcTjn5wT+6DHGIOxHipYHyAwKb7jKho0XkM6Yi4ORe1mxF5HDtqA0ztta
> mZPNjNrt/ngK20xRbqkb0GtxoyZq38ZF3Bq1gaWl2v9MBBMD5ZxQAvgCNUQFEo0=
> =W26K
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

2023-06-07 17:38:32 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:>2) Changes to the consensus rules: As others have said, this isn't
anyone's decision for anyone else. It's up to each individual user as
to what code they run and what rules they enforce. So then why is
everyone so up in arms about what Mike and Gavin are proposing if
everyone is free to decide for themselves?
Because the notion that people are free to decide for themselves is just
a rough approximation of the real world situation. If your software
does not agree with merchants and exchanges you can't pay your bills and
if Bitcoin splits the exchange rate could plummet and damage the
ecosystem. People are free to decide within the constraints of the
Bitcoin system.
Russ

2023-06-07 17:38:30 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:>Impacts, yes, decider, no. Multiple ACKs are required from developers
who will not act if the community will disagree with the change.
>The users ultimately choose by deciding which software to download,
and that dictates the range of choices available.
That is what I mean by a cultish reply. Just saying the users
ultimately decide is not an adequate explanation of the situation. You
are talking hard fork if someone doesn't like it. If 10% of the users
don't like there is nothing they can do unless they want to operate an
altcoin. You are not going to resolve anything by repeating these types
of replies that really have no applicability in the real world. The
person who approves the pull request (no matter what the process is
beforehand) is effectively the decider.
Also, as pointed out, there is no real process in place. Making
offhand statements that "multiple ACKs are required" without describing
a real process just sends people down a rat hole like this block size
debate. Providing these (non) answers instead of developing a real
process is why there is so much contention now.
Russ

2023-06-07 17:38:30 CEST

- reply

📅 Original date posted:2015-06-18
📝 Original message:>So I'm *not* the decider for anything that concerns the behavior of
the global consensus, and I cannot be, as I have explained in the
previous post.
The person who decides if a pull request is accepted is a decider and
significantly affects the behavior of the global consensus. The only
option for someone who doesn't agree is to hard fork. There is no way
around that and you should just accept that fact and move on.
Russ