public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail•com>
To: Luke Kenneth Casson Leighton <lkcl@lkcl•net>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 85, Issue 4
Date: Tue, 7 Jun 2022 23:05:33 -0500	[thread overview]
Message-ID: <CAGpPWDZjAgDJVYFwm+Le3bRTW3U=HD5uE-MzC+nOKnonXL3D+Q@mail.gmail.com> (raw)
In-Reply-To: <CAPweEDwTSDhRav6Uw2iYTKJDZH60D8eoQYSc-VejUXjrTai60g@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2022-06-08  4:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.7.1654430403.1388.bitcoin-dev@lists.linuxfoundation.org>
2022-06-05 12:31 ` Luke Kenneth Casson Leighton
2022-06-08  4:05   ` Billy Tetrud [this message]
     [not found]     ` <06BC155F-2EB3-46E0-8A01-2BA5535DA015@gmail.com>
2022-06-15  4:02       ` Billy Tetrud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGpPWDZjAgDJVYFwm+Le3bRTW3U=HD5uE-MzC+nOKnonXL3D+Q@mail.gmail.com' \
    --to=billy.tetrud@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=lkcl@lkcl$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox