path: root/90/23450a79ca3e97c59de4a4934817da32d69383

Return-Path: <prayank@tutanota.de>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 0EC33C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 Nov 2021 12:49:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0AB6280D77
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 Nov 2021 12:49:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=tutanota.de
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ggArVwO1USDc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 Nov 2021 12:49:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 4D29280D6F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  9 Nov 2021 12:49:16 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
 by w1.tutanota.de (Postfix) with ESMTP id 41911FBF613;
 Tue,  9 Nov 2021 12:49:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1636462154; 
 s=s1; d=tutanota.de;
 h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;
 bh=Xi99kSZ8od263f6w8KLzOI2E6DAN/lPd1XVDxV/LGj0=;
 b=G4Mjv7btpoOY2XywYkSR7E9slutxA6x91Q6YUGsSaCKEWdESqFQ4dn4Yo73PI0Z4
 j6OJQKRqw3HVlHchYQ5vbpesIwNMzL2eMQy4Y1DY1sM4ugnuk1HU0pXVABYgrVh6pfw
 lJdTa1gMbm3vamMGIHYQZrH8LXxx1z2XoPs+pUQzFN6jYHUEcoxdHDZ5+UOqxMErSho
 yoZrkEE3oVRxW9R+AZquky7Y8/lfHDPiOgHsb+P7s00IJ4nV5vOSDnyeGwK/6NcK+l8
 8j/BZu5m9z3Lk/J+wTmF7TUjXn/BNn8iJaDCRbcK/VUpVUa31dPi4eE+4t9XTNq31/Y
 Wf5FsYAyXA==
Date: Tue, 9 Nov 2021 13:49:14 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Yanmaani <yanmaani@cock.li>
Message-ID: <Mo3jgtg--3-2@tutanota.de>
In-Reply-To: <3d686c3a100338514c3ebcc264ec24f2@cock.li>
References: <MmT9umZ--3-2@tutanota.de>
 <20211020192054.GA117785@jauntyelephant.191.37.198.vultr.com>
 <CAHiDt8A30DZtvsPnDDdtyVpho-NKKQhbP_4g8d0MGATawWvg_w@mail.gmail.com>
 <MnjA6g0--3-2@tutanota.de> <3d686c3a100338514c3ebcc264ec24f2@cock.li>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_652308_553003584.1636462154249"
X-Mailman-Approved-At: Tue, 09 Nov 2021 12:56:09 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 12:49:18 -0000

------=_Part_652308_553003584.1636462154249
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Yanmaani,

> 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.

I am aware of this problem however looking for solutions or workarounds. Is it possible to have one library for things related to consensus which is used by all full node implementations? There are lot of other things in any full node implementation apart from consensus related code.

> 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.

Sorry neither I agree with this nor its "all about money" for me. I am assuming there are few others as well with similar thoughts.

I had shared few reasons why someone might contribute to Bitcoin Core: https://bitcoin.stackexchange.com/a/108017/

> 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.

Sorry I don't agree with this approach. Its not about 'box-ticking' textbook exercise but to make the attacks more difficult by any governments or people with malicious intent. Few years back when I was in college and Tor wasn't as famous as it is now, we used normal socks proxies for pentesting. My mentor Godzilla had suggested us to use IP of different countries not because it is some textbook exercise but it helps when someone tries to trace your requests. Similarly, if we have people from different countries in different full node implementations as maintainers it will be difficult for people to try crazy things.

> See above. Bitcoin Knots isn't really independent.

I understand there are other implementations like btcd, bcoin, gocoin, libbitcoin, bitcore etc. and Knots is a derivative of Core. However there are lot of differences and it changes your experience as a user while running node and using it for different things. I have mentioned few things in the medium post shared in last email.

> You could also look into a system like Monero's CCS.

Yes I like it and suggested once in bitcoin.org repository even though it can be done by anyone as there is no official website for Bitcoin: https://github.com/bitcoin-dot-org/Bitcoin.org/issues/3545


-- 
Prayank

A3B1 E430 2298 178F



Nov 5, 2021, 20:15 by yanmaani@cock.li:

> 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.
>


------=_Part_652308_553003584.1636462154249
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>Hi Yanmaani,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&g=
t; Unfortunately, this isn't really possible. If they did that, you could g=
et consensus splits. This is why all the other stuff is so important - if B=
itcoin is subverted via soft-fork, you *can't* just run your own fork.<br><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">I am aware of this probl=
em however looking for solutions or workarounds. Is it possible to have one=
 library for things related to consensus which is used by all full node imp=
lementations? There are lot of other things in any full node implementation=
 apart from consensus related code.<br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">&gt; This is all about the money - it's easy to have people=
 be independent when their source of money is independent. But nobody's cra=
zy 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 wealt=
hy enough not to have to care.<br></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Sorry neither I agree with this nor its "all about money" for me=
. I am assuming there are few others as well with similar thoughts.<br></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">I had shared few reasons wh=
y someone might contribute to Bitcoin Core: https://bitcoin.stackexchange.c=
om/a/108017/<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; Is=
n't Bitcoin already plenty distributed? Funding people in under-represented=
 countries seems to me like a textbook exercise in 'box-ticking, but moreov=
er, I'd frankly rather have reasonably well-off guys from Western Europe/Am=
erica 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.<br></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Sorry I don't agree with this approach. Its not about 'bo=
x-ticking' textbook exercise but to make the attacks more difficult by any =
governments or people with malicious intent. Few years back when I was in c=
ollege and Tor wasn't as famous as it is now, we used normal socks proxies =
for pentesting. My mentor Godzilla had suggested us to use IP of different =
countries not because it is some textbook exercise but it helps when someon=
e tries to trace your requests. Similarly, if we have people from different=
 countries in different full node implementations as maintainers it will be=
 difficult for people to try crazy things.<br></div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">&gt; See above. Bitcoin Knots isn't really independe=
nt.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">I understand the=
re are other implementations like btcd, bcoin, gocoin, libbitcoin, bitcore =
etc. and Knots is a derivative of Core. However there are lot of difference=
s and it changes your experience as a user while running node and using it =
for different things. I have mentioned few things in the medium post shared=
 in last email.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div=
>&gt; You could also look into a system like Monero's CCS.<br></div><div><b=
r></div><div>Yes I like it and suggested once in bitcoin.org repository eve=
n though it can be done by anyone as there is no official website for Bitco=
in: https://github.com/bitcoin-dot-org/Bitcoin.org/issues/3545<br></div></d=
iv><div><br></div><div dir=3D"auto"><br></div><div>-- <br></div><div>Prayan=
k<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></div><d=
iv><br></div><div><br></div><div><br></div><div>Nov 5, 2021, 20:15 by yanma=
ani@cock.li:<br></div><blockquote class=3D"tutanota_quote" style=3D"border-=
left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>On 202=
1-11-05 08:17, Prayank via bitcoin-dev wrote:<br></div><blockquote><div>Wha=
t followed it (whitepaper being shared on different websites) was<br></div>=
<div>true decentralization and we need something similar in other aspects<b=
r></div><div>of full node implementations. Few things that can improve<br><=
/div><div>decentralization:<br></div><div><br></div><div>1.More people usin=
g alternative full node implementations. Right now<br></div><div>98% of nod=
es use Bitcoin Core.<br></div></blockquote><div><br></div><div>Unfortunatel=
y, this isn't really possible. If they did that, you could get consensus sp=
lits. This is why all the other stuff is so important - if Bitcoin is subve=
rted via soft-fork, you *can't* just run your own fork.<br></div><div><br><=
/div><div>Theoretically, I suppose you could run two implementations and do=
 something if they differ, but what?<br></div><div>1. Bitcoin Core and &lt;=
AltImpl&gt; both say block is valid -&gt; valid<br></div><div>2. Bitcoin Co=
re and &lt;AltImpl&gt; both say block is invalid -&gt; invalid<br></div><di=
v>3. Bitcoin Core says valid, &lt;AltImpl&gt; says invalid -&gt; valid (or =
get forked off)<br></div><div>4. Bitcoin Core says invalid, &lt;AltImpl&gt;=
 says valid -&gt; invalid (or hardfork)<br></div><blockquote><div>2.More pe=
ople like Luke Dashjr and Amir Taaki who do not simp for<br></div><div>anyo=
ne. Being a contributor or maintainer in Bitcoin full node<br></div><div>im=
plementation is different from other open source projects. It was<br></div>=
<div>never going to be easy and it will get difficult with time,<br></div><=
/blockquote><div><br></div><div>This is all about the money - it's easy to =
have people be independent when their source of money is independent. But n=
obody's crazy enough to bite the hand that feeds them, and you couldn't rea=
lly build a system on that basis. Our best hope is gentle hands, or contrib=
utors wealthy enough not to have to care.<br></div><div><br></div><div>(Wha=
tever happened to Amir Taaki, by the way?)<br></div><blockquote><div>3.More=
 people from different countries getting involved in important<br></div><di=
v>roles.<br></div></blockquote><div><br></div><div>Isn't Bitcoin already pl=
enty 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 fin=
ancial 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 W=
est Uzbekistan.<br></div><div><br></div><div>(Maybe they need a union?)<br>=
</div><blockquote>4.Few anons.<br></blockquote><div><br></div><div>Gonna gu=
ess you mean "a few anons," not fewer anons.<br></div><div><br></div><div>A=
gain, problem is money. These days, nobody threatens anyone with anything s=
ubstantive, like murder - the threats all involve cutting off some funding.=
 So having anonymous people being funded by non-robust sources doesn't real=
ly buy you that much, because the weakest link will pretty much never be th=
e de-jure, legal freedom of an individual.<br></div><div><br></div><div>Hav=
ing a system that allows people to fund anonymous people better would be in=
teresting, but it has some challenges with trust and so on.<br></div><block=
quote><div>5.Individuals and organizations who fund different Bitcoin proje=
cts<br></div><div>should consider contributing in alternative. full node im=
plementations<br></div><div>as well. Maybe start with Bitcoin Knots.<br></d=
iv></blockquote><div><br></div><div>See above. Bitcoin Knots isn't really i=
ndependent. btcd in Go is, so I guess they could try that. But at the end o=
f the day, it wouldn't help - btcd has to be bug-for-bug compatible with Co=
re, and it couldn't really be any other way.<br></div><div><br></div><div>F=
or my $0.05, what's needed is more "hard money" - if people could make dona=
tions into a fund, with the fund then paying out to developers, and that fu=
nd be controlled in a civilized and non-centralized way (that's the hard pa=
rt!), this would somewhat insulate developers from people threatening to st=
op their contributions to The Fund, at the price of having developers being=
 able to be coerced by The Fund.<br></div><div><br></div><div>You could als=
o 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 s=
till has to enter the system somehow. Since Bitcoin is a public good, you c=
an't really capture its value, and this means individuals who can (e.g. by =
malicious activity) will always have the leg up.<br></div></blockquote><div=
 dir=3D"auto"><br></div>  </body>
</html>

------=_Part_652308_553003584.1636462154249--