Re: [Din] blockchain for IP addresses draft update

Jordi Paillissé Vilanova <> Wed, 04 July 2018 11:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C51AD130E3B; Wed, 4 Jul 2018 04:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y7RDy6qVhZrF; Wed, 4 Jul 2018 04:28:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8F952130DCE; Wed, 4 Jul 2018 04:28:32 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id w64BSGja007150; Wed, 4 Jul 2018 13:28:16 +0200
Received: from [] ( []) by (Postfix) with ESMTPSA id 5EC98165; Wed, 4 Jul 2018 13:28:11 +0200 (CEST)
To: David Mazieres expires 2018-09-30 PDT <>,,, Stephane Bortzmeyer <>,, Greg Skinner <>,, "" <>, Vina Ermagan <>, Fabio Maino <>, Albert Cabellos <>,
References: <> <> <>
From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= <>
Message-ID: <>
Date: Wed, 4 Jul 2018 13:28:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------556A0A05FB0DA42423EC9986"
Content-Language: en-GB
Archived-At: <>
X-Mailman-Approved-At: Wed, 04 Jul 2018 21:08:57 -0700
Subject: Re: [Din] blockchain for IP addresses draft update
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Jul 2018 11:28:37 -0000

Hi David,

Indeed, we did not delve deeper into the PoS algorithm. This depends on 
the specific implementation, our opinion is that an Algroand-like would 
be a good option, and if it can tolerate a large portion of offline 
participants even better. In addition, we think that punishing or 
deposit mechanisms are not desirable because they don't fit the 
characteristics of the scenario. Overall the incentive is "a more secure 
Internet", we believe that this is well-aligned with the economical 
interests of the participants.

Regarding SCP, the fact that you only need to trust your neighbours may 
prove very convenient in this scenario. As you said, it reflects current 
Internet trust schemes, this basically means that BGP Peering = Trust = 
Stellar quorum slices. We'll look into this for the next iteration of 
the draft.



El 02/07/18 a les 17:59, David Mazieres ha escrit:
> Jordi Paillissé Vilanova <> writes:
>> (apologies for cross-posting)
>> Dear all,
>> We have submitted a new version of the draft addressing comments
>> received both on the mailing list and IETF meetings.
>> Thanks to all of you for taking the time to read the draft :)
>> Regards,
>> Jordi
> Very interesting draft.  One high-level comment, I would avoid terms
> like "tamper-proof" or really anything-"proof" except possibly in the
> context of information-theoretic security, in favor of tamper-resistant.
> This is particularly important in the context of blockchains that have
> experienced a number of forks in practice and where it would likely take
> only a few tens of millions of dollars a day to tamper with history.
> I think the draft would benefit from a much finer-grained consideration
> of several different forms of proof-of-stake, because there are a number
> of assertions that do not hold for all forms of proof of stake.  E.g.,
> will there be delegation like peercoin, randomization like algorand,
> penalties like Casper, sleepy nodes like snowwhite?
> And while of course I'm biased on this issue, I think that a
> Byzantine-agreement-based approach like SCP
> ( would work
> better than PoS.  SCP is well matched to the Internet peering model,
> which we already know is a workable decentralized governance model.  You
> may not agree, but it would at least be nice for the document to explain
> why you reject this approach.
> David