Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4E88AC002D for ; 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 ; 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 ; 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 ; Wed, 8 Jun 2022 04:05:49 +0000 (UTC) Received: by mail-pg1-x52e.google.com with SMTP id 129so17794742pgc.2 for ; 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: In-Reply-To: From: Billy Tetrud Date: Tue, 7 Jun 2022 23:05:33 -0500 Message-ID: To: Luke Kenneth Casson Leighton , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > (apologies i am subscribed digest) > > On Sun, Jun 5, 2022 at 1:00 PM > wrote: > > > Date: Sun, 05 Jun 2022 04:18:04 +0000 > > From: alicexbt > > To: Bitcoin Protocol Discussion > > > > Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable > > Message-ID: > > > 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
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't quite see what the similarity=C2=A0is between Trust= Metric and bitcoin tho. How would=C2=A0you propose "building it into&= quot; bitcoin?=C2=A0

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 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>
I'm curious to know specifically how the metric works and how= its resistant to adversaries, specifically how its sybil resistant. In par= ticular I'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

On Su= n, 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
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<bitcoin-dev@lists.linuxfoundation= .org>
> Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
> Message-ID:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<zyE-uR_2M7vAE8jXf3wthIGQj_-dz9FoL= 50ERTmCb-MCv4zyMgoHAdSff539SPtROJpJdgrfBspM3IZJrNQ9V4kpDnyMB9X6mlWf0eSk1Rk= =3D@= protonmail.com>
> Hi Jorge,
>
>
> Misinformation is false or inaccurate information, especially that whi= ch 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.=C2=A0 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
=C2=A0persistence and tenacity. you serve an extremely useful purpose
=C2=A0of 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"<= br> 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/mail= man/listinfo/bitcoin-dev
--000000000000f9d06005e0e7d11a--