Subject: Re: [Din] Blockchain protocols

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 Dec 2017 17:06:12 +0100

On Sat, Oct 21, 2017 at 12:48:38PM +0200,
 Jordi Paillissé <[email-masked]> wrote 
 a message of 642 lines which said:

> We have been investigating this issue and published a draft
> (https://datatracker.ietf.org/doc/draft-paillisse-sidrops-blockchain/). I
> attach a more up-to-date version.

I've just read -01 and I have a few remarks. First one and the biggest:

> For example, IANA could write a transaction allocating addresses to
> the RIRs, which in turn could allocate them to the LIRs, etc.
...
> This architecture mimics the hierarchy of IP address allocation
> present in today's Internet, with IANA on top of it.

In that case, what is the point of your proposal? If we keep the same
tree system IANA->RIR->LIR, why a blockchain?

And this contradicts the other section where you say:

>  Advantages:
>
>   o  Decentralized: No central entity controls the blockchain, it is
>      shared among all participants.

Now, some details:

> Some successful systems exist such as [Blockstack] and [Namecoin],
> which aim at building a secure DNS.

No. These systems have nothing to do with DNS. Unless you call "DNS"
any naming protocol, whatever its characteristics.

> Entities participating in the blockchain can achieve privacy using
> anonymous keys, i.e. randomly-generated keys not related to their
> identity

On most blockchains, keys are far from anonymous since transactions
are typically linkable. That's why one should "generate a new keypair
for each new transaction". Please check draft-tenoever-hrpc-anonymity.

> As a result the community has designed mining specific hardware
> (ASICs) that provides a competitive advantage.  In this context
> blockchain becomes less democratic, since the cost of participating
> in it increases.

You should mention ASIC-resistant algorithms, that are in use in most
blockchains, except Bitcoin.

> At the time of this writing major players in the blockchain
> environment such as [Ethereum] are preparing a shift towards PoS

Note that Ethereum promises a shift towards PoS from the beginning
and we still don't see it. Some care should be applied, before
relaying this promise.

> For each new block, a signer is selected randomly from the list of
> participants typically weighted according to their stake.

How can you check the integrity of the chain if it is truly random? I
assume you mean pseudo-random (because every miner needs to check it
was done honestly, so they need to run the same algorithm with the
same result).

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Tue, 19 Dec 2017 12:09:21 +0100

Dear Stephane,

Thanks for taking the time to read the draft. We really appreciate your 
comments and will take them into consideration for the next version of 
the draft.

Regarding your first question, you raise a very valid point. We think 
that a blockchain provides equivalent security and easier management 
when compared to existing systems (PKI-based). Although our first 
approach to this use-case gave full control to the holders of IP 
addresses (thus like any blockchain), after feedback from operators and 
RIRs, we realized that they shouldn't have full control. For example, if 
an IP holder looses the private key associated with its addresses, they 
will be lost forever. Thus, IMHO we need some recovery mechanism for 
such situations, but without giving back all control to the RIRs, 
because it would be again a standard PKI system. In other words, we 
would like to strike a good tradeoff between the centralization of PKI 
systems and the complete decentralization of blockchains. We would love 
to hear feedback from the community on this topic :)

Please find other comments below JP>>

Regards,

Jordi

> any naming protocol, whatever its characteristics.
JP>> Agree, the wording is too straightforward.
> blockchains, except Bitcoin.
JP>> Will add to the draft
> and we still don't see it. Some care should be applied, before
JP>> As far as I know, they have started testing their algorithm in a 
non-production network, but I agree it's taking more than expected.
> was done honestly, so they need to run the same algorithm with the
JP>> Exactly, several algorithms (Algorand, Ouroboros, etc) present this 
characteristics; more specifically, they randomly select the signer 
without being possible to predict it in advance.
>
> _______________________________________________
> Din mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/din

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Dec 2017 15:46:25 +0100

On Tue, Dec 19, 2017 at 12:09:21PM +0100,
 Jordi Paillissé Vilanova <[email-masked]> wrote 
 a message of 96 lines which said:

> > How can you check the integrity of the chain if it is truly
> > random? I assume you mean pseudo-random (because every miner needs
> > to check it was done honestly, so they need to run the same
> > algorithm with the same result).

> Exactly, several algorithms (Algorand, Ouroboros, etc) present this

It seems to me Algorand's selection of the miner is pseudo-random and
not random (they call it "algorithmically random" which seems to me a
fancy way of saying pseudo-random).

Oh, and since Algorand mentions VRF, do not miss draft-irtf-cfrg-vrf.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Dec 2017 10:27:32 -0500

On Dec 19, 2017, at 06:09, Jordi Paillissé Vilanova <[email-masked]> wrote:

> We think that a blockchain provides equivalent security and easier management when compared to existing systems (PKI-based).

You think that or hope that?

> For example, if an IP holder looses the private key associated with its addresses, they will be lost forever. Thus, IMHO we need some recovery mechanism for such situations, but without giving back all control to the RIRs, because it would be again a standard PKI system.

You can’t have the blockchain and eat it too. This is the fundamental problem of anything you stuff in a blockchain. The namecoin “DNS” has the same problem.

> In other words, we would like to strike a good tradeoff between the centralization of PKI systems and the complete decentralization of blockchains. We would love to hear feedback from the community on this topic :)

If you make any override of the blockchain, the blockchain properties are nullified and your system is better of not blockchaining at all.

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Dec 2017 16:34:25 +0100

On Tue, Dec 19, 2017 at 10:27:32AM -0500,
 Paul Wouters <[email-masked]> wrote 
 a message of 25 lines which said:

> You can’t have the blockchain and eat it too.

The world is not binary. You have intermediate solutions. Professional
notaries keeping private keys, or multi-signatures schemes, for
instance.

> This is the fundamental problem of anything you stuff in a
> blockchain. The namecoin “DNS” has the same problem.

This is _a_ problem (and a serious one), but it has solutions.

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Tue, 19 Dec 2017 16:42:08 +0100

I agree. In a blockchain you can implement any transaction logic you 
want, (e.g. expire a transaction after sometime, multi-signatures, etc), 
in order to remove some power to CAs and central authorities. As 
Stephane said, it's not necessarily a binary decision.

Regards,

Jordi

---

From: Jehan Tremback <[email-masked]>
Date: Tue, 19 Dec 2017 10:20:34 -0800

> You can’t have the blockchain and eat it too. This is the fundamental 
> problem of anything you stuff in a blockchain. The namecoin “DNS” has 
> the same problem.

It's always possible for a majority of the validators to change the software they are running. The large ipv6 address space can absorb individual oopsies, and then be "garbage collected" with a hard fork every few years to free addresses that were accidentally lost. If some huge top level entity loses its key somehow then an emergency hard fork can be done.

> If you make any override of the blockchain, the blockchain properties 
> are nullified and your system is better of not blockchaining at all.

The benefit you get from a blockchain that has occasional updates through hard fork is that you can have a system that has fine-grained operation which is governed through a majority vote. The fine grained operation happens day to day, backed up with a majority vote by hard fork when something needs to be changed. It would be too expensive to have a majority vote on every single address allocation, so we have a set of general rules which are automatically implemented but can be overridden if necessary.

-- 
  Jehan Tremback
  [email-masked]

On Tue, Dec 19, 2017, at 7:27 AM, Paul Wouters wrote:
> You can’t have the blockchain and eat it too. This is the fundamental 
> problem of anything you stuff in a blockchain. The namecoin “DNS” has 
> the same problem.
> 
> If you make any override of the blockchain, the blockchain properties 
> are nullified and your system is better of not blockchaining at all.
> 
> Paul
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Dec 2017 23:47:29 -0500 (EST)

On Tue, 19 Dec 2017, Jehan Tremback wrote:

> It's always possible for a majority of the validators to change the software they are running.

Either this process is impractical (eg truly distributed, no coercion or
collaboration possible) such as with bitcoin, or this process is
practical by a few important players, such as with the namecoin "DNS"
where 7 people can force a change.

So now imagine you lost a private key to domain "foo".

Either you can ask a few people to gain your domain back (in which case,
it is not different from a non-blockchain approach, so why bother) or
you cannot get your domain back (in which case you should explain to
Coca Cola what they should do when they lose their private key and the
domain is forever lost.

Or imagine you win a court case against person X running a "foo" domain
where "foo" is your trademark. Either the court ruling cannot be enforced,
in which case you get to explain to Coca Cola why they won the suit but
still don't have the name, or the court can force the handover of the
domain, in which case the current system without blockchain has the same
property.

> The benefit you get from a blockchain that has occasional updates through hard fork

I don't think "hard fork" is a scalable solution to 250 Million domain
names and their lost keys and fought court battles.

> is that you can have a system that has fine-grained operation which is governed through a majority vote. The fine grained operation happens day to day, backed up with a majority vote by hard fork when something needs to be changed. It would be too expensive to have a majority vote on every single address allocation, so we have a set of general rules which are automatically implemented but can be overridden if necessary.

Yes, we have such a legal system in place already. You are not improving
the existing system.

Paul

---

From: Nikander Pekka <[email-masked]>
Date: Wed, 20 Dec 2017 06:44:34 +0000

> I agree. In a blockchain you can implement any transaction logic you want, (e.g. expire a transaction after sometime, multi-signatures, etc), in order to remove some power to CAs and central authorities. As Stephane said, it's not necessarily a binary decision.

Well, depending on your trust model and business requirements, it may no longer make sense to use a PoW blockchain under such conditions.  A (non-PoW) DLT or something _like_ IOTA tangle*, where the "work" is pretty evenly distributed, may still make pretty much sense, though.

IMHO it is important to make distinction between the "distributed ledger" and "PoW-based consensus" properties in DLTs.  AFAICS, the very idea of a distributed ledger is much more applicable in general than the idea of PoW-based consensus.

--Pekka

* I'm well aware of the technical critic against the IOTA implementation.  But that doesn't diminish the beauty of the tangle _idea_ in my eyes.

---

From: Nikander Pekka <[email-masked]>
Date: Wed, 20 Dec 2017 06:47:42 +0000

> The benefit you get from a blockchain that has occasional updates through hard fork is that you can have a system that has fine-grained operation which is governed through a majority vote. The fine…

IMNSHO, relying on hard forks and majority vote chaos on every vote is a pretty lousy governance model for a mission critical IT system.  

Of course, if we don't find any better governance models that strike on the middle ground between fully centralised and evenly distributed, then we may need to live with hard forks and transition periods that last days until the dust settles on each fork.

--Pekka

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Wed, 20 Dec 2017 10:03:31 +0100

Yep, a thing we're starting to see is that (in some cases) blockchains 
need a governance model suited to their use-case, taking into account 
all stakeholders' positions. This way you avoid unnecessary forks and 
confusion (I'm thinking of the Bitcoin cash fork).

However, finding this governance model may prove difficult.

Regards,

Jordi

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 20 Dec 2017 09:14:38 +0000

folks may be interested in some legal-viewpoint papers on blockchain - see
http://js573.user.srcf.net/mccrc/events/2017-symposium-blockchain/

> in order to remove some power to CAs and central authorities. As Stephane 
> said, it's not necessarily a binary decision.
> 
> Well, depending on your trust model and business requirements, it may no 
> longer make sense to use a PoW blockchain under such conditions.  A 
> (non-PoW) DLT or something _like_ IOTA tangle*, where the "work" is 
> pretty evenly distributed, may still make pretty much sense, though.
> 
> IMHO it is important to make distinction between the "distributed ledger" 
> and "PoW-based consensus" properties in DLTs.  AFAICS, the very idea of a 
> distributed ledger is much more applicable in general than the idea of 
> PoW-based consensus.
> 
> --Pekka
> 
> * I'm well aware of the technical critic against the IOTA implementation. 
>  But that doesn't diminish the beauty of the tangle _idea_ in my eyes.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Dec 2017 15:19:54 +0000

> http://js573.user.srcf.net/mccrc/events/2017-symposium-blockchain/

Another excellent paper on the topic of governance and blockchains is:
https://www.oii.ox.ac.uk/blog/the-blockchain-paradox-why-distributed-ledger-technologies-may-do-little-to-transform-the-economy/

---

From: Melinda Shore <[email-masked]>
Date: Thu, 21 Dec 2017 14:33:16 -0900

On 12/19/17 2:09 AM, Jordi Paillissé Vilanova wrote:
> when compared to existing systems (PKI-based). 
Well, I think you need to be somewhat careful in what you
mean by "security," here.  There may be strong cryptographic
guarantees but still have the system subvertable through other
means.  For example, when you presented in Prague you argued
in favor of a proof-of-stake consensus mechanism, but while
those still have double-spend protections they are vulnerable to
monopoly control.

Melinda

-- 
Software longa, hardware brevis

PGP fingerprint: 795A 714B CD08 F996 AEFE
                 AB36 FE18 57E9 6B9D A293

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Fri, 22 Dec 2017 13:57:23 +0100

True, monopolies are a drawback for PoS, but I think we can overcome it. 
For example, in Algorand  (thanks for the pointer!) security is 
guaranteed if at least 2/3 of the players are honest.

In other blockchains what I've seen is:

  * Use data from all users and transactions as an input to PoS (NEM)
  * Add an additional control when the blockchain is starting and remove
    it when it's mature enough to prevent attacks (IOTA)

Regards,

Jordi

---

From: Albert Cabellos <[email-masked]>
Date: Fri, 22 Dec 2017 16:01:34 +0100

Hi all

On Fri, Dec 22, 2017 at 1:57 PM, Jordi Paillissé Vilanova <[email-masked]
> wrote:

> For example, in Algorand  (thanks for the pointer!) security is guaranteed
> if at least 2/3 of the players are honest.
>

Regarding monopolies, we can design the PoS algorithm to have a smart
mapping of IP prefixes to the weight of the randomness (i.,e probability of
being selected randomly to add a block) to mitigate this. Actually this
approach has to be followed in IPv6, otherwise the huge unallocated IPv6
address space results in a monopoly. But overall I agree, monopolies are a
drawback.

With certificates, CAs are the monopolies :)

>    - Use data from all users and transactions as an input to PoS (NEM)
>    - Add an additional control when the blockchain is starting and remove
> Din mailing [email-masked]://www.irtf.org/mailman/listinfo/din
>
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 22 Dec 2017 15:58:45 +0000

> With certificates, CAs are the monopolies :) 

I see the smiley here, but I want to emphasize that this exactly the opposite of the truth. The relying party software (primarily the browsers) have explicit policies that no CA or small group of CAs will ever become a monopoly. The policies are defined and updated in public. Compare this to the hard-to-find algorithms and assumptions in most blockchains.

--Paul Hoffman

---

From: Albert Cabellos <[email-masked]>
Date: Thu, 28 Dec 2017 19:06:58 +0100

Thanks for the clarification and sorry for my lack of formality.

What the blockchain consensus algorithms brings is a 'knob' to adjust where
the trust is. How to adjust the 'knob' is debatable and provides advantages
and disadvantages.

The blockchain *must* have easy-to-find and public assumptions, this should
be discussed and agreed publicly. Blockchains should not be understood as
anarchic, they require governance just as today's Internet. The role of the
governance is precisely to publicly decide where the 'knob' is and what can
and cannot do the algorithms.

On Fri, Dec 22, 2017 at 4:58 PM, Paul Hoffman <[email-masked]>
wrote:

> I see the smiley here, but I want to emphasize that this exactly the
> opposite of the truth. The relying party software (primarily the browsers)
> have explicit policies that no CA or small group of CAs will ever become a
> monopoly. The policies are defined and updated in public. Compare this to
> the hard-to-find algorithms and assumptions in most blockchains.
>
> --Paul Hoffman