path: root/53/61a61422bb59ee6397592a9ad4bfdad49e09ab

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 57257C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jun 2022 04:02:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3C14C60FE1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jun 2022 04:02:56 +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: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id S2-2A4yDPGgG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jun 2022 04:02:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com
 [IPv6:2607:f8b0:4864:20::435])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 2668160FE0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jun 2022 04:02:54 +0000 (UTC)
Received: by mail-pf1-x435.google.com with SMTP id u2so10322991pfc.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jun 2022 21:02:54 -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
 :cc; bh=GPYWf2KccV8o3ZsdqIA/iH801nJiAuN/bIDeHIlnc6s=;
 b=acYbGco/OjJB2B+XLhKIZkamscXi6UV6FzRibnzYgzz3Nm+M6v4Q1GBG5IS+HTf/d+
 e1yogeQaWH3/qIpoYoOpytui2PkFNeG2RS3qWEXSnzS5SxWV1LnJvhGIoupD9l1wiIo2
 3YCsdD9y000g0Ym9D4HnHgMhA9K0jnpJqxMKW7eCtbKXNuGGpvcdRj1b2oWCYJCzdp1U
 KQkjP76CLJzde6MvpvNMW1pWIAYp0kHjkKoXxWm9yQX8g1uJyKEtUsYWgWRnAd+wB3e7
 erBSAXrg5aI+rr139BiF/10ji50RyaKYWX0HjfGrMpQ48rW0XhBn5escqJ1YpmoNBaat
 ActQ==
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:cc;
 bh=GPYWf2KccV8o3ZsdqIA/iH801nJiAuN/bIDeHIlnc6s=;
 b=wsav+HZRpgkkG8qSAc/KuuYVeqaIzpCg3gTGmbRxnkYJHmnyZHZW9l2Kd/0NQvM9j6
 03OkMcrTW9W3CLKIYWMdxgjCMG65hXP0P0OVPUeRqoeItWInver9bwc72b1qNwcdMhxx
 V4D4fIP+wDp/gW1I+iG/Uh/Q0ekwX+1Oi1JwnYLzls84m2xKVad1KC7qNK0JY3qA2MpG
 n6Kut0sjbtg0COelDmaUXjg0VEjRbpgbriDBnzegK7pidam/4A7jwyTT3MFQifi1fpjI
 ZzP4hv3uZd4CH/TtcqvPRZL6JLT8JQNU3a3E6ygLQBqIxLhSk4hXakOH2IsQmftqZz/j
 LdFg==
X-Gm-Message-State: AOAM533As9v0R/0MolK90bXqJKwJdd78zmc72YoC1PUVjaNlGkSkxcnN
 lH/knWCv3mBvb2IscWWPnCd1YcjlP2Pfmk/CiFQBN/f3
X-Google-Smtp-Source: ABdhPJzEDHON+KSvhcClBWIvdCh29KZ1JBeHqDkPFcjkiqiw+DNlZCqlgoDUQxQ3cmwehboTgp0Y9aIOJpX7kiLO2J8=
X-Received: by 2002:a63:e34b:0:b0:405:111a:a295 with SMTP id
 o11-20020a63e34b000000b00405111aa295mr7338561pgj.48.1655265773408; Tue, 14
 Jun 2022 21:02:53 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.7.1654430403.1388.bitcoin-dev@lists.linuxfoundation.org>
 <CAPweEDwTSDhRav6Uw2iYTKJDZH60D8eoQYSc-VejUXjrTai60g@mail.gmail.com>
 <CAGpPWDZjAgDJVYFwm+Le3bRTW3U=HD5uE-MzC+nOKnonXL3D+Q@mail.gmail.com>
 <06BC155F-2EB3-46E0-8A01-2BA5535DA015@gmail.com>
In-Reply-To: <06BC155F-2EB3-46E0-8A01-2BA5535DA015@gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 14 Jun 2022 23:02:38 -0500
Message-ID: <CAGpPWDbigj9yxcxqC37fyB4jkCDo9eZejzwYrgEE5UtbvJuU9Q@mail.gmail.com>
To: lkcl <luke.leighton@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000006ed81905e17498fa"
X-Mailman-Approved-At: Wed, 15 Jun 2022 08:06:32 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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, 15 Jun 2022 04:02:56 -0000

--0000000000006ed81905e17498fa
Content-Type: text/plain; charset="UTF-8"

>   two aspects to consensus

Well, consensus isn't just one thing with two aspects. There are many
things one might ask for consensus about, and many groups you might ask for
it from. There's miner consensus about transaction ordering, miner
consensus about soft fork signaling, developer consensus about the
desirability and readiness of a particular change (to the code / miner
consensus rules), there's consensus about these changes from various sub
communities within and related to bitcoin, and the broader consensus of the
whole bitcoin community. And probably many others. Most of these types of
consensus involve trust to various degrees. I think that's what  you mean
by there being more than one aspect of consensus, yes?

> the live advogato system .. remained 100% spam-free of off-topic articles
throughout its entire life.

Very impressive!

>  if those pseudo-identities are not linked to anyone .. they .. remain
isolated.

I see. Because anyone measuring consensus is only measuring it with respect
to their own trust network, anyone not transitively trusted by the person
measuring consensus is simply ignored.

> i made some modifications that required a *minimum number* of incoming
Trust Declarations before Flow was permitted to cross outwards.

I wouldn't think this is sufficient, since an attacker could put in effort
to achieve whatever minimum you come up with. For example, an attacker
could pose as someone with a particular popular point of view, put in
effort to produce actual helpful content that's interesting to their target
audience, and therefore get plenty of trust from people, but then they
could mark themselves as trusting of various sock puppets. The only way I
can think of solving that problem is for people in the community to be able
to investigate and somehow recognize something's weird about who that
outwardly helpful person trusts and detrust them because of it. Are there
other mechanisms to deal with this kind of thing, maybe as part of Keynote?

> hilariously, such isolated networks, being easy to identify, and also
entirely public, allow the existence of attackers to come to public
awareness.

I suppose this is related to my thought above.

> negative Certs were discussed but never implemented because they could do
more harm than good.

How so?

> the other weakess is: *it takes discipline to maintain*. you cannot
incentivise people to do this kind of thing without risking invitation of
bribery.

What do you mean by "discipline"? Discipline amongst who? The whole
network? The operator of something like Avogato? An individual who wants to
measure consensus?

> a zero-value transaction gets the entry into the chain.
> who on earth wants to pay BTC to make some "stupid" declaration of whom
they "trust"?

I don't see a reason to commit any of this data to the blockchain. Why not
just have a network where nodes collect and/or query for the data they
need? Such a thing would be far less expensive (could potentially even be
free). Since declarations of trust are always signed, they're all
verifiable. There's no double spending problem here because any "double
spend" (ie two signed conflicting declarations) only serves to dilute or
nullify that person's contribution to consensus (which is basically only
bad for the "double spender"). If one wanted to connect a signed
declaration to a block, they could simply include the block hash in the
signature, which would verify that the declaration was signed after that
block happened, and it could mean that the declaration is valid from that
block until a new declaration is signed with a newer block's hash. If one
wanted to but some financial barriers in place to limit sybil attacks, you
could require a zero-value transaction that records the public key (or a
hash of the public key) like you mentioned. However, rather than charging a
fee to register a public key, you could instead simply require that the
public key be associated with UTXOs. This works best when it makes sense to
weight any declaration by the value contained in the associated UTXOs, like
I suggest doing with coin-weighted polling here
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020146.html>
.


On Thu, Jun 9, 2022 at 6:34 AM lkcl <luke.leighton@gmail.com> wrote:

> ------------------------------
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Wed, Jun 8, 2022 at 5:05 AM Billy Tetrud <billy.tetrud@gmail.com>
> wrote:
> >
> > That sounds like an interesting mechanism to help measure consensus -
>
> it is related to consensus but is not consensus as bitcoin sees it.
>
> there are two aspects to consensus:
>
> 1) the public declarations of "trust" (or other declarations)
> 2) the programmatic evaluation of the same resulting in automated
> decisions.
>
> conflating these two or assuming them to be inextricably intertwined
> results in severe limitations of the possible applications of bitcoin.
>
> > 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.
>
> the mining is a "public declaration" where the "trust" may be
> computationally verified. it is... slightly different but similar enough to
> be able to fit
>
> >How would you propose "building it into" bitcoin?
>
> without requiring going through a BEP for that, use of the comment field
> would suffice. a zero-value transaction gets the entry into the chain.
>
> the comments can include a URL or a hash of a URL (if the conversation is
> supposed to be private), and must include a hash of an identity which can
> be verified (GPG Key, a BTC Wallet known to be linked to a user). yes, the
> end-result here is that the blockchain subsumes the role of a web-of-trust
> as part of the Operational Requirements [you can't have trust unless the
> pseudonym is provably-linkable to a user in a verifiable way. Monero
> protocol springs to mind here, as does Debian's GPG Key-signing protocols]
>
>
> from there it becomes a matter of writing programs that parse the chain,
> extracting the comments, parse them, and perform a "trust evaluation".
>
>
> note that these programs *do not* rely on any centralised party. any user
> may decide the "top-level seeds" (whom they implicitly trust 100%) which
> may only be themselves.
>
> > 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?
>
> using Transitive Relationships, yes. A trusts B, B trusts C, therefore it
> is reasonable for A to trust C (to some extent). If A trusts B *and* D, and
> both B *and* D trust C, thenA has a much higher level of confidence that
> they can trust C than in the first scenario.
>
> the use of the Ford-Fulkersson Max Flow Algorithm allows for an unordered
> graph of such "Trust Declarations" to be turned into a Directed Acyclic
> Graph, with weighting in order to deliberately "peter out" the possibility
> of long-distance Transitive Chains from being "faulty".
>
> [btw in pymmetry i did *not* use depth-first, as in Ford-Fulkersson, i
> used breadth-first. the cost of depth-first will be insane in a network as
> large as BTC]
>
> What is nice about the Max Flow Algorithm is that should there be a large
> genuine cluster of Declarations into a node that is a large number of
> degrees away from the "seeds", that node can still potentially receive a
> positive evaluation. Likewise, Nodes that have a limited number of
> Declarations get quickly filtered out.
>
> > I would think such a thing can be done completely separately from
> bitcoin, but used to answer questions about bitcoin.
>
> indeed. and many other uses.
>
> > I'm curious to know specifically how the metric works and how its
> resistant to adversaries, specifically how its sybil resistant.
>
> had to look that up
> https://en.m.wikipedia.org/wiki/Sybil_attack
>
> ok, so if those pseudo-identities are not linked to anyone that is linked
> to the "seeds", they can create as many Trust Declarations in between
> themselves as they damn well like: they get f***-all flow and consequently
> remain isolated.
>
> this was exactly what happened on the live advogato system and it remained
> 100% spam-free of off-topic articles throughout its entire life.
>
> > In particular I'm curious what weaknesses it has that could be gamed.
>
> rright. the problem comes if someone who *does* have Transitive Flow of
> Trust is fooled by the puppets into making a Declaration, "I trust one of
> these puppets because what they said looked reasonable to me at the time".
>
> and this was a weakness of the *original* advogato algorithm, because the
> application of the Ford Fulkersson algorithm was naive "flow in from edge
> equals flow out".
>
> i made some modifications that required a *minimum number* of incoming
> Trust Declarations before Flow was permitted to cross outwards.
>
> this led me to investigate Keynote (RFC2704) because i realised that there
> may be circumstances for which much more sophisticated Gating would be
> needed, and Keynote is perfect for that.
>
> (you could in theory use bitcoin scripts, but they're not really up to the
> task, as designed)
>
> revocation is needed, here, which will be interesting on top of a
> blockchain, for when people realise they've been duped.
>
>
> > 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.
>
> they can try but as i said above, if no Transitive Relationship exists to
> them, they can basically do whatever they like.
>
> hilariously, such isolated networks, being easy to identify, and also
> entirely public, allow the existence of attackers to come to public
> awareness.
>
> the only reason why such attackers can f*** with Facebook etc. is
> precisely because the attacks are behind the secretive closed doors of
> proprietary systems.
>
> if the entire database is public they have nowhere to hide.
>
>
> the other weakness of the original system was that there was neither
> expiry, revocation, nor "negative" Certs. people abandoned their account,
> someone misbehaved, and the Certs flowing to the misbehaving person
> remained.
>
> negative Certs were discussed but never implemented because they could do
> more harm than good.
>
> i wrote over a hundred articles on advogato, and Raph received MULTIPLE
> DEMANDS from really quite prominent Open Source Developers who had
> absolutely no business at all demanding Censorship and the removal of those
> articles. Raph pointed them at the *150* "Master" Level Certs i had
> received (which was a lot), and informed them that only when all 150 of
> those Certs were removed by each of those individuals, many of whom were
> also respected Community Members, would my "Master" Level drop and their
> demands that i no longer be permitted to post Articles would automatically
> and inherently be met.
>
> there's nothing that can be done about defamation or social abuse, in
> other words. just because technology exists doesn't make people become more
> humane.
>
>
> the other weakess is: *it takes discipline to maintain*. you cannot
> incentivise people to do this kind of thing without risking invitation of
> bribery. there were enough people begging "please Cert me" on underground
> forums as it was.
>
>
> > 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.
>
> through requiring that the Trust Declarations be actual bitcoin
> transactions, that helps as well.
>
> the only problem then becomes a practical social one: who on earth wants
> to pay BTC to make some "stupid" declaration of whom they "trust"? and,
> more than that: are the *developers themselves* being actually paid enough
> in BTC such that they can *afford* to make a Declaration?
>
> or, sorry, crictical, critical correction: separating the Declaration from
> the payment threshold is important! anyone should be able to enter a
> zero-value Transaction with a Declaration of Trust, but whether their
> Declaration is *included in the Graph Processing* would be (a la Keynote)
> down to the independent post-processing.
>
> for example, if a Developer has five hundred incoming Declarations of
> Trust and they are only one degree away from the "seeds", it should be
> blindingly obvious that charging them for making Declarations is
> unnecessary. this "rule" would be expressed a la Keynote
>
> these things can be solved in other words.
>
> l.
>
>

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

<div dir=3D"ltr">&gt;=C2=A0

=C2=A0two aspects to consensus<div><br></div><div>Well, consensus isn&#39;t=
 just one thing with two aspects. There are many things one might ask for c=
onsensus about, and many groups=C2=A0you might ask for it from. There&#39;s=
 miner consensus about transaction ordering, miner consensus about soft for=
k signaling, developer consensus about the desirability and readiness of a =
particular change (to the code / miner consensus rules), there&#39;s consen=
sus about these changes from various sub communities within and related to =
bitcoin, and the broader consensus of the whole bitcoin community. And prob=
ably many others. Most of these types of consensus involve trust to various=
 degrees. I think that&#39;s what=C2=A0 you mean by there being more than o=
ne aspect of consensus, yes?</div><div><br></div><div><div>&gt; the live ad=
vogato system .. remained 100% spam-free of off-topic articles throughout i=
ts entire life.</div><div><br></div><div>Very impressive!</div></div><div><=
br></div><div>&gt;=C2=A0 if those pseudo-identities are not linked to anyon=
e .. they .. remain isolated.</div><div><br></div><div>I see. Because anyon=
e measuring consensus is only measuring it with respect to their own trust =
network, anyone not transitively trusted by the person measuring consensus =
is simply ignored.</div><div><br></div><div>&gt; i made some modifications =
that required a *minimum number* of incoming Trust Declarations before Flow=
 was permitted to cross outwards.</div><div><br></div><div>I wouldn&#39;t t=
hink this is sufficient, since an attacker could put in effort to achieve w=
hatever minimum you come up with. For example, an attacker could pose as so=
meone with a particular popular point of view, put in effort to produce act=
ual helpful content that&#39;s interesting to their target audience, and th=
erefore get plenty of trust from people, but then they could mark themselve=
s as trusting of various sock puppets. The only way I can think of solving =
that problem is for people in the community to be able to investigate and s=
omehow recognize something&#39;s weird about who that outwardly helpful per=
son trusts and detrust them because of it. Are there other mechanisms to de=
al with this kind of thing, maybe as part of Keynote?</div><div><br></div><=
div>&gt; hilariously, such isolated networks, being easy to identify, and a=
lso entirely public, allow the existence of attackers to come to public awa=
reness.</div><div><br></div><div>I suppose this is related to my thought ab=
ove.</div><div><br></div><div>&gt; negative Certs were discussed but never =
implemented because they could do more harm than good.</div><div><br></div>=
<div>How so?=C2=A0</div><div><br></div><div>&gt; the other weakess is: *it =
takes discipline to maintain*. you cannot incentivise people to do this kin=
d of thing without risking invitation of bribery.</div><div><br></div><div>=
What do you mean by &quot;discipline&quot;? Discipline amongst who? The who=
le network? The operator of something like Avogato? An individual who wants=
 to measure consensus?=C2=A0</div><div><br></div><div><div>&gt; a zero-valu=
e transaction gets the entry into the chain.<br></div><div>&gt; who on eart=
h wants to pay BTC to make some &quot;stupid&quot; declaration of whom they=
 &quot;trust&quot;?</div><div><br></div><div>I don&#39;t see a reason to co=
mmit any of this data to the blockchain. Why not just have a network where =
nodes collect and/or query for the data they need? Such a thing would be fa=
r less expensive (could potentially even be free). Since declarations of tr=
ust are always signed, they&#39;re all verifiable. There&#39;s no double sp=
ending problem here because any &quot;double spend&quot; (ie two signed con=
flicting declarations) only serves to dilute or nullify that person&#39;s c=
ontribution to consensus (which is basically only bad for the &quot;double =
spender&quot;). If one wanted to connect a signed declaration to a block, t=
hey could simply include the block hash in the signature, which would verif=
y that the declaration was signed after that block happened, and it could m=
ean that the declaration is valid from that block until a new declaration i=
s signed with a newer block&#39;s hash. If one wanted to but some financial=
 barriers in place to limit sybil attacks, you could require a zero-value t=
ransaction that records the public key (or a hash of the public key) like y=
ou mentioned. However, rather than charging a fee to register a public key,=
 you could instead simply require that the public key be associated with UT=
XOs. This works best when it makes sense to weight any declaration by the v=
alue contained in the associated UTXOs, like I suggest doing with <a href=
=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/0201=
46.html" target=3D"_blank">coin-weighted polling here</a>.</div></div><div>=
<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Thu, Jun 9, 2022 at 6:34 AM lkcl &lt;<a href=3D"mailto:luke.le=
ighton@gmail.com" target=3D"_blank">luke.leighton@gmail.com</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><hr>crowd-funded=
 eco-conscious hardware: <a href=3D"https://www.crowdsupply.com/eoma68" tar=
get=3D"_blank">https://www.crowdsupply.com/eoma68</a><br><br>On Wed, Jun 8,=
 2022 at 5:05 AM Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com"=
 target=3D"_blank">billy.tetrud@gmail.com</a>&gt; wrote:<br>&gt;<br>&gt; Th=
at sounds like an interesting mechanism to help measure consensus - <br><br=
>it is related to consensus but is not consensus as bitcoin sees it.<br><br=
>there are two aspects to consensus:<br><br>1) the public declarations of &=
quot;trust&quot; (or other declarations)<br>2) the programmatic evaluation =
of the same resulting in automated decisions.<br><br>conflating these two o=
r assuming them to be inextricably intertwined results in severe limitation=
s of the possible applications of bitcoin.<br><br>&gt; and a good way to do=
 that would help bitcoin significantly I think. I don&#39;t quite see what =
the similarity is between Trust Metric and bitcoin tho. <br><br>the mining =
is a &quot;public declaration&quot; where the &quot;trust&quot; may be comp=
utationally verified.  it is... slightly different but similar enough to be=
 able to fit<br><br>&gt;How would you propose &quot;building it into&quot; =
bitcoin?<br><br>without requiring going through a BEP for that, use of the =
comment field would suffice.  a zero-value transaction gets the entry into =
the chain.<br><br>the comments can include a URL or a hash of a URL (if the=
 conversation is supposed to be private), and must include a hash of an ide=
ntity which can be verified (GPG Key, a BTC Wallet known to be linked to a =
user).  yes, the end-result here is that the blockchain subsumes the role o=
f a web-of-trust as part of the Operational Requirements [you can&#39;t hav=
e trust unless the pseudonym is provably-linkable to a user in a verifiable=
 way. Monero protocol springs to mind here, as does Debian&#39;s GPG Key-si=
gning protocols]<br><br><br>from there it becomes a matter of writing progr=
ams that parse the chain, extracting the comments, parse them, and perform =
a &quot;trust evaluation&quot;.<br><br><br>note that these programs *do not=
* rely on any centralised party.  any user may decide the &quot;top-level s=
eeds&quot; (whom they implicitly trust 100%) which may only be themselves.<=
br><br>&gt; From my limited searching, it looks like trust metric is basica=
lly a graph of who trusts who, allowing you to quantify who&#39;s trusted a=
mong a particular set or subset of people. Is that right?<br><br>using Tran=
sitive Relationships, yes.  A trusts B, B trusts C, therefore it is reasona=
ble for A to trust C (to some extent).  If A trusts B *and* D, and both B *=
and* D trust C, thenA has a much higher level of confidence that they can t=
rust C than in the first scenario.<br><br>the use of the Ford-Fulkersson Ma=
x Flow Algorithm allows for an unordered graph of such &quot;Trust Declarat=
ions&quot; to be turned into a Directed Acyclic Graph, with weighting in or=
der to deliberately &quot;peter out&quot; the possibility of long-distance =
Transitive Chains from being &quot;faulty&quot;.<br><br>[btw in pymmetry i =
did *not* use depth-first, as in Ford-Fulkersson, i used breadth-first. the=
 cost of depth-first will be insane in a network as large as BTC]<br><br>Wh=
at is nice about the Max Flow Algorithm is that should there be a large gen=
uine cluster of Declarations into a node that is a large number of degrees =
away from the &quot;seeds&quot;, that node can still potentially receive a =
positive evaluation.  Likewise, Nodes that have a limited number of Declara=
tions get quickly filtered out.<br><br>&gt;  I would think such a thing can=
 be done completely separately from bitcoin, but used to answer questions a=
bout bitcoin.<br><br>indeed. and many other uses.<br><br>&gt; I&#39;m curio=
us to know specifically how the metric works and how its resistant to adver=
saries, specifically how its sybil resistant. <br><br>had to look that up<b=
r><a href=3D"https://en.m.wikipedia.org/wiki/Sybil_attack" target=3D"_blank=
">https://en.m.wikipedia.org/wiki/Sybil_attack</a><br><br>ok, so if those p=
seudo-identities are not linked to anyone that is linked to the &quot;seeds=
&quot;, they can create as many Trust Declarations in between themselves as=
 they damn well like: they get f***-all flow and consequently remain isolat=
ed.<br><br>this was exactly what happened on the live advogato system and i=
t remained 100% spam-free of off-topic articles throughout its entire life.=
<br><br>&gt; In particular I&#39;m curious what weaknesses it has that coul=
d be gamed. <br><br>rright.  the problem comes if someone who *does* have T=
ransitive Flow of Trust is fooled by the puppets into making a Declaration,=
 &quot;I trust one of these puppets because what they said looked reasonabl=
e to me at the time&quot;.<br><br>and this was a weakness of the *original*=
 advogato algorithm, because the application of the Ford Fulkersson algorit=
hm was naive &quot;flow in from edge equals flow out&quot;.<br><br>i made s=
ome modifications that required a *minimum number* of incoming Trust Declar=
ations before Flow was permitted to cross outwards.<br><br>this led me to i=
nvestigate Keynote (RFC2704) because i realised that there may be circumsta=
nces for which much more sophisticated Gating would be needed, and Keynote =
is perfect for that.<br><br>(you could in theory use bitcoin scripts, but t=
hey&#39;re not really up to the task, as designed)<br><br>revocation is nee=
ded, here, which will be interesting on top of a blockchain, for when peopl=
e realise they&#39;ve been duped.<br><br><br>&gt; It seems sybil resistance=
 might be there for a while, but I can imagine that it might be possible fo=
r a colluding set of users to farm aliases with higher and higher reputatio=
n until they could take over the network. <br><br>they can try but as i sai=
d above, if no Transitive Relationship exists to them, they can basically d=
o whatever they like.<br><br>hilariously, such isolated networks, being eas=
y to identify, and also entirely public, allow the existence of attackers t=
o come to public awareness.<br><br>the only reason why such attackers can f=
*** with Facebook etc. is precisely because the attacks are behind the secr=
etive closed doors of proprietary systems.<br><br>if the entire database is=
 public they have nowhere to hide.<br><br><br>the other weakness of the ori=
ginal system was that there was neither expiry, revocation, nor &quot;negat=
ive&quot; Certs.  people abandoned their account, someone misbehaved, and t=
he Certs flowing to the misbehaving person remained.<br><br>negative Certs =
were discussed but never implemented because they could do more harm than g=
ood.<br><br>i wrote over a hundred articles on advogato, and Raph received =
MULTIPLE DEMANDS from really quite prominent Open Source Developers who had=
 absolutely no business at all demanding Censorship and the removal of thos=
e articles.  Raph pointed them at the *150* &quot;Master&quot; Level Certs =
i had received (which was a lot), and informed them that only when all 150 =
of those Certs were removed by each of those individuals, many of whom were=
 also respected Community Members, would my &quot;Master&quot; Level drop a=
nd their demands that i no longer be permitted to post Articles would autom=
atically and inherently be met.<br><br>there&#39;s nothing that can be done=
 about defamation or social abuse, in other words.  just because technology=
 exists doesn&#39;t make people become more humane.<br><br><br>the other we=
akess is: *it takes discipline to maintain*.  you cannot incentivise people=
 to do this kind of thing without risking invitation of bribery.  there wer=
e enough people begging &quot;please Cert me&quot; on underground forums as=
 it was.<br><br><br>&gt; In bitcoin, there are good ways of bolstering such=
 sybil resistance, eg by charging fees for identities in some way, or by re=
quiring proof of funds.<br><br>through requiring that the Trust Declaration=
s be actual bitcoin transactions, that helps as well.<br><br>the only probl=
em then becomes a practical social one: who on earth wants to pay BTC to ma=
ke some &quot;stupid&quot; declaration of whom they &quot;trust&quot;? and,=
 more than that: are the *developers themselves* being actually paid enough=
 in BTC such that they can *afford* to make a Declaration?<br><br>or, sorry=
, crictical, critical correction: separating the Declaration from the payme=
nt threshold is important! anyone should be able to enter a zero-value Tran=
saction with a Declaration of Trust, but whether their Declaration is *incl=
uded in the Graph Processing* would be (a la Keynote) down to the independe=
nt post-processing.<br><br>for example, if a Developer has five hundred inc=
oming Declarations of Trust and they are only one degree away from the &quo=
t;seeds&quot;, it should be blindingly obvious that charging them for makin=
g Declarations is unnecessary.  this &quot;rule&quot; would be expressed a =
la Keynote<br><br>these things can be solved in other words.<br><br>l.<br><=
br></blockquote></div>

--0000000000006ed81905e17498fa--