What is Nostr?
Eric Lombrozo [ARCHIVE] /
npub1azv…2krq
2023-06-07 15:40:13
in reply to nevent1q…hcz8

Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-25 📝 Original message:Wladimir is doing an ...

📅 Original date posted:2015-06-25
📝 Original message: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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/79673426/attachment.sig>;
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq