path: root/a1/4361ceb192ad13938857d3f6cc44aefdc9e410

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4E88AC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Jun 2022 04:05:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 394C4409ED
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Jun 2022 04:05:50 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7G6fsv6r6Vnd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Jun 2022 04:05:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com
 [IPv6:2607:f8b0:4864:20::52e])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3036A40194
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  8 Jun 2022 04:05:49 +0000 (UTC)
Received: by mail-pg1-x52e.google.com with SMTP id 129so17794742pgc.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 07 Jun 2022 21:05:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=xFZK5bTKUDRXDK7BPZfGwSDSMdR5GY7Cx2I8vEfv+s8=;
 b=QOXbi7A7vnKcVn7uzbb1C0nxcxwwy9OLgd8+2aj9dk2LMAPMI4k4lE5hkmmcu6wAZI
 lFrs3s4xUjGv1MS0G48Gns9sOeYoT5RUht+6IXh6kBKAzTqc3/cbuGLY1QQds6nPnBa3
 cbGVhAKQcXEMZZbPcoij4PZ5XYYgDexsgtTBKV8f9qfLQNyl/QrcfNUAtmAA0uV1Ptd9
 /G8gCkodYwVOxjxFILhFGRoofAaxPD0d2Lb71KFb/3RF8MVhAbTX40ll+yCBOJI09eyN
 1K8V5+TUoX9SKBN4BE1wkZzwSefQ+ZQsmjWi3r/wH9wQd96Jol2IXtmR+EkK7ar7F7/T
 R3og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=xFZK5bTKUDRXDK7BPZfGwSDSMdR5GY7Cx2I8vEfv+s8=;
 b=4A0a4X4d2bTYDBwaniyCT7d2knHYwT3Haua7Y5PlcPa0zY2Mu0o92K81Zrmkr7R2rY
 vmpFDPXxqtYww8jMCHgU0/wSAcurFwSTQE8bp+3vSXFpu9YdIFTYPkD0A2QdoF8m7xQv
 yipX00AaBchcfkDwwBcJRPKpI4adFddyAI1aHgRbv6LA1dukd7K+LFXtJSkA6MQyOQni
 F8SQrklhPewNSkKGR8j7fVMp/ALVAmeBM2LQgGp1Nmeh1rcI+O/L8PkAK0Vb9Ne2l9BO
 /Wbsz8tqbhi6OoXKO7puaGgaziBZxBY1xtx2ZFOyOTly76BcsAU4AgjxF1bE4TO9OGXZ
 QATg==
X-Gm-Message-State: AOAM532ZJsCbCnWzjDo927WVFT0WHJ43c9r2+Vojrg8sINpbIjuFp4uO
 j+/D4Otru65PEBrAqHj1lZOlUWJHYnFbongwQAxuzbfr7Qw=
X-Google-Smtp-Source: ABdhPJyCzwkid+sM+M/FDIkbiWqfF7ulPMSy34jQbHLxfXXvm2IVkFJRoYM8EYoYJXtlwUrfITe2RfZVFe2RcoSX1eA=
X-Received: by 2002:a62:820a:0:b0:51b:d1f9:b45f with SMTP id
 w10-20020a62820a000000b0051bd1f9b45fmr28921021pfd.63.1654661148428; Tue, 07
 Jun 2022 21:05:48 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.7.1654430403.1388.bitcoin-dev@lists.linuxfoundation.org>
 <CAPweEDwTSDhRav6Uw2iYTKJDZH60D8eoQYSc-VejUXjrTai60g@mail.gmail.com>
In-Reply-To: <CAPweEDwTSDhRav6Uw2iYTKJDZH60D8eoQYSc-VejUXjrTai60g@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 7 Jun 2022 23:05:33 -0500
Message-ID: <CAGpPWDZjAgDJVYFwm+Le3bRTW3U=HD5uE-MzC+nOKnonXL3D+Q@mail.gmail.com>
To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f9d06005e0e7d11a"
X-Mailman-Approved-At: Wed, 08 Jun 2022 07:38:08 +0000
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4
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: Wed, 08 Jun 2022 04:05:50 -0000

--000000000000f9d06005e0e7d11a
Content-Type: text/plain; charset="UTF-8"

That sounds like an interesting mechanism to help measure consensus - and a
good way to do that would help bitcoin significantly I think. I don't quite
see what the similarity is between Trust Metric and bitcoin tho. How
would you propose "building it into" bitcoin?

From my limited searching, it looks like trust metric is basically a graph
of who trusts who, allowing you to quantify who's trusted among a
particular set or subset of people. Is that right? I would think such a
thing can be done completely separately from bitcoin, but used to answer
questions about bitcoin.

I'm curious to know specifically how the metric works and how its resistant
to adversaries, specifically how its sybil resistant. In particular I'm
curious what weaknesses it has that could be gamed. It seems sybil
resistance might be there for a while, but I can imagine that it might be
possible for a colluding set of users to farm aliases with higher and
higher reputation until they could take over the network. In bitcoin, there
are good ways of bolstering such sybil resistance, eg by charging fees for
identities in some way, or by requiring proof of funds.

On Sun, Jun 5, 2022 at 8:19 AM Luke Kenneth Casson Leighton via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:

> (apologies i am subscribed digest)
>
> On Sun, Jun 5, 2022 at 1:00 PM
> <bitcoin-dev-request@lists.linuxfoundation.org> wrote:
>
> > Date: Sun, 05 Jun 2022 04:18:04 +0000
> > From: alicexbt <alicexbt@protonmail.com>
> > To: Bitcoin Protocol Discussion
> >         <bitcoin-dev@lists.linuxfoundation.org>
> > Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
> > Message-ID:
> >
>  <zyE-uR_2M7vAE8jXf3wthIGQj_-dz9FoL50ERTmCb-MCv4zyMgoHAdSff539SPtROJpJdgrfBspM3IZJrNQ9V4kpDnyMB9X6mlWf0eSk1Rk=@
> protonmail.com>
> > Hi Jorge,
> >
> >
> > Misinformation is false or inaccurate information, especially that which
> is deliberately intended to deceive.
> > A combination of 'misleading' and 'information'.
>
> it's a classic technique that was refined by psy-ops well over
> 60 years ago.  it should come as no surprise at all that it is
> being systematically deployed to undermine bitcoin.
> (welcome to the party, all psy-ops teams reading this: i admire your
>  persistence and tenacity. you serve an extremely useful purpose
>  of detecting flaws in the resilience of bitcoin and its development.)
>
> a potential solution is Trust Metrics. the most successful open
> source experiment in that regard was advogato.org by Raph Levien.
>
> i expanded it greatly so that any user could specify the "seeds"
> whom *they* trusted, rather than being forced to utilise the fixed
> hard-coded user ids in the advogato.org source code (this difference
> is extremely important for de-centralisation)
>
> public declarations of trust, and their propagation through standard
> Maximum-Flow Graph analysis, helps greatly to filter out the crap.
> advogato deflected heavy systematic and sustained spam attacks
> thanks to the simple expedient of users declaring publicly whom
> they trusted.
>
> a more advanced version of the max-flow concept came up a few
> years later called keynote (RFC2704)
>
> the similarity between trust metric evaluation and the bitcoin protocol
> is so remarkable that i am, frankly, slightly stunned that it was not
> added right from the start.
>
> it is ironic that the lack of integrated trust metric evaluation built-in
> to the bitcoin protocol is now hampering developers from being able
> to evaluate whom to trust when it comes to protocol development.
>
> l.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000f9d06005e0e7d11a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">That sounds like an interesting mechanism to help measure =
consensus - and a good way to do that would help bitcoin significantly=C2=
=A0I think. I don&#39;t quite see what the similarity=C2=A0is between Trust=
 Metric and bitcoin tho. How would=C2=A0you propose &quot;building it into&=
quot; bitcoin?=C2=A0<div><br></div><div>From my limited searching, it looks=
 like trust metric is basically a graph of who trusts who, allowing you to =
quantify who&#39;s trusted among a particular set or subset of people. Is t=
hat right? I would think such a thing can be done completely separately fro=
m bitcoin, but used to answer questions=C2=A0about bitcoin.</div><div><br><=
/div><div>I&#39;m curious to know specifically how the metric works and how=
 its resistant to adversaries, specifically how its sybil resistant. In par=
ticular I&#39;m curious what weaknesses it has that could be gamed. It seem=
s sybil resistance might be there for a while, but I can imagine that it mi=
ght be possible for a colluding set of users to farm aliases with higher an=
d higher reputation until they could take over the network. In bitcoin, the=
re are good ways of bolstering such sybil resistance, eg by charging fees f=
or identities in some way, or by requiring proof of funds.=C2=A0</div></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Su=
n, Jun 5, 2022 at 8:19 AM Luke Kenneth Casson Leighton via bitcoin-dev &lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">(apologies i am subscribed digest)<br>
<br>
On Sun, Jun 5, 2022 at 1:00 PM<br>
&lt;<a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev-request@lists.linuxfoundation.org</a>&gt; wrote:<br=
>
<br>
&gt; Date: Sun, 05 Jun 2022 04:18:04 +0000<br>
&gt; From: alicexbt &lt;<a href=3D"mailto:alicexbt@protonmail.com" target=
=3D"_blank">alicexbt@protonmail.com</a>&gt;<br>
&gt; To: Bitcoin Protocol Discussion<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt;<br>
&gt; Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable<br>
&gt; Message-ID:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;zyE-uR_2M7vAE8jXf3wthIGQj_-dz9FoL=
50ERTmCb-MCv4zyMgoHAdSff539SPtROJpJdgrfBspM3IZJrNQ9V4kpDnyMB9X6mlWf0eSk1Rk=
=3D@<a href=3D"http://protonmail.com" rel=3D"noreferrer" target=3D"_blank">=
protonmail.com</a>&gt;<br>
&gt; Hi Jorge,<br>
&gt;<br>
&gt;<br>
&gt; Misinformation is false or inaccurate information, especially that whi=
ch is deliberately intended to deceive.<br>
&gt; A combination of &#39;misleading&#39; and &#39;information&#39;.<br>
<br>
it&#39;s a classic technique that was refined by psy-ops well over<br>
60 years ago.=C2=A0 it should come as no surprise at all that it is<br>
being systematically deployed to undermine bitcoin.<br>
(welcome to the party, all psy-ops teams reading this: i admire your<br>
=C2=A0persistence and tenacity. you serve an extremely useful purpose<br>
=C2=A0of detecting flaws in the resilience of bitcoin and its development.)=
<br>
<br>
a potential solution is Trust Metrics. the most successful open<br>
source experiment in that regard was <a href=3D"http://advogato.org" rel=3D=
"noreferrer" target=3D"_blank">advogato.org</a> by Raph Levien.<br>
<br>
i expanded it greatly so that any user could specify the &quot;seeds&quot;<=
br>
whom *they* trusted, rather than being forced to utilise the fixed<br>
hard-coded user ids in the <a href=3D"http://advogato.org" rel=3D"noreferre=
r" target=3D"_blank">advogato.org</a> source code (this difference<br>
is extremely important for de-centralisation)<br>
<br>
public declarations of trust, and their propagation through standard<br>
Maximum-Flow Graph analysis, helps greatly to filter out the crap.<br>
advogato deflected heavy systematic and sustained spam attacks<br>
thanks to the simple expedient of users declaring publicly whom<br>
they trusted.<br>
<br>
a more advanced version of the max-flow concept came up a few<br>
years later called keynote (RFC2704)<br>
<br>
the similarity between trust metric evaluation and the bitcoin protocol<br>
is so remarkable that i am, frankly, slightly stunned that it was not<br>
added right from the start.<br>
<br>
it is ironic that the lack of integrated trust metric evaluation built-in<b=
r>
to the bitcoin protocol is now hampering developers from being able<br>
to evaluate whom to trust when it comes to protocol development.<br>
<br>
l.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000f9d06005e0e7d11a--