Subject: Re: [saag] [Ilc] Distributed ledgers and control

From: Deian Stefan <[email-masked]>
Date: Sat, 1 Apr 2017 13:32:39 -0700

On Wed, Mar 29, 2017 at 6:24 AM, Eric Rescorla <[email-masked]> wrote:
> 
> On Wed, Mar 29, 2017 at 6:43 AM, David Mazieres
> <[email-masked]> wrote
>> 
>> Furthermore, the notion of a blockchain-esque public log can be
>> leveraged for various forms of transparency.  For instance, last year
>> there was a controversy in which Apple claimed to refuse an FBI request
>> to sign a special compromised iPhone bootloader.  Unfortunately, for all
>> we know, Apple may have signed the software after all while claiming not
>> to for the PR benefit.  That they probably didn't yields the worst of
>> both worlds--angering the FBI and still spooking potential customers.
>> Requiring firmware updates to be published in a public log would allow
>> the public to verify whether or not such activity is happening.
> 
> 
> Just for those who may not be tracking this kind of work, this is something
> that's starting to happen, though typically with semi-centralized consensus
> mechanisms. In that form, it's generally known as "Binary Transparency".
> 
> See, for instance:
> 
> - https://groups.google.com/forum/#!forum/binary-transparency
> and
> - https://wiki.mozilla.org/Security/Binary_Transparency

Piggybacking on CT seems pretty interesting (and pretty clever!). For things like
Firefox releases this is also likely sufficient. I think this problem gets a bit more
complicated when you have many, different parties that are releasing software.

I’ve been meaning to chime in on this list especially since David I think talked about
it in the in-person meeting: one thing we’ve been been looking at UCSD is how to
build uncurated package management systems/software distribution systems like npm
<https://www.npmjs.com/> where average developers or CI tools push releases. We have a short
position paper describing the beginning of this work here:
 
- https://cseweb.ucsd.edu/~dstefan/pubs/brown:2017:spam.pdf (or http://spam.programming.systems)

Beyond transparency, we also want to (1) allow developers to mark certain versions of packages as
vulnerable (2) provide key continuity to avoid burdening developers with key management and revocation
and (3) make it easy to write tooling and policies to really make it possible to only install
packages/libraries you trust.

The blockchain-eque public log is hugely important for what we’re trying to do because we’re trying
to manage not only project data/metadata, but also user data/metadata. Moreover, we really care about
latency: a developer waiting 15 minutes to publish a package is likely a deal-breaker.

-deian

---

From: iang <[email-masked]>
Date: Mon, 3 Apr 2017 00:13:36 -0400

Referring to the article.

I'd argue (and it's arguable) that governance is out of scope of the IETF.

     > *Regardless of the model, my point is that blockchain
    technologies cannot escape the problem of governance.*

Full agreement.

    > And  this leads me to my final point, a provocation:*once you address
    the problem of governance, you no longer need blockchain;*you can
    just as well use conventional technology that assumes a trusted
    central party to enforce the rules, because you’re already trusting
    somebody (or some organization/process) to make the rules. I call
    this blockchain’s ‘governance paradox’: once you master it, you no
    longer need it.

I agree that blockchain has no easy answers to governance, apparently.  
But...

The paradox is only assuming that governance is of a form to replace or 
neuter the distributed nature of blockchain.  This is not necessarily 
so.  Designs have been deployed (bitshares, steem to my knowledge) that 
distributed the voting for changes onto the chain itself.  Other designs 
have been mooted (DAMN, my work) that resolve disputes after the fact 
and preserve the entry of parties without being denied by governance (in 
other words, work happily with psuedonyms).

In short, governance is how we as humans govern the system, and while 
powerful third parties are popular solutions, they are by no means the 
only solution.  The challenge is to improve the existing governance 
mechanisms of extant blockchains and not lose the benefit in the 
process.  Or to design new blockchains around distributed governance 
mechanisms where the older designs fall short.

iang

ps: on R3's Corda design:

     > Indeed, R3’s design seems to have something called “uniqueness
    services”, which look a lot like trusted third-party enforcers
    (though this isn’t clear from thewhite paper
    <https://static1.squarespace.com/static/55f73743e4b051cfcc0b02cf/t/57bda2fdebbd1acc9c0309b2/1472045822585/corda-introductory-whitepaper-final.pdf>).
    RSCoin likewise relies entirely on trusted third parties.

although I accept it might be hard to read in the Intro because there is 
so much packed into the paper - the 'uniqueness service isn't obligatory 
or centralised.  Firstly, the design is that the developer of a contract 
can choose where in the protocol flow of a contract that a race 
condition or similar might occur, and at that point a third party is 
brought on to do that mediation.  Secondly, the choice of the third 
party is left to the parties to the contract, they can use themselves, 
or someone else, or they can rotate.  Thirdly, the use of the third 
party is (in some handwavy sense) not dependent on the nature of the 
transaction.  In sum, the third party 'uniqueness service' can be 
organised in such a way that he does not become a defacto enforcer.  
Disclosure - I was co-author on the Intro white paper.

RSCoin is of course a completely separate beast - it is a digital cash 
server oriented from the start to one issuer, one governance, one huge 
cash issue.  Centralised administration was assumed, as far as I can see 
(I've read the paper and heard a talk, I suppose there could be 
something I missed).

On 28/03/2017 14:38, Paul Hoffman wrote:
> Greetings. A few folks have recently been discussing which ledger and 
> ledger-esque protocols should be used with upcoming IETF protocols. It 
> is easy to conflate the governance of the ledger with its uses. A good 
> article that helps make the distinction is:
>
> https://www.oii.ox.ac.uk/blog/the-blockchain-paradox-why-distributed-ledger-technologies-may-do-little-to-transform-the-economy/ 
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag