From: yanmaani@cock.li
To: Prayank <prayank@tutanota.de>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0
Date: Fri, 05 Nov 2021 14:45:36 +0000 [thread overview]
Message-ID: <3d686c3a100338514c3ebcc264ec24f2@cock.li> (raw)
In-Reply-To: <MnjA6g0--3-2@tutanota.de>
On 2021-11-05 08:17, Prayank via bitcoin-dev wrote:
> What followed it (whitepaper being shared on different websites) was
> true decentralization and we need something similar in other aspects
> of full node implementations. Few things that can improve
> decentralization:
>
> 1.More people using alternative full node implementations. Right now
> 98% of nodes use Bitcoin Core.
Unfortunately, this isn't really possible. If they did that, you could
get consensus splits. This is why all the other stuff is so important -
if Bitcoin is subverted via soft-fork, you *can't* just run your own
fork.
Theoretically, I suppose you could run two implementations and do
something if they differ, but what?
1. Bitcoin Core and <AltImpl> both say block is valid -> valid
2. Bitcoin Core and <AltImpl> both say block is invalid -> invalid
3. Bitcoin Core says valid, <AltImpl> says invalid -> valid (or get
forked off)
4. Bitcoin Core says invalid, <AltImpl> says valid -> invalid (or
hardfork)
> 2.More people like Luke Dashjr and Amir Taaki who do not simp for
> anyone. Being a contributor or maintainer in Bitcoin full node
> implementation is different from other open source projects. It was
> never going to be easy and it will get difficult with time,
This is all about the money - it's easy to have people be independent
when their source of money is independent. But nobody's crazy enough to
bite the hand that feeds them, and you couldn't really build a system on
that basis. Our best hope is gentle hands, or contributors wealthy
enough not to have to care.
(Whatever happened to Amir Taaki, by the way?)
> 3.More people from different countries getting involved in important
> roles.
Isn't Bitcoin already plenty distributed? Funding people in
under-represented countries seems to me like a textbook exercise in
'box-ticking, but moreover, I'd frankly rather have reasonably well-off
guys from Western Europe/America who have the financial backbone to not
worry that much about attacks to their funding, than mercenaries who
have to follow orders or get fired. Even if they're from West
Uzbekistan.
(Maybe they need a union?)
> 4.Few anons.
Gonna guess you mean "a few anons," not fewer anons.
Again, problem is money. These days, nobody threatens anyone with
anything substantive, like murder - the threats all involve cutting off
some funding. So having anonymous people being funded by non-robust
sources doesn't really buy you that much, because the weakest link will
pretty much never be the de-jure, legal freedom of an individual.
Having a system that allows people to fund anonymous people better would
be interesting, but it has some challenges with trust and so on.
> 5.Individuals and organizations who fund different Bitcoin projects
> should consider contributing in alternative. full node implementations
> as well. Maybe start with Bitcoin Knots.
See above. Bitcoin Knots isn't really independent. btcd in Go is, so I
guess they could try that. But at the end of the day, it wouldn't help -
btcd has to be bug-for-bug compatible with Core, and it couldn't really
be any other way.
For my $0.05, what's needed is more "hard money" - if people could make
donations into a fund, with the fund then paying out to developers, and
that fund be controlled in a civilized and non-centralized way (that's
the hard part!), this would somewhat insulate developers from people
threatening to stop their contributions to The Fund, at the price of
having developers being able to be coerced by The Fund.
You could also look into a system like Monero's CCS. But at the end of
the day, funding is really a very difficult problem, no matter how you
slice it. The money still has to enter the system somehow. Since Bitcoin
is a public good, you can't really capture its value, and this means
individuals who can (e.g. by malicious activity) will always have the
leg up.
next prev parent reply other threads:[~2021-11-05 14:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-20 14:47 [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0 Prayank
2021-10-20 19:20 ` Owen Gunden
2021-10-20 19:37 ` Pieter Wuille
2021-10-20 19:49 ` Owen Gunden
2021-10-20 19:43 ` Charles Hill
2021-10-20 20:18 ` Kate Salazar
2021-11-05 8:17 ` Prayank
2021-11-05 10:52 ` damian
2021-11-05 14:45 ` yanmaani [this message]
2021-11-08 3:02 ` ZmnSCPxj
2021-11-09 12:49 ` Prayank
-- strict thread matches above, loose matches on Subject: below --
2021-10-20 21:50 Andrew Chow
2021-10-20 12:54 Owen Gunden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d686c3a100338514c3ebcc264ec24f2@cock.li \
--to=yanmaani@cock.li \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=prayank@tutanota.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox