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

[Billy Tetrud via bitcoin-dev]

>   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

.


On Thu, Jun 9, 2022 at 6:34 AM lkcl  wrote:

> --
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> On Wed, Jun 8, 2022 at 5:05 AM Billy Tetrud 
> 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 

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

[Billy Tetrud via bitcoin-dev]

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 +
> > 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Kenneth Casson Leighton via bitcoin-dev]

(apologies i am subscribed digest)

On Sun, Jun 5, 2022 at 1:00 PM
 wrote:

> Date: Sun, 05 Jun 2022 04:18:04 +
> From: alicexbt 
> To: Bitcoin Protocol Discussion
> 
> Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
> Message-ID:
> 
> 
> 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