What is Nostr?
NotMike Hearn [ARCHIVE] /
npub1kkr…fx4e
2023-06-07 17:42:52

NotMike Hearn [ARCHIVE] on Nostr: đź“… Original date posted:2015-10-06 đź“ť Original message:> > > On Mon, Oct 5, 2015 ...

đź“… Original date posted:2015-10-06
đź“ť Original message:>
>
> On Mon, Oct 5, 2015 at 11:20 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

>
> > On Oct 5, 2015, at 6:37 PM, Tom Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > On 10/5/2015 1:56 PM, Gregory Maxwell via bitcoin-dev wrote:
> >> In this case, I don't even believe we have any regulator contributors
> >> that disagree.
> >
> > Since Gavin Andresen chose you to be one of 4 people who decides whose
> > contributions are accepted to the Core project, shouldn't you recuse
> > yourself from referencing "regular contributor" as some kind of bar to
> > an opinion being worthy?
> >
> > You don't want to be accused of squelching a person's opinions by
> > nacking or sitting on commits, then turning around and branding those
> > opinions as worthless because they are not from a "regular contributor."
> > Do you?
>
> Great point, Tom!
>
> In fact, you’ve just explained the dynamics that create “centralizing
> pressure” in regards to development: If the weight of a person’s opinion
> is proportional to how many commits that person has made, and if the
> probability of getting a commit pulled is proportional to the weight of
> that person’s opinion, well…I’m pretty sure this results in a differential
> equation that has a solution that results in ever-increasing centralized
> control of the code base.
>

Really great stuff, Mr. R! We can use differential equations to measure
centralization pressure (I'm pretty sure, good idea). If we want
decentralization (or even mere stability), we must impose a
counterbalancing rule such that each past commit makes one *less* likely to
get their next commit pulled. For example, a "one man one commit" policy.


>
> I believe we should work to deprecate the idea that Core is somehow the
> “core of Bitcoin," in favour of multiple competing implementations. XT and
> btcd are two working examples of this idea. Let’s make it easier for the
> community to determine the evolution of Bitcoin by making it easier for the
> community to express their vote based on the code we choose to run.
>

Yes, this is essential. Greg, stop making it so hard for me to determine
the evolution of Bitcoin by making it hard to express my vote based on the
code I choose to run. Blockstream is always doing that I am sick of it.

Mr. R really understands these concepts at a deep level and people need to
pay more attention to what he has to say. Nash equilibriums are very
important mathematical concept, for example:
https://www.reddit.com/r/Bitcoin/comments/3nhq5a/deprecating_bitcoin_core_visualizing_the/


>
> Best regards,
> Peter
> _______________________________________________
> 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/20151006/251be515/attachment-0001.html>;
Author Public Key
npub1kkr20dcfa7a27uqrlkryqwxangtngc9nmx9cdlpyp3yvq37s8wsqz7fx4e