Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4

[Luke Kenneth Casson Leighton]

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

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 3752 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5030 bytes --]

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 12749 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 14093 bytes --]