From nobody Sun Dec 10 08:34:57 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A81128B93 for ; Sun, 10 Dec 2017 08:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ5IDCdVnHyG for ; Sun, 10 Dec 2017 08:34:53 -0800 (PST) Received: from smtp-out-02.aalto.fi (testsmtp.aalto.fi [130.233.228.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF29124D6C for ; Sun, 10 Dec 2017 08:34:53 -0800 (PST) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9B14E271133_A2D6244B for ; Sun, 10 Dec 2017 16:35:16 +0000 (GMT) Received: from exng1.org.aalto.fi (exng1.org.aalto.fi [130.233.223.20]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng1.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTPS id 5DED3271113_A2D6244F for ; Sun, 10 Dec 2017 16:35:16 +0000 (GMT) Received: from exng7.org.aalto.fi (130.233.223.26) by exng1.org.aalto.fi (130.233.223.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Sun, 10 Dec 2017 18:34:49 +0200 Received: from exng2.org.aalto.fi (130.233.223.21) by exng7.org.aalto.fi (130.233.223.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Sun, 10 Dec 2017 18:34:49 +0200 Received: from exng2.org.aalto.fi ([fe80::5989:81ad:a65:2cbf]) by exng2.org.aalto.fi ([fe80::5989:81ad:a65:2cbf%12]) with mapi id 15.01.0669.032; Sun, 10 Dec 2017 18:34:49 +0200 From: Nikander Pekka To: "din@irtf.org" Thread-Topic: Invitation to IoThon, the first IoT, blockchain, and ICN hackathon in Berlin! Thread-Index: AQHTcdTMc83dKHNnz0qRRvl+ZcXJFA== Date: Sun, 10 Dec 2017 16:34:49 +0000 Message-ID: <5468987C-CBF6-4124-B730-D7F1E73C7CE4@aalto.fi> Accept-Language: en-GB, fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [130.233.0.5] Content-Type: text/plain; charset="utf-8" Content-ID: <893C763A16BE0748818F93C2209C9543@aalto.fi> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Din] Invitation to IoThon, the first IoT, blockchain, and ICN hackathon in Berlin! X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Sun, 10 Dec 2017 16:34:56 -0000 SGkgYWxsLA0KDQpXZSB3b3VsZCBsaWtlIHRvIGludml0ZSB5b3UgdG8gam9pbiBJb1Rob24sIEV1 cm9wZSdzIGZpcnN0IG9wZW4gc291cmNlIElvVCwgYmxvY2tjaGFpbnMgYW5kIElDTiAoSW5mb3Jt YXRpb24gQ2VudHJpYyBOZXR3b3JraW5nKSBoYWNrYXRob24gd2hpY2ggd2lsbCB0YWtlIHBsYWNl IG9uIEphbnVhcnkgMTfigJMxOSwgMjAxOCBpbiBCZXJsaW4hDQoNClJlYWQgbW9yZSBhYm91dCB0 aGUgZXZlbnQgYXQgICBodHRwczovL2lvdGhvbi5pby8NCg0KSW9UaG9uIGlzIGEgZnJlZS1vZi1j aGFyZ2UgZXZlbnQgZm9yIHN0dWRlbnRzLCBkZXZlbG9wZXJzIGFuZCBhbnlvbmUgaW50ZXJlc3Rl ZCBpbiBkZXZlbG9waW5nIElvVCBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUgcHJvamVjdHMgd2l0aCBi bG9ja2NoYWlucyBhbmQvb3IgSUNOLCB0d28gbmV3IHRlY2hub2xvZ2llcyB0aGF0IGhhdmUgdGhl IHBvdGVudGlhbCBvZiBjaGFuZ2luZyBvdXIgZnV0dXJlLg0KDQpUaGUgcGFydGljaXBhbnRzIGhh dmUgYWJvdXQgMjQgaG91cnMgdG8gZGV2ZWxvcCB0aGVpciBvd24gcHJvamVjdHMgYW5kIHNvbHZp bmcgY2hhbGxlbmdlcyBwcm92aWRlZCBieSBvcmdhbmlzZXJzIGFuZCBwYXJ0bmVyIGNvbXBhbmll cywgb2ZmZXJpbmc6DQoNCuKAoiBUdXRvcmlhbHMgb24gYmxvY2tjaGFpbnMsIElDTiwgYW5kIG1v cmUNCuKAoiAyNCsgaG91cnMgaGFja2luZyB0b2dldGhlcg0K4oCiIE1haW4gcHJpemUgMTAwMOKC rA0K4oCiIEZyZWUgZm9vZCBhbmQgZHJpbmtzDQoNClRoZSBudW1iZXIgb2YgdGhlIHBhcnRpY2lw YW50cyBpcyBsaW1pdGVkLCBzbyBieSBhcHBseWluZyBxdWlja2x5IHlvdSBlbmhhbmNlIHlvdXIg Y2hhbmNlcyB0byBiZSBhZG1pdHRlZC4gQXBwbGljYXRpb24gZGVhZGxpbmUgaXMgRGVjZW1iZXIg MjN0aC4NCg0KV2Ugd2lsbCBldmFsdWF0ZSB0aGUgYXBwbGljYXRpb25zIGNvbnRpbnVvdXNseSwg YW5ub3VuY2luZyB0aGUgcGFydGljaXBhbnRzIG5vIGxhdGVyIHRoYW4gRGVjZW1iZXIgMjd0aC4g VGhpcyBwcm92aWRlcyBhdCBsZWFzdCB0aHJlZSB3ZWVrcyB0byBib29rIGZsaWdodHMgYW5kIG1h a2Ugb3RoZXIgdHJhdmVsIGFycmFuZ2VtZW50cy4NCg0KRmVlbCBmcmVlIHRvIGFkdmVydGlzZSB0 aGlzIGV2ZW50IHRvIHlvdXIgY29sbGVhZ3VlcyBhbmQgc3R1ZGVudHMhDQoNCkhhcHB5IGhhY2tp bmcgYW5kIHNlZSB5b3UgaW4gQmVybGluIQ0KDQotLVBla2thIE5pa2FuZGVyDQoNCg== From nobody Wed Dec 13 00:05:39 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFBE126C26 for ; Wed, 13 Dec 2017 00:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EcjYUgLz6jj for ; Wed, 13 Dec 2017 00:05:35 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063E7120046 for ; Wed, 13 Dec 2017 00:05:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.45,397,1508796000"; d="scan'208";a="248180802" Received: from static-176-183-206-74.ncc.abo.bbox.fr (HELO [192.168.1.40]) ([176.183.206.74]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 13 Dec 2017 09:05:33 +0100 From: =?UTF-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= To: din@irtf.org Message-ID: <828847aa-f9c0-b4d6-e40d-a76849300f59@inria.fr> Date: Wed, 13 Dec 2017 09:05:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: [Din] IEEE/IFIP Man2Block 2018 - Call for Papers - Deadline is approaching: January 5, 2018 X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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, 13 Dec 2017 08:05:38 -0000 ====================================================================== IEEE/IFIP Man2Block 2018 International Workshop on Managing and Managed by Blockchain Colocated with IEEE/IFIP NOMS 2018, 27 April 2018, Taipei, Taiwan https://man2block.inria.fr Paper submission: January 5, 2018 Notification to authors: February 28, 2018 Camera ready: March 16, 2018 Workshop date: April 27, 2018 ====================================================================== The blockchain technologies and their ecosystem are growing at a high pace. Starting from bitcoin, there are now numerous blockchain technologies and applications, with new ones appearing every month. Although all these innovations reside in cryptographic research and developments, blockchain is firstly a distributed system. The underlying infrastructure is blindly leveraged by blockchain technologies whereas this arises serious concerns in terms of scalability, quality-of-service, security and fault tolerance. Indeed, monitoring and configuring such a distributed system without or with a loosely control is naturally difficult. Even fully understanding and predicting expected performance before a real deployment at large scale is vital from a technical and business operations perspective. Furthermore, blockchain is also a potential candidate to ease network and service management. Indeed, many services over Internet rely on pre-establish trust among entities which is hard to maintain at large scale and which are thus the sources of many malfunctioning or the targets of attacks. Among them, we can cite the naming services, the distributed cloud management, resource sharing, the PKI management, or even distributed policy management and accountability within a sofwtarized network architecture. Man2Block 2018 is a dedicated venue for bringing together students, researchers and practitioners from academia and industry who share common interests in the management and the use of the blockchain infrastructure and smart contracts in network, system, service operations and management. Theoretical approaches, practical experimentations and papers highlighting future trends and challenges are welcomed. Authors are invited to submit original contributions (full and short papers) that fall into the following list of topics of interest (not exhaustive): - Blockchain infrastructure management - Security - Monitoring and configuration - Anomaly detection - Resource provisioning - Blockchain QoS and QoE - Large-scale experimentation - Smart contract management - Auditing - Threat assessment - Privacy and anonymity - PKI for blockchains - Simulation and evaluation methodologies - Analytics - Attack design and mitigation - Blockchain architectures ====================================================================== Venue: Man2Block will be held in conjunction with IEEE/IFIP Network Operations and Management Symposium (NOMS) 2018 in Taipei, Taiwan, 27 April 2018 Submission Instructions: Prospective authors are invited to submit original, unpublished works for publication in the IEEE NOMS 2018 proceedings and for presentation in the workshop. Papers under review elsewhere must not be submitted to the workshop. Submissions must be in IEEE 2-column style and have a maximum length of 6 pages (full paper) or 4 pages (short paper). The accepted papers will be submitted for publication in the IEEE Xplore Digital Library. Papers will be withdrawn from IEEE Xplore in case the authors do not present their paper at the workshop Submissions must be made in PDF format via: https://jems.sbc.org.br/home.cgi?c=2939 ====================================================================== Man2Block Workshop co-chairs: Jérôme François, Inria Nancy Grand Est, France Abdelkader Lahmadi, Université de Lorraine, France Radu State, University of Luxembourg, Luxembourg Burkhard Stiller, University of Zurich, Switzerland From nobody Mon Dec 18 08:06:20 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C224E12708C for ; Mon, 18 Dec 2017 08:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT1dX8BXPhWW for ; Mon, 18 Dec 2017 08:06:16 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6031112D7EC for ; Mon, 18 Dec 2017 08:06:16 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E806D282699; Mon, 18 Dec 2017 17:06:12 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id E17EC2826A8; Mon, 18 Dec 2017 17:06:12 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id DA529282699; Mon, 18 Dec 2017 17:06:12 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id CFF946423548; Mon, 18 Dec 2017 17:06:12 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id C2C35401D4; Mon, 18 Dec 2017 17:06:12 +0100 (CET) Date: Mon, 18 Dec 2017 17:06:12 +0100 From: Stephane Bortzmeyer To: Jordi =?utf-8?Q?Pailliss=C3=A9?= Cc: "Rene 'Renne' Bartsch, B.Sc. Informatics" , din@irtf.org, Albert Cabellos Message-ID: <20171218160612.eu7glh7hxkvssqn3@nic.fr> References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000375, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.155716 Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Mon, 18 Dec 2017 16:06:19 -0000 On Sat, Oct 21, 2017 at 12:48:38PM +0200, Jordi Paillissé 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 nobody Tue Dec 19 03:09:36 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19CE127871 for ; Tue, 19 Dec 2017 03:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oih6Qhc0wz79 for ; Tue, 19 Dec 2017 03:09:30 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D8126B71 for ; Tue, 19 Dec 2017 03:09:29 -0800 (PST) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vBJB9QqF015183; Tue, 19 Dec 2017 12:09:26 +0100 Received: from [147.83.35.250] (dync-35-250.ac.upc.es [147.83.35.250]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id AEF0140C; Tue, 19 Dec 2017 12:09:21 +0100 (CET) To: Stephane Bortzmeyer Cc: Albert Cabellos , din@irtf.org References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: Date: Tue, 19 Dec 2017 12:09:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171218160612.eu7glh7hxkvssqn3@nic.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Tue, 19 Dec 2017 11:09:35 -0000 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 El 18/12/17 a les 17:06, Stephane Bortzmeyer ha escrit: > On Sat, Oct 21, 2017 at 12:48:38PM +0200, > Jordi Paillissé 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. JP>> Agree, the wording is too straightforward. > >> 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. JP>> Will add to the draft > >> 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. 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. > >> 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). 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 > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din From nobody Tue Dec 19 06:46:30 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD05126C25 for ; Tue, 19 Dec 2017 06:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCX6Us6N-4A1 for ; Tue, 19 Dec 2017 06:46:27 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E9A12704A for ; Tue, 19 Dec 2017 06:46:27 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 3250A282670; Tue, 19 Dec 2017 15:46:25 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 2C0FB282727; Tue, 19 Dec 2017 15:46:25 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 2568F282670; Tue, 19 Dec 2017 15:46:25 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 1E8226423551; Tue, 19 Dec 2017 15:46:25 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 1213A401D4; Tue, 19 Dec 2017 15:46:25 +0100 (CET) Date: Tue, 19 Dec 2017 15:46:25 +0100 From: Stephane Bortzmeyer To: Jordi =?utf-8?Q?Pailliss=C3=A9?= Vilanova Cc: Stephane Bortzmeyer , Albert Cabellos , din@irtf.org Message-ID: <20171219144625.tshnapgl3jx4mbs4@nic.fr> References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000234, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.19.143616 Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Tue, 19 Dec 2017 14:46:29 -0000 On Tue, Dec 19, 2017 at 12:09:21PM +0100, Jordi Paillissé Vilanova 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 > characteristics; more specifically, they randomly select the signer > without being possible to predict it in advance. 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 nobody Tue Dec 19 07:27:44 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5C0127876 for ; Tue, 19 Dec 2017 07:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Tn3pqT8ScLS for ; Tue, 19 Dec 2017 07:27:40 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A821241FC for ; Tue, 19 Dec 2017 07:27:40 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3z1MGd3879z1q6; Tue, 19 Dec 2017 16:27:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1513697257; bh=FD4CqzPRE8ITesBII6c2uN46HrfhTuVIt9IhwqRtWRc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bolZJ0s1ocwYThMVjsaPxZ1JShQB2LlQDFCxZFcmmRz++Auhytv4vZw4VQCyzmoka /U0eWmwL6fjY3tobEIEWcWJ3p7FAIDVBQcodclWH7HAj6TbAXAf2WbIxRy4ANxsT/R 1tjqb1AR9mnONAAUrq0NOgGiafHYZDcPVsRwK+jM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id nP9ozsup0fYi; Tue, 19 Dec 2017 16:27:34 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 19 Dec 2017 16:27:33 +0100 (CET) Received: from [193.111.228.72] (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id C17AB61A34; Tue, 19 Dec 2017 10:27:32 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C17AB61A34 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Tue, 19 Dec 2017 10:27:32 -0500 Cc: Stephane Bortzmeyer , Albert Cabellos , din@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> To: =?utf-8?Q?Jordi_Pailliss=C3=A9_Vilanova?= Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Tue, 19 Dec 2017 15:27:43 -0000 On Dec 19, 2017, at 06:09, Jordi Pailliss=C3=A9 Vilanova = wrote: > We think that a blockchain provides equivalent security and easier managem= ent 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 ad= dresses, they will be lost forever. Thus, IMHO we need some recovery mechani= sm for such situations, but without giving back all control to the RIRs, bec= ause it would be again a standard PKI system. You can=E2=80=99t have the blockchain and eat it too. This is the fundamenta= l problem of anything you stuff in a blockchain. The namecoin =E2=80=9CDNS=E2= =80=9D has the same problem. > In other words, we would like to strike a good tradeoff between the centra= lization 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 nu= llified and your system is better of not blockchaining at all. Paul From nobody Tue Dec 19 07:34:30 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E5F12D77B for ; Tue, 19 Dec 2017 07:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m--v1jsE4PcG for ; Tue, 19 Dec 2017 07:34:28 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F6C129C6E for ; Tue, 19 Dec 2017 07:34:27 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id EA20028243E; Tue, 19 Dec 2017 16:34:25 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id E330D2824A0; Tue, 19 Dec 2017 16:34:25 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id DC41E28243E; Tue, 19 Dec 2017 16:34:25 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id D6DEE642A7A1; Tue, 19 Dec 2017 16:34:25 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id CA880401D4; Tue, 19 Dec 2017 16:34:25 +0100 (CET) Date: Tue, 19 Dec 2017 16:34:25 +0100 From: Stephane Bortzmeyer To: Paul Wouters Cc: Jordi =?utf-8?Q?Pailliss=C3=A9?= Vilanova , Stephane Bortzmeyer , Albert Cabellos , din@irtf.org Message-ID: <20171219153425.oarg3egwox27bqbh@nic.fr> References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.145536, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.19.152415 Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Tue, 19 Dec 2017 15:34:29 -0000 On Tue, Dec 19, 2017 at 10:27:32AM -0500, Paul Wouters 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 nobody Tue Dec 19 07:42:20 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C6E12D77B for ; Tue, 19 Dec 2017 07:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6P97x4hWH4q for ; Tue, 19 Dec 2017 07:42:17 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 54A40129C6D for ; Tue, 19 Dec 2017 07:42:17 -0800 (PST) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vBJFgD4Z023343; Tue, 19 Dec 2017 16:42:13 +0100 Received: from [147.83.35.239] (dync-35-239.ac.upc.es [147.83.35.239]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id AC0C3144; Tue, 19 Dec 2017 16:42:08 +0100 (CET) To: Stephane Bortzmeyer , Paul Wouters Cc: Albert Cabellos , din@irtf.org References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> <20171219153425.oarg3egwox27bqbh@nic.fr> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: Date: Tue, 19 Dec 2017 16:42:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171219153425.oarg3egwox27bqbh@nic.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Tue, 19 Dec 2017 15:42:19 -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. Regards, Jordi El 19/12/17 a les 16:34, Stephane Bortzmeyer ha escrit: > On Tue, Dec 19, 2017 at 10:27:32AM -0500, > Paul Wouters 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 nobody Tue Dec 19 10:20:38 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D9112D7E8 for ; Tue, 19 Dec 2017 10:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoDBikQ1BdaO for ; Tue, 19 Dec 2017 10:20:35 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D751127136 for ; Tue, 19 Dec 2017 10:20:35 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9E5F820DD1 for ; Tue, 19 Dec 2017 13:20:34 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Tue, 19 Dec 2017 13:20:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Orgsgg FGJ91A+ND3V1LqJVrMbRh5Uwvyujf5/BubtvU=; b=poQ4pMqKHPzJKHGvcUI0u4 Mt5DJtoIWBt5AO371RIPB7Yf2GvOKh9bWS0pedep587pDHoVyEWOL+WoLYDdY85p YnqM9aZHksgfLT4R4mK/UT306t/R+U/Lc94rP9nR11UD+9GjkG3YLhNiLDscDUL5 WIYLQyHLst5g/4Fh1IHM5Tdztcdxt7EcPD6y8AP+CB8sq1v1kf/T1a5kmvTXc6Tj aMy3fU9o4rLXmfbxVq5rlmLib/opLps2vRXW4lzWzmQO7BNq/1BrdW7GixniXPfM ARu5AIiPFSDPfVVNv918Xk2BSGjDuW35MP6g10gXOg7sH9+BgPZt7NASUiRBvdjw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 69D599E3AF; Tue, 19 Dec 2017 13:20:34 -0500 (EST) Message-Id: <1513707634.3934032.1210296976.0AD4B135@webmail.messagingengine.com> From: Jehan Tremback To: din@irtf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6353e3a Date: Tue, 19 Dec 2017 10:20:34 -0800 References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> In-Reply-To: <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Tue, 19 Dec 2017 18:20:37 -0000 > > 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 mec= hanism for such situations, but without giving back all control to the RIRs= , because it would be again a standard PKI system. >=20 > You can=E2=80=99t have the blockchain and eat it too. This is the fundame= ntal=20 > problem of anything you stuff in a blockchain. The namecoin =E2=80=9CDNS= =E2=80=9D has=20 > the same problem. It's always possible for a majority of the validators to change the softwar= e they are running. The large ipv6 address space can absorb individual oops= ies, and then be "garbage collected" with a hard fork every few years to fr= ee addresses that were accidentally lost. If some huge top level entity los= es its key somehow then an emergency hard fork can be done. > > In other words, we would like to strike a good tradeoff between the cen= tralization of PKI systems and the complete decentralization of blockchains= . We would love to hear feedback from the community on this topic :) >=20 > If you make any override of the blockchain, the blockchain properties=20 > are nullified and your system is better of not blockchaining at all. The benefit you get from a blockchain that has occasional updates through h= ard fork is that you can have a system that has fine-grained operation whic= h is governed through a majority vote. The fine grained operation happens d= ay 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 auto= matically implemented but can be overridden if necessary. --=20 Jehan Tremback jehan@altheamesh.com On Tue, Dec 19, 2017, at 7:27 AM, Paul Wouters wrote: > On Dec 19, 2017, at 06:09, Jordi Pailliss=C3=A9 Vilanova wrote: >=20 > > We think that a blockchain provides equivalent security and easier mana= gement when compared to existing systems (PKI-based). >=20 > You think that or hope that? >=20 > > 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 mec= hanism for such situations, but without giving back all control to the RIRs= , because it would be again a standard PKI system. >=20 > You can=E2=80=99t have the blockchain and eat it too. This is the fundame= ntal=20 > problem of anything you stuff in a blockchain. The namecoin =E2=80=9CDNS= =E2=80=9D has=20 > the same problem. >=20 > > In other words, we would like to strike a good tradeoff between the cen= tralization of PKI systems and the complete decentralization of blockchains= . We would love to hear feedback from the community on this topic :) >=20 > If you make any override of the blockchain, the blockchain properties=20 > are nullified and your system is better of not blockchaining at all. >=20 > Paul >=20 > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din From nobody Tue Dec 19 20:47:40 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDB7126B72 for ; Tue, 19 Dec 2017 20:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKl3sUZ407pr for ; Tue, 19 Dec 2017 20:47:37 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80C8127522 for ; Tue, 19 Dec 2017 20:47:36 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3z1j1d2bPkz3DC; Wed, 20 Dec 2017 05:47:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1513745253; bh=lPSZkeUR0ETP2CwqKxdtIHoOH2hE76MW9hfqLuHuErY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ocS8+fcqLOxPof6bKXHk8vGzkM2woRrVreuqU3yrCDvb1nSmLbJp2vREfs9kJDiYc QpYBuxbXpRK39yJqCYaDQsh8DeXZw9aftG8+xM6JnjUPHRtE9k+Bbn+KD2NkbhPtvH EMgMPcqSOt5qO9DyoZvv245hRnXEhDXV7o8SOpkw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id L0pPJwyqdDo5; Wed, 20 Dec 2017 05:47:32 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 20 Dec 2017 05:47:31 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0802370A3FB; Tue, 19 Dec 2017 23:47:30 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0802370A3FB Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E4AFE43A0D56; Tue, 19 Dec 2017 23:47:30 -0500 (EST) Date: Tue, 19 Dec 2017 23:47:29 -0500 (EST) From: Paul Wouters To: Jehan Tremback cc: din@irtf.org In-Reply-To: <1513707634.3934032.1210296976.0AD4B135@webmail.messagingengine.com> Message-ID: References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> <1513707634.3934032.1210296976.0AD4B135@webmail.messagingengine.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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, 20 Dec 2017 04:47:38 -0000 On Tue, 19 Dec 2017, Jehan Tremback wrote: >>> 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. > > 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 nobody Tue Dec 19 22:44:41 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE97126D45 for ; Tue, 19 Dec 2017 22:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ini4sSGeLGxd for ; Tue, 19 Dec 2017 22:44:38 -0800 (PST) Received: from smtp-out-02.aalto.fi (testsmtp.aalto.fi [130.233.228.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75272120227 for ; Tue, 19 Dec 2017 22:44:38 -0800 (PST) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2BA002714C4_A3A06F1B; Wed, 20 Dec 2017 06:45:05 +0000 (GMT) Received: from exng1.org.aalto.fi (exng1.org.aalto.fi [130.233.223.20]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client CN "exng1.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTPS id CC9E62714C2_A3A06F0F; Wed, 20 Dec 2017 06:45:04 +0000 (GMT) Received: from exng2.org.aalto.fi (130.233.223.21) by exng1.org.aalto.fi (130.233.223.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Wed, 20 Dec 2017 08:44:34 +0200 Received: from exng2.org.aalto.fi ([fe80::5989:81ad:a65:2cbf]) by exng2.org.aalto.fi ([fe80::5989:81ad:a65:2cbf%12]) with mapi id 15.01.0669.032; Wed, 20 Dec 2017 08:44:34 +0200 From: Nikander Pekka To: =?iso-8859-1?Q?Jordi_Pailliss=E9_Vilanova?= CC: "din@irtf.org" Thread-Topic: [Din] Blockchain protocols Thread-Index: AQHTeN/tybbTEJb7UkWa1dlqu9Z+rKNLqLWA Date: Wed, 20 Dec 2017 06:44:34 +0000 Message-ID: References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> <20171219153425.oarg3egwox27bqbh@nic.fr> <21900_1513698143_5A39335E_21900_205_1_f041f78a-c337-ac58-38a2-d24646f2a2ea@ac.upc.edu> In-Reply-To: <21900_1513698143_5A39335E_21900_205_1_f041f78a-c337-ac58-38a2-d24646f2a2ea@ac.upc.edu> Accept-Language: en-GB, fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [130.233.0.5] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SASI-RCODE: 200 Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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, 20 Dec 2017 06:44:40 -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 ord= er to remove some power to CAs and central authorities. As Stephane said, i= t's not necessarily a binary decision. Well, depending on your trust model and business requirements, it may no lo= nger 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 di= stributed, may still make pretty much sense, though. IMHO it is important to make distinction between the "distributed ledger" a= nd "PoW-based consensus" properties in DLTs. AFAICS, the very idea of a di= stributed ledger is much more applicable in general than the idea of PoW-ba= sed 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 nobody Tue Dec 19 22:47:48 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60787126D45 for ; Tue, 19 Dec 2017 22:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IV1ErfdhDVuM for ; Tue, 19 Dec 2017 22:47:46 -0800 (PST) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6395120227 for ; Tue, 19 Dec 2017 22:47:45 -0800 (PST) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 362C7115ADE_A3A07ADB; Wed, 20 Dec 2017 06:48:13 +0000 (GMT) Received: from exng2.org.aalto.fi (exng2.org.aalto.fi [130.233.223.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "exng2.org.aalto.fi", Issuer "org.aalto.fi RootCA" (not verified)) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTPS id D81991156E0_A3A07ACF; Wed, 20 Dec 2017 06:48:12 +0000 (GMT) Received: from exng6.org.aalto.fi (130.233.223.25) by exng2.org.aalto.fi (130.233.223.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 20 Dec 2017 08:47:42 +0200 Received: from exng2.org.aalto.fi (130.233.223.21) by exng6.org.aalto.fi (130.233.223.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 20 Dec 2017 08:47:42 +0200 Received: from exng2.org.aalto.fi ([fe80::5989:81ad:a65:2cbf]) by exng2.org.aalto.fi ([fe80::5989:81ad:a65:2cbf%12]) with mapi id 15.01.0669.032; Wed, 20 Dec 2017 08:47:42 +0200 From: Nikander Pekka To: Jehan Tremback CC: "din@irtf.org" Thread-Topic: [Din] Blockchain protocols Thread-Index: AQHTePYPybbTEJb7UkWa1dlqu9Z+rKNLqWmA Date: Wed, 20 Dec 2017 06:47:42 +0000 Message-ID: <82567DCC-A2C1-4124-82CA-8DEF175B3B5A@aalto.fi> References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> <23534_1513707642_5A39587A_23534_43_1_1513707634.3934032.1210296976.0AD4B135@webmail.messagingengine.com> In-Reply-To: <23534_1513707642_5A39587A_23534_43_1_1513707634.3934032.1210296976.0AD4B135@webmail.messagingengine.com> Accept-Language: en-GB, fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [130.233.0.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <76D8BF93666CF440A29B04C87C1B1FB1@aalto.fi> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SASI-RCODE: 200 Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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, 20 Dec 2017 06:47:47 -0000 >>> In other words, we would like to strike a good tradeoff between the cen= tralization of PKI systems and the complete decentralization of blockchains= . We would love to hear feedback from the community on this topic :) >>=20 >> If you make any override of the blockchain, the blockchain properties=20 >> are nullified and your system is better of not blockchaining at all. >=20 > 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 wh= ich 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 nee= ds to be changed. It would be too expensive to have a majority vote on ever= y single address allocation, so we have a set of general rules which are au= tomatically implemented but can be overridden if necessary. IMNSHO, relying on hard forks and majority vote chaos on every vote is a pr= etty lousy governance model for a mission critical IT system. =20 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 ma= y need to live with hard forks and transition periods that last days until = the dust settles on each fork. --Pekka From nobody Wed Dec 20 01:03:51 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5EF12D864 for ; Wed, 20 Dec 2017 01:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_S8Zlh4EApw for ; Wed, 20 Dec 2017 01:03:43 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 82C8012D88A for ; Wed, 20 Dec 2017 01:03:42 -0800 (PST) Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vBK93b6N012705; Wed, 20 Dec 2017 10:03:37 +0100 Received: from [147.83.35.239] (dync-35-239.ac.upc.es [147.83.35.239]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id AFAE85C9; Wed, 20 Dec 2017 10:03:31 +0100 (CET) To: Nikander Pekka , Jehan Tremback Cc: "din@irtf.org" References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> <23534_1513707642_5A39587A_23534_43_1_1513707634.3934032.1210296976.0AD4B135@webmail.messagingengine.com> <82567DCC-A2C1-4124-82CA-8DEF175B3B5A@aalto.fi> From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: <11242d50-0cd8-4e0b-33c6-021a23834c47@ac.upc.edu> Date: Wed, 20 Dec 2017 10:03:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <82567DCC-A2C1-4124-82CA-8DEF175B3B5A@aalto.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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, 20 Dec 2017 09:03:48 -0000 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 El 20/12/17 a les 07:47, Nikander Pekka ha escrit: >>>> 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. >> 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. > 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 > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din From nobody Wed Dec 20 01:14:48 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EB912D962 for ; Wed, 20 Dec 2017 01:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faxk_gdM6T11 for ; Wed, 20 Dec 2017 01:14:44 -0800 (PST) Received: from mta1.cl.cam.ac.uk (mta1.cl.cam.ac.uk [128.232.25.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FAC12D960 for ; Wed, 20 Dec 2017 01:14:44 -0800 (PST) Received: from ely.cl.cam.ac.uk ([128.232.64.213]) by mta1.cl.cam.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1eRaSX-0006no-JI; Wed, 20 Dec 2017 09:14:41 +0000 From: Jon Crowcroft To: Nikander Pekka cc: =?iso-8859-1?Q?Jordi_Pailliss=E9_Vilanova?= , "din@irtf.org" , Jon Crowcroft In-reply-to: References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> <20171219153425.oarg3egwox27bqbh@nic.fr> <21900_1513698143_5A39335E_21900_205_1_f041f78a-c337-ac58-38a2-d24646f2a2ea@ac.upc.edu> Comments: In-reply-to Nikander Pekka message dated "Wed, 20 Dec 2017 06:44:34 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15312.1513761278.1@ely.cl.cam.ac.uk> Date: Wed, 20 Dec 2017 09:14:38 +0000 Message-Id: Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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, 20 Dec 2017 09:14:46 -0000 folks may be interested in some legal-viewpoint papers on blockchain - see http://js573.user.srcf.net/mccrc/events/2017-symposium-blockchain/ > > 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. > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din > From nobody Wed Dec 20 07:20:01 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D86124D85 for ; Wed, 20 Dec 2017 07:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbDwMB9kGx1A for ; Wed, 20 Dec 2017 07:19:57 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF67126CD6 for ; Wed, 20 Dec 2017 07:19:57 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 20 Dec 2017 07:19:55 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 20 Dec 2017 07:19:55 -0800 From: Paul Hoffman To: "din@irtf.org" Thread-Topic: [Ext] Re: [Din] Blockchain protocols Thread-Index: AQHTeV4HCo7AdWPdB0WLWgS1GbsZH6NMeUsAgABmDYA= Date: Wed, 20 Dec 2017 15:19:54 +0000 Message-ID: References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <355A19DB-E505-4DBB-8129-DEE256E37063@nohats.ca> <20171219153425.oarg3egwox27bqbh@nic.fr> <21900_1513698143_5A39335E_21900_205_1_f041f78a-c337-ac58-38a2-d24646f2a2ea@ac.upc.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Din] [Ext] Re: Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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, 20 Dec 2017 15:20:00 -0000 On Dec 20, 2017, at 1:14 AM, Jon Crowcroft wro= te: > folks may be interested in some legal-viewpoint papers on blockchain - se= e > 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 nobody Thu Dec 21 15:33:22 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28628126E01 for ; Thu, 21 Dec 2017 15:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMjktToGwE57 for ; Thu, 21 Dec 2017 15:33:20 -0800 (PST) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A87120713 for ; Thu, 21 Dec 2017 15:33:20 -0800 (PST) Received: by mail-pl0-x22d.google.com with SMTP id 62so10458892pld.7 for ; Thu, 21 Dec 2017 15:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=mxuXKN3jetHE0ooEwqD/C7zNGoGo4TG+mYSOU79g8fA=; b=m3s8JpbzoxsdKXOdx5ooqiOHT1hOP6rMduE01NXgNRmgRf0QUpOOy18tNWB3WdhmmP VIlcj0du9l/J11JMUUv3D52eha4eG3K0zeZ+FsZMZMJ6zst71FeSu0TMVHI2oKcDtSFX Ll9TUMz7aS9RjDKOa2AVMCt1t8WyNu93zckCjzSLYLHHiGYwph2fKS/vhOOlFCFW54+F 9FMhQy30J5+xRDwyRA18Xui6OLcS2+sNFc6DkvTod8tSiyF6nPEDrfSYKW8K5pF6gD0P VmkJqueS58d7x2A8Uwh41o9VzWP084jlU6e7/oj+fKQsFIii8fXsF1v5aGisg/lJLrb9 jvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=mxuXKN3jetHE0ooEwqD/C7zNGoGo4TG+mYSOU79g8fA=; b=KlTxnEwQkTRTnw0Xg8nUyuYrLzbEeFBPa6FLCVV70FOwFCPX8h2An4n/LF3/I2WfiZ cJ47SSLb8LyxE+2JcmN4XXQ0fIpPHiRSp8FfyiTt+rcMnzVni4f7WBDAwUZbYJe56gXm HXp+SUaMSomCc8Xau8lpWPZvUWfRH6+jZp+J42XIPWiqxfioJIE+kANw+C9sWDLTV9Uz qKMC7YiYtZO5uEdfFjrwxoLZfA8HUcYuBQt73JCUTXDAjBA4EuPoMkZb3VSQ9X764yRN 3ZQyhrGrUny0RYHeg4Ubmfon+uw/HaE2IJFK8WSgIhiFu1skDBdDtx8Df6pPOmOFfW1a ZvWA== X-Gm-Message-State: AKGB3mIrBbDNsbtivXrxfExptYxWZgC5ClZe0i6sJ69Znft0Qq9/hpEi i/Vy5nXYopbVVRrvbrK9JwrkkNA= X-Google-Smtp-Source: ACJfBotWZFNqqeg51kADrcXsVFKQ1ENPlFogqPwSecamFdrNYzz5nM9YpbPwW5MshEYADNs7l1WcOg== X-Received: by 10.159.252.197 with SMTP id o5mr12142553pls.46.1513899199699; Thu, 21 Dec 2017 15:33:19 -0800 (PST) Received: from aspen.local (198-163-39-225-radius.dynamic.acsalaska.net. [198.163.39.225]) by smtp.gmail.com with ESMTPSA id u68sm40299023pfu.17.2017.12.21.15.33.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Dec 2017 15:33:19 -0800 (PST) To: din@irtf.org References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> From: Melinda Shore Message-ID: Date: Thu, 21 Dec 2017 14:33:16 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="j17K4AAp0qC1VOQVOshHaxmIIc25I3AfE" Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Thu, 21 Dec 2017 23:33:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j17K4AAp0qC1VOQVOshHaxmIIc25I3AfE Content-Type: multipart/mixed; boundary="J7v9vA8LQfpsf81AgvIfMGHQ4XjnNuT0f"; protected-headers="v1" From: Melinda Shore To: din@irtf.org Message-ID: Subject: Re: [Din] Blockchain protocols References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> In-Reply-To: --J7v9vA8LQfpsf81AgvIfMGHQ4XjnNuT0f Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/19/17 2:09 AM, Jordi Pailliss=C3=A9 Vilanova wrote: > 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).=20 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 --=20 Software longa, hardware brevis PGP fingerprint: 795A 714B CD08 F996 AEFE AB36 FE18 57E9 6B9D A293 --J7v9vA8LQfpsf81AgvIfMGHQ4XjnNuT0f-- --j17K4AAp0qC1VOQVOshHaxmIIc25I3AfE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaPES9AAoJELiGRpM6HoEucFgQAJi2wvAt35RzPXez7N9dJaRw ZasqymN5jLfGt8mFc6QN9erPM3oEka/Qs5+04EYz6mhlkpoFG07hMs1n0saOCKRs J39+CUJLZcdRWUvHvLn8/wXO5tZKb9osMANB102I7RBzum9e9n1NlajkkUKv2Ynk yPMXWx3TwJej9M8OF7Z9IU/oXc7AzDslkJ5sFwxHg+F6Fnp0mD9YHhGik8gHNctn Y5zBFNHm0tQEZMG9ayuJYM4s0AhIj0naG1G2vuwlq7erLGeLURGlBMTOuS8X00Ae FjJwwQ+x3PLXxwjoXn1JyX+DPq7RYC5zmtAmvl8WEeY01oFiYjtUwmbrGSvMuZ5z IGSThPwctViD5AK9bvYJp0tisgf2Sbi8Ya/4bZCneEs0ytq98xyjNQkW68DGmOnY a3htWztZroGgmDKT6wSYgNuTCWWowTV8TtOXfm8AtSi+P10TQMwJKNo7sxhy7XiK G5mjCDGpOBpwM6GWxMYJ2Q1rRbI5+6Xu2QeNSQxQt8BbCBSh3yAN+o2mNyhRC9Cq ApnCDHbLVjh8lHJIVDfDSvh5nikxfLoOjwkQfxVwHnskKN4SUqdsNJ9LSXUv69ZB 2CtOSusoA0pSAzfKWuFlO+gxd7ySgQiEjlP2Ej0p1fxehIhAcwwtsW/82eyANvCn xyJknL0ClPoZSwhDYiyh =il4c -----END PGP SIGNATURE----- --j17K4AAp0qC1VOQVOshHaxmIIc25I3AfE-- From nobody Fri Dec 22 04:57:37 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946B912DA4A for ; Fri, 22 Dec 2017 04:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyvY2EkXOM5N for ; Fri, 22 Dec 2017 04:57:32 -0800 (PST) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9849412DA51 for ; Fri, 22 Dec 2017 04:57:31 -0800 (PST) Received: from correu-2.ac.upc.es (correu-2.ac.upc.es [147.83.30.92]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id vBMCvUcK021408; Fri, 22 Dec 2017 13:57:30 +0100 Received: from [192.168.1.4] (43.red-88-18-119.staticip.rima-tde.net [88.18.119.43]) by correu-2.ac.upc.es (Postfix) with ESMTPSA id 7EB14323; Fri, 22 Dec 2017 13:57:24 +0100 (CET) To: Melinda Shore , din@irtf.org References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> Cc: Albert Cabellos From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= Message-ID: <2c00a58b-5d29-0e66-4538-3da617911813@ac.upc.edu> Date: Fri, 22 Dec 2017 13:57:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------23B4DB49A722353CE6D487DF" Content-Language: en-US Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Fri, 22 Dec 2017 12:57:36 -0000 This is a multi-part message in MIME format. --------------23B4DB49A722353CE6D487DF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 El 22/12/17 a les 00:33, Melinda Shore ha escrit: > On 12/19/17 2:09 AM, Jordi Paillissé Vilanova wrote: >> 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). > 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 > > > > _______________________________________________ > Din mailing list > Din@irtf.org > https://www.irtf.org/mailman/listinfo/din --------------23B4DB49A722353CE6D487DF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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


El 22/12/17 a les 00:33, Melinda Shore ha escrit:
On 12/19/17 2:09 AM, Jordi Paillissé Vilanova wrote:

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). 

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




_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mailman/listinfo/din

--------------23B4DB49A722353CE6D487DF-- From nobody Fri Dec 22 07:01:43 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D3612EAEE for ; Fri, 22 Dec 2017 07:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jERmOgttZbba for ; Fri, 22 Dec 2017 07:01:36 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2DCD12EAEA for ; Fri, 22 Dec 2017 07:01:36 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id w1so10281579ybe.10 for ; Fri, 22 Dec 2017 07:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0sfVTD/VZ/wG2/Jqx7GMsHzXB77JDz1YIWyFAb4wRns=; b=dpGBWgO+6BaGZj/lP7BcZ/DA2+gLcnoGNbdKz8/NenzHFQ02VXzia5/+LXwwdpWOKj sw3bHOKy02MlfYh1Cbl//sGhwXapFJ1pjKa/3o09BxixbD6DqBiWLenFxuqvMDcHwB6J f+1uxG+wLeQGGfng/LCeReo+I6IwScSHtPAiWJo4isy+NRH4gnjblul+PMzipvyEaiqz 5zJpzIdswJUbjYi6jtIpYnhYCnWbRD8nB56mfz4Ws/852qIgLIV2Hao6y9xXf77NfMq9 NNo5qD82fRsPOhFaUqr9qYiFKqscbPAj+ExEUUrvh0B4TOH1EobMpf3r1LgKbF1wc7E2 F9wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0sfVTD/VZ/wG2/Jqx7GMsHzXB77JDz1YIWyFAb4wRns=; b=n3i+gX0x+yeB17ljOtTClq916PxIzY/KCvQhclKBguUC4uEk1H+tfp0IhsDNNH8/W+ q3lnrLTy0K5+EUKSKvoEVG+ttcGJX5dlGXs8H14eVull/Dpo2e8UclM+k7V2wN4NaWR1 BRJFhI8pxTGM9/NrftKOUqG9YpDD3ra+D2EI1fbE8gUefUTphzI3DI7w9p4rX0NvSEHh IxWsPqc4kOanR780Vk0KB6wLdn9CZfrjBO3X3unpjWqSY1wxkY5SRwTau+wz/8eiF03i i/bPVNCR8GKUfEdKgxh9BTVI8G9Xec1qubHuWFouSDYToNSgLT5bDOwXIQ+DWqwNY7H8 zlLQ== X-Gm-Message-State: AKGB3mILWDmHudVRo6t2IwOy1pfaAMY4yHfnO/rX/QxU3vuL2IwMDT82 Rg3LKhPBNxByfcjLhZUc5fG96ZZ/zRr7by9OA327AQ== X-Google-Smtp-Source: ACJfBos4RsSk0BLuTzobhVFAiEly+7UDekaol7sZ4Tj7OIfppFfDoLCS7ku1O6pIVoEfoXWF4ypbxaRO5E3EaQZeC9Y= X-Received: by 10.37.191.202 with SMTP id q10mr9122387ybm.145.1513954895364; Fri, 22 Dec 2017 07:01:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.183.142 with HTTP; Fri, 22 Dec 2017 07:01:34 -0800 (PST) In-Reply-To: <2c00a58b-5d29-0e66-4538-3da617911813@ac.upc.edu> References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <2c00a58b-5d29-0e66-4538-3da617911813@ac.upc.edu> From: Albert Cabellos Date: Fri, 22 Dec 2017 16:01:34 +0100 Message-ID: To: =?UTF-8?Q?Jordi_Pailliss=C3=A9_Vilanova?= Cc: Melinda Shore , din@irtf.org, Albert Cabellos Content-Type: multipart/alternative; boundary="089e08265ef4be8f4d0560ef17e5" Archived-At: Subject: Re: [Din] Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Fri, 22 Dec 2017 15:01:41 -0000 --089e08265ef4be8f4d0560ef17e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all On Fri, Dec 22, 2017 at 1:57 PM, Jordi Pailliss=C3=A9 Vilanova wrote: > True, monopolies are a drawback for PoS, but I think we can overcome it. > For example, in Algorand (thanks for the pointer!) security is guarantee= d > 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 :) > 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 > > El 22/12/17 a les 00:33, Melinda Shore ha escrit: > > On 12/19/17 2:09 AM, Jordi Pailliss=C3=A9 Vilanova wrote: > > 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). > > 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 > > > > > _______________________________________________ > Din mailing listDin@irtf.orghttps://www.irtf.org/mailman/listinfo/din > > > --089e08265ef4be8f4d0560ef17e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all



On Fri, Dec 22, 2017 at 1:57 PM, Jordi = Pailliss=C3=A9 Vilanova <jordip@ac.upc.edu> wrote:
=20 =20 =20

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


Regarding monopolies, we can des= ign 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 blo= ck) to mitigate this. Actually this approach has to be followed in IPv6, ot= herwise the huge unallocated IPv6 address space results in a monopoly. But = overall I agree, monopolies are a drawback.

With c= ertificates, CAs are the monopolies :)=C2=A0

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


El 22/12/17 a les = 00:33, Melinda Shore ha escrit:
On 12/19/17 2:09 AM, Jordi Pailliss=C3=A9 Vilanova wrote:

Regarding your first question, you raise a very valid point. W=
e think
that a blockchain provides equivalent security and easier management
when compared to existing systems (PKI-based).=20

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




_______________________________________________
Din mailing list
Din@irtf.org
https://www.irtf.org/mai=
lman/listinfo/din


--089e08265ef4be8f4d0560ef17e5-- From nobody Fri Dec 22 07:58:50 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3178312D93E for ; Fri, 22 Dec 2017 07:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H2r3xx_tgaQ for ; Fri, 22 Dec 2017 07:58:47 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D160612D892 for ; Fri, 22 Dec 2017 07:58:47 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 22 Dec 2017 07:58:46 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Fri, 22 Dec 2017 07:58:46 -0800 From: Paul Hoffman To: Albert Cabellos CC: "din@irtf.org" Thread-Topic: [Ext] Re: [Din] Blockchain protocols Thread-Index: AQHTeBooxGeB5FE5ZUKaGYSxrEPpY6NLCYuAgAP0gwCAAOCrgIAAIrIAgAAP+QA= Date: Fri, 22 Dec 2017 15:58:45 +0000 Message-ID: References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <2c00a58b-5d29-0e66-4538-3da617911813@ac.upc.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <134A5C239B200C41B6166DD84CA015D3@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Din] [Ext] Re: Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Fri, 22 Dec 2017 15:58:49 -0000 On Dec 22, 2017, at 7:01 AM, Albert Cabellos wr= ote: > With certificates, CAs are the monopolies :)=20 I see the smiley here, but I want to emphasize that this exactly the opposi= te of the truth. The relying party software (primarily the browsers) have e= xplicit policies that no CA or small group of CAs will ever become a monopo= ly. The policies are defined and updated in public. Compare this to the har= d-to-find algorithms and assumptions in most blockchains. --Paul Hoffman= From nobody Thu Dec 28 10:07:04 2017 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4753512D965 for ; Thu, 28 Dec 2017 10:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp2QvYxeFQGl for ; Thu, 28 Dec 2017 10:07:00 -0800 (PST) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F2A12D86E for ; Thu, 28 Dec 2017 10:07:00 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id s10so228806ybl.7 for ; Thu, 28 Dec 2017 10:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F33A0Olcg1HZadnwnL0PqiOScZ6Ak9zaotXL0Ay9EIA=; b=YX2B+/EDG1PAafw0IAdr1SeMHgVDFuq6hdpU4lYB1kYJsV5MSp5v2ZLsArj+AMSi6l xbx3tGFWQrrrIhzgbSZH92CwF4zP+P2mpnjaHMSasilYwMwL82Dbqe9sPQlxJ5oOBXna peXB4cNkp7O3seQOLO20FHnnsJnyD+D5tRH5RnoCSu2V0xUt59/oZ+CPGQrhjtg5/Dgj HXhntv2aCJVBAHSVoOqHwkeF3sAmpKu7wBQqf9BcAsVl5YE5dykUsk1Uv/lNtYjeJpc4 lDLKtRxwSRP+9U6opAU882oeJ/ZP4HlLg5SK2TnT/srzWE6v3R+yimSrqHFuYqbZ6be5 lcUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F33A0Olcg1HZadnwnL0PqiOScZ6Ak9zaotXL0Ay9EIA=; b=GRDzgL16luo8lYwN7CubxTuDUniMLtudFnn+qINIa8U1AY3cyRzUdVn5l/bOD+L5W2 SFv7E9I+Ln2VU70b3OSS1nyeyObse0HOQ5HHYXkjElnwGmCMDLmPWaYftHBwLrrKqrfH G38gLH6t76zB3nNb/zU1310TIp+a95TCgFTSeBGStancWj7OCPD4G2DxWkDIFNF9aopa P6WqWpyOZyg4CznzuENo5u6pWZDyhmfwy0rjSO4KF/YX2wAFkVqAEKk+eOtp4y0x9t/8 DrU4snpwZhc8EU4Yx6sRVuv5gXf0SRFmiQ+a798VzOQ9BFE1BAjfYWJAAKKwfG44NnNO u+TA== X-Gm-Message-State: AKGB3mIBQ3LZ8sfxm7+DLcAynOPn6S8FDNSo7i+UMy+dsxIf6j5vM0fU JJpNngzYeKINQm4eXjyjieyq/zztSg3h/mdze/8ajq6u X-Google-Smtp-Source: ACJfBoufLtCRqCaEY6UeQfOh1p1g9ZOgd7RcoHweQ3RoWkwO3WrUt3D+ChFIJundDkKVMqc0fmAD8DvqpOaglqOrwQw= X-Received: by 10.37.185.73 with SMTP id s9mr3624172ybm.435.1514484419405; Thu, 28 Dec 2017 10:06:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.183.142 with HTTP; Thu, 28 Dec 2017 10:06:58 -0800 (PST) In-Reply-To: References: <73fb424c-261f-8d6d-23d6-69cd4cdde9a3@bartschnet.de> <20171218160612.eu7glh7hxkvssqn3@nic.fr> <2c00a58b-5d29-0e66-4538-3da617911813@ac.upc.edu> From: Albert Cabellos Date: Thu, 28 Dec 2017 19:06:58 +0100 Message-ID: To: Paul Hoffman Cc: "din@irtf.org" Content-Type: multipart/alternative; boundary="089e08266834d62cd305616a61cf" Archived-At: Subject: Re: [Din] [Ext] Re: Blockchain protocols X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.22 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: Thu, 28 Dec 2017 18:07:02 -0000 --089e08266834d62cd305616a61cf Content-Type: text/plain; charset="UTF-8" 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 wrote: > On Dec 22, 2017, at 7:01 AM, Albert Cabellos > wrote: > > 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 --089e08266834d62cd305616a61cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the clarificati= on and sorry for my lack of formality.

What the blockchain consensus al= gorithms brings is a 'knob' to adjust where the trust is. How to ad= just the 'knob' is debatable and provides advantages and disadvanta= ges.=C2=A0

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

On Fri, Dec 22, 2017 a= t 4:58 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:=
On Dec 22, 2017, at 7:0= 1 AM, Albert Cabellos <albe= rt.cabellos@gmail.com> wrote:
> 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

--089e08266834d62cd305616a61cf--