bitcoin-dev Digest, Vol 85, Issue 4

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

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

>   two aspects to consensus

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

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

> i made some modifications that required a *minimum number* of incoming

> hilariously, such isolated networks, being easy to identify, and also

> negative Certs were discussed but never implemented because they could do

> the other weakess is: *it takes discipline to maintain*. you cannot

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

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