From nobody Tue Aug 8 05:03:21 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8361321BD for ; Tue, 8 Aug 2017 05:03:19 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 RFVTPAQsnXB3 for ; Tue, 8 Aug 2017 05:03:17 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 2819D1321B7 for ; Tue, 8 Aug 2017 05:03:17 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id f9so13590262uaf.4 for ; Tue, 08 Aug 2017 05:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=8I9/GmdNiQIkYkmqbby8k2tOl5XDkdQOaTkqPoian7A=; b=hC4V1gHllWmLhjJ7RmOKEq8BNnsHb9E5Z4gH0stD4nyL3HZzmIucvnnWfcao48EBg3 apkkjjPmBb+v/4p+AeGbNDv5VGS+bp+aAkr4Ulp2uffhHqAyLQMY7QRi5OHyXKFBiUpN njaDABa9mpstXCKUFAeFq5i2VXa226k2fGImE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8I9/GmdNiQIkYkmqbby8k2tOl5XDkdQOaTkqPoian7A=; b=eOtAwRKYnSQWqbKGg1gqDbLmtIn4gEoKlJOxFBqLbtKNPOQWE4a/SLSM7HXCblRtaJ 4vTeJ24rZWEKbdrTXaBVfymnHWNcnIcR7eSJan8TIIyxbPrZ0ZyvWq4rF63L3QZqPK1p Y+PiN2ewxzZQKLvaeeq0SWwDvRsIA6Qgp8TCE3u682mF7nV9gYby1qsBh5syg5jMqf4H CnPM71Glmt+NdMQKRbOzq+bUisITWcGHQU9G+AWayX5qRvzkOR467HEJoImn35Cey/Sp 767K+6GD9LMlI1IyU57f9EqRKdg4zqezN6e35TNKC7Vi5R3ExOlBfbiesmtCI7pYEn0k EbQg== X-Gm-Message-State: AHYfb5jnYMd0Hqn2whFH2pynIZDvOgZwrCBHMH1iIlyw2EFPnxnU14fl dWlp1r3fWCWZQEg/DwwzhR+5kR75/XjXIZpcsw== X-Received: by 10.159.38.7 with SMTP id 7mr3081507uag.148.1502193796019; Tue, 08 Aug 2017 05:03:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.144.11 with HTTP; Tue, 8 Aug 2017 05:03:15 -0700 (PDT) From: Adrian Hope-Bailie Date: Tue, 8 Aug 2017 14:03:15 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1137256298b96905563cbffa" Archived-At: Subject: [Ledger] AGENDA - Interledger Community Call - 9 August - 3pm UTC X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 12:03:19 -0000 --001a1137256298b96905563cbffa Content-Type: text/plain; charset="UTF-8" There has been some good discussion, following the proposal to define a binary RPC protocol, about the ILP packet definitions and layering in general. There are a number of proposals in the form of PRs on the RFC repo: https://github.com/interledger/rfcs/pull/263 https://github.com/interledger/rfcs/pull/264 https://github.com/interledger/rfcs/pull/266 Discussion of these will likely take up the bulk of Wednesday's call but please forward any other topics to the list and we'll pick them up. To join or start the meeting, go to: https://bluejeans.com/795795755 (Also works on iPhone or Android phone) To connect directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 795795755 -or- use the pairing code Dial-in numbers: http://bluejeans.com/numbers (use Meeting ID: 795795755) --001a1137256298b96905563cbffa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There has been some good discussion, following t= he proposal to define a binary RPC protocol, about the ILP packet definitio= ns and layering in general.

There are a number of proposals in= the form of PRs on the RFC repo:

https://github.com/interledger/rfcs/pull/263
= https://github.com= /interledger/rfcs/pull/264
https://github.com/interledger/rfcs/pull/266

Discussion of these will likely take up the bulk of Wednesday's call= but please forward any other topics to the list and we'll pick them up= .

To join or start the meeting, go to:
(Also works on iPhone or Android phone)
<= br>
To connect directly from a room system?
1) Dial: 19= 9.48.152.152 or bjn.vc
2) Enter Meeting ID: 795795755 -or- use the pairing code
Dial-in numbers: http://bluejeans.com/numbers (use Meeting ID: 795795755)<= /div>
--001a1137256298b96905563cbffa-- From nobody Tue Aug 8 17:46:34 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2C31321DA for ; Tue, 8 Aug 2017 17:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ripple.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 0cQ39ujaeai9 for ; Tue, 8 Aug 2017 17:46:31 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 52FC81321B1 for ; Tue, 8 Aug 2017 17:46:24 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id k71so18487244wrc.2 for ; Tue, 08 Aug 2017 17:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=u8aDWZrSL8/qrA4S03shSXtukNakVEEresbIjdzH/Do=; b=Q/fq7NVpUaTCKnLbo8/xSrX6JyZHr6x3Y50HK2vtQy446M1RA4HOoB9xnhKk1pJYfC 9TQmMafHVF3dcMlMm8U5IKFIkC2/3JZZqkFv0m4mKrgVAb7WivLboBpTKAWG+RQOtLJj LNx4gQYsCdIgoQ1b7PdK1PGp20jbXfiYRNv78= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=u8aDWZrSL8/qrA4S03shSXtukNakVEEresbIjdzH/Do=; b=OKeRzb9r4uZIKVfE1fkHS1TbURI7oF5P08524OAQuO+a4/uPtafBQ7K7BLdGdfmnib KDldPCMcc7PAiymn80IQCb7u6YbIekNgKl2r6dh6eZOETRtri/OZsFrx+Bo1Wv6BHvn1 FHOW8mhWsAZcIUTWSuGgLc3d0TzXdjCvAcWSNV/DL5Eq1rQK43sMVys0eRGtlIEk+FxY pudr6J+SwYUlebVQgAk4JNqAox7cM5xa5m6idZpPnbKUb9gt+Gb3SnZNyM0LaMQxBGME EvyYN6lgCwwoLui2qReuTt+lHBhm40eTXA8j4DP9r6fNBNJKWerseV1ZC2vNgx2bVK88 zbsw== X-Gm-Message-State: AHYfb5gF2CpmHflCfRaJBlZvbdxOoiEJk5dNxMs7rzcujEhyaFfIlPV/ i4cYwxXxv2QDbXgnV2O5/EHBbHYA6dAY X-Received: by 10.223.166.7 with SMTP id k7mr4703152wrc.34.1502239582617; Tue, 08 Aug 2017 17:46:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Evan Schwartz Date: Wed, 09 Aug 2017 00:46:11 +0000 Message-ID: To: Adrian Hope-Bailie , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="f403045cf6a8b095c30556476893" Archived-At: Subject: Re: [Ledger] AGENDA - Interledger Community Call - 9 August - 3pm UTC X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 00:46:34 -0000 --f403045cf6a8b095c30556476893 Content-Type: text/plain; charset="UTF-8" The discussion we've been having over the past couple of days has been one of the most interesting I've been involved in since starting to work on this project. If you can join this call I'd highly recommend it. On Tue, Aug 8, 2017, 2:03 PM Adrian Hope-Bailie wrote: > There has been some good discussion, following the proposal to define a > binary RPC protocol, about the ILP packet definitions and layering in > general. > > There are a number of proposals in the form of PRs on the RFC repo: > > https://github.com/interledger/rfcs/pull/263 > https://github.com/interledger/rfcs/pull/264 > https://github.com/interledger/rfcs/pull/266 > > Discussion of these will likely take up the bulk of Wednesday's call but > please forward any other topics to the list and we'll pick them up. > > To join or start the meeting, go to: > https://bluejeans.com/795795755 > (Also works on iPhone or Android phone) > > To connect directly from a room system? > 1) Dial: 199.48.152.152 or bjn.vc > 2) Enter Meeting ID: 795795755 -or- use the pairing code > > Dial-in numbers: http://bluejeans.com/numbers (use Meeting ID: 795795755) > _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger > -- Evan Schwartz Software Engineer Managing Director of Ripple Luxembourg --f403045cf6a8b095c30556476893 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The discussion we've been having over the past couple of= days has been one of the most interesting I've been involved in since = starting to work on this project. If you can join this call I'd highly = recommend it.


On Tue, Aug 8, 2017, 2:03 P= M Adrian Hope-Bailie <adrian@ho= pebailie.com> wrote:
There has been some good discussion, following the prop= osal to define a binary RPC protocol, about the ILP packet definitions and = layering in general.

There are a number of proposals in the fo= rm of PRs on the RFC repo:

https://github.com/interledger/rfcs/pull/= 263
https://github.com/interledger/rfcs/pull/264
https://git= hub.com/interledger/rfcs/pull/266

Discussion of these will= likely take up the bulk of Wednesday's call but please forward any oth= er topics to the list and we'll pick them up.

To join or st= art the meeting, go to:
(Also wo= rks on iPhone or Android phone)

To connect directl= y from a room system?
1) Dial: 199.48.152.152 or bjn.vc
2) Enter Meeting ID: 79579= 5755 -or- use the pairing code

Dial-in numbers: http://bluejeans.c= om/numbers (use Meeting ID: 795795755)
_______________________________________________
Ledger mailing list
Ledger@ietf.org https://www.ietf.org/mailman/listinfo/ledger
--

Evan Schwartz

Sof= tware Engineer
Managing Director of Ripple Luxemb= ourg
--f403045cf6a8b095c30556476893-- From dimi@ascribe.io Thu Aug 10 01:55:11 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9AC13239A for ; Thu, 10 Aug 2017 01:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ascribe.io 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 r8o6ea0K0rPV for ; Thu, 10 Aug 2017 01:55:09 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 C01E5132660 for ; Thu, 10 Aug 2017 01:55:09 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id l64so365336pge.5 for ; Thu, 10 Aug 2017 01:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ascribe.io; s=google; h=sender:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wo/fetQts3SHudMa2z8bBzJ+oV7aW5jytBdnRJkBblI=; b=wSOJhrEmjCeV38xul2CiVRPCtCnBWKk+cb4bpgxXjw5fXPBr60O6oJjp68abY2K+Tr QRRp6xklTFK9+7z/CNNgptbGh20z94+Vq4KBCmW+brkPZPmy7/S8XTP8Q8gfywRo9jZv yeC/dx6rngXoYzrq1/vJdfPjRV6g7Qj9qYQKg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wo/fetQts3SHudMa2z8bBzJ+oV7aW5jytBdnRJkBblI=; b=FfC/ZPbgUEBYFWf/3bNUtmelyB6DEtkF6w/GluEyDYq718JF6RF1ZMU5ZK+GdXeumC 4FKX7I29YSYgVCaVdR7I69GhnVzG1xY2XiaHUU5470YHhwNlMbdkANCe0T9vc9KLlJyy 2UUuT4219FKFfl8JL9M+/uNMEtO4tQsHGrDkegGBVNjlpyoDNb+298EyI05C9AuCgJ9e /E1XUpf6vci0ah4tCQfTNBXsneNQ7ZemJN7BrAO0n0wBQC+oawUpOxV932Trw5XICP7q JuWzeiiQr6JaWzTnP11Y2OyItxNMKCnEvZrMtrNW4KFicD36+wFP6DvnVQwE8j9oE9YC iBPg== X-Gm-Message-State: AHYfb5h/HkgKdgrG9mZ6X1SXv7n1Uwfq85xdXrZyuIGMQjEF5Ft2RuaB UvYvhDQ4b+n6j9JvMvA= X-Received: by 10.99.96.197 with SMTP id u188mr10374055pgb.340.1502355308772; Thu, 10 Aug 2017 01:55:08 -0700 (PDT) Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com. [74.125.83.49]) by smtp.gmail.com with ESMTPSA id q124sm7916464pga.8.2017.08.10.01.55.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 01:55:07 -0700 (PDT) Sender: Dimi De Jonghe Received: by mail-pg0-f49.google.com with SMTP id v77so464272pgb.3 for ; Thu, 10 Aug 2017 01:55:06 -0700 (PDT) X-Received: by 10.84.217.208 with SMTP id d16mr12386478plj.269.1502355306549; Thu, 10 Aug 2017 01:55:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.14 with HTTP; Thu, 10 Aug 2017 01:55:05 -0700 (PDT) In-Reply-To: References: From: Dimitri De Jonghe Date: Thu, 10 Aug 2017 10:55:05 +0200 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Cc: Veikko Eeva , Interledger Mailing List - IETF , Interledger Community Group Content-Type: multipart/alternative; boundary="94eb2c19fb705f9a4b0556625a1b" Archived-At: Subject: Re: [Ledger] Plasma: Scalable Autonomous Smart Contracts (Ethereum, Poon & Buterin) X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 08:57:04 -0000 --94eb2c19fb705f9a4b0556625a1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Then I would rather see ledger-agnostic compute (ie https://www.codius.org/= ) - but glad they start to realize that state transition is blocked by compute consensus 2017-08-10 10:52 GMT+02:00 Jorge Tim=C3=B3n : > Unfortunately is based on ethereum, which has many design flaws. Bitcoin > or Bitcoin-like smart contracts are much more interesting to me. > > On 10 Aug 2017 11:41, "Veikko Eeva" wrote: > >> Hi! >> >> This could be an interesting piece of discussion: http://plasma.io/. I >> have not the paper (yet), here's the the abstract >> >> Abstract: Plasma is a proposed framework for incentivized and enforced >> execution of smart contracts which is scalable to a significant amount o= f >> state updates per second (potentially billions) enabling the blockchain = to >> be able to represent a significant amount of decentralized financial >> applications worldwide. These smart contracts are incentivized to contin= ue >> operation autonomously via network transaction fees, which is ultimately >> reliant upon the underlying blockchain (e.g. Ethereum) to enforce >> transactional state transitions. >> >> We propose a method for decentralized autonomous applications to scale t= o >> process not only financial activity, but also construct economic incenti= ves >> for globally persistent data services, which may produce an alternative = to >> centralized server farms. >> >> Plasma is composed of two key parts of the design: Reframing all >> blockchain computation into a set of MapReduce functions, and an optiona= l >> method to do Proof-of-Stake token bonding on top of existing blockchains >> with the understanding that the Nakamoto Consensus incentives discourage >> block withholding. >> This construction is achieved by composing smart contracts on the main >> blockchain using fraud proofs whereby state transitions can be enforced = on >> a parent blockchain. We compose blockchains into a tree hierarchy, and >> treat each as an individual branch blockchain with enforced blockchain >> history and MapReducable computation committed into merkle proofs. By >> framing one's ledger entry into a child blockchain which is enforced by = the >> parent chain, one can enable incredible scale with minimized trust >> (presuming root blockchain availability and correctness). >> >> The greatest complexity around global enforcement of non-global data >> revolves around data availability and block withholding attacks, Plasma = has >> mitigations for this issue by allowing for exiting faulty chains while a= lso >> creating mechanisms to incentivize and enforce continued correct executi= on >> of data. >> >> As only merkleized commitments are broadcast periodically to the root >> blockchain (i.e. Ethereum) during non-faulty states, this can allow for >> incredibly scalable, low cost transactions and computation. Plasm= a >> enables persistently operating decentralized applications at high scale. >> >> Cheers, >> Veikko Eeva >> >> --=20 [image: Logo] Dimitri De Jonghe, PhD Application Director phone +32 496 809 414 skype dimi.dejonghe BigchainDB GmbH | Twitter | LinkedIn | GitHub | Facebook info@bigchaindb.com | www.bigchaindb.com | +49 30 6482 6092 Wichertstr. 14a, 10439 Berlin | Managing Director: Bruce Pon | Registered in Berlin HRB 160856B --94eb2c19fb705f9a4b0556625a1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Then I would rather see ledger-agnostic compute (ie=C2=A0<= a href=3D"https://www.codius.org/">https://www.codius.org/) - but glad = they start to realize that state transition is blocked by compute consensus=

2017-08-10 = 10:52 GMT+02:00 Jorge Tim=C3=B3n <jtimon@jtimon.cc>:
Unfortunately is based on ether= eum, which has many design flaws. Bitcoin or Bitcoin-like smart contracts a= re much more interesting to me.

On 10 Aug 2017 = 11:41, "Veikko Eeva" <veikko.eeva@waresign.com> wrote:
Hi!

This could be an interesting piece of discussion: http://plasma.io/. I have not= the paper (yet), here's the the abstract

Abstract: Plasma is a proposed framework for incentivized and enforced exec= ution of smart contracts which is scalable to a significant amount of state= updates per second (potentially billions) enabling the blockchain to be ab= le to represent a significant amount of decentralized financial application= s worldwide. These smart contracts are incentivized to continue operation a= utonomously via network transaction fees, which is ultimately reliant upon = the underlying blockchain (e.g. Ethereum) to enforce transactional state tr= ansitions.

We propose a method for decentralized autonomous applications to scale to p= rocess not only financial activity, but also construct economic incentives = for globally persistent data services, which may produce an alternative to = centralized server farms.

Plasma is composed of two key parts of the design: Reframing all blockchain= computation into a set of MapReduce functions, and an optional method to d= o Proof-of-Stake token bonding on top of existing blockchains with the unde= rstanding that the Nakamoto Consensus incentives discourage block withholdi= ng.
This construction is achieved by composing smart contracts on the main bloc= kchain using fraud proofs whereby state transitions can be enforced on a pa= rent blockchain. We compose blockchains into a tree hierarchy, and treat ea= ch as an individual branch blockchain with enforced blockchain history and = MapReducable computation committed into merkle proofs. By framing one's= ledger entry into a child blockchain which is enforced by the parent chain= , one can enable incredible scale with minimized trust (presuming root bloc= kchain availability and correctness).

The greatest complexity around global enforcement of non-global data revolv= es around data availability and block withholding attacks, Plasma has mitig= ations for this issue by allowing for exiting faulty chains while also crea= ting mechanisms to incentivize and enforce continued correct execution of d= ata.

As only merkleized commitments are broadcast periodically to the root block= chain (i.e. Ethereum) during non-faulty states, this can allow for incredib= ly scalable, low cost transactions=C2=A0 =C2=A0 =C2=A0 =C2=A0 and computati= on. Plasma enables persistently operating decentralized applications at hig= h scale.

Cheers,
Veikko Eeva




--
=


3D"Logo"

Dimitri De Jonghe, PhD
Application Director=

phone+32 496 809 414
skypedimi.dejonghe

BigchainDB GmbH=C2=A0|=C2=A0Twitter=C2=A0|=C2=A0LinkedIn=C2=A0|=C2=A0GitHub=C2=A0|=C2=A0Facebook=C2=A0
i= nfo@bigchaindb.com=C2=A0|=C2=A0www.bigchaindb.com=C2=A0|=C2=A0+49 30 6482 6092=C2= =A0
Wichertstr. 14a, 10439 Berlin=C2=A0| Managing Director:= Bruce Pon | Registered in Berlin HRB 160856B

=
--94eb2c19fb705f9a4b0556625a1b-- From jtimon@jtimon.cc Thu Aug 10 01:52:09 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C316613265D for ; Thu, 10 Aug 2017 01:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jtimon-cc.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 vp4bAZMPjSh5 for ; Thu, 10 Aug 2017 01:52:08 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 F14821323D7 for ; Thu, 10 Aug 2017 01:52:07 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 80so557707uas.0 for ; Thu, 10 Aug 2017 01:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dEXZmdkhdNfSvnzzPStRCpwqAFITqns2rWek30jJkyU=; b=ZWoAjlnZwfI/P+OWrNGUPLUUtr76Su5kDSc23JK+7m65U5LR95/lxMJMT7aOVSRFub yPr5i/hzU/3JjEv1LlZpNZ8xxMU0K+0OMwJPJ+/YLK4Oi0MARahqHmzMZO/5ymp7b0UN S2agae3nMrGuKqJcNUjF4oGtxrT4++6luxcWlTp5PiHl8ZhmOKadTeF0vgKUUHfLwour a0Tq51pFKHZZlKb20QIbH4U28xBWFnWX+rltD9A83LV8KVXgWzBESwgJ3AmdJ4QcPpK2 JysiNjHnSu8h+vk0Nck7sXXpAvKrBXz0uVgMmt65bC4lu+5wGn7F+msB4tDtqvICHU9D hlDw== 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=dEXZmdkhdNfSvnzzPStRCpwqAFITqns2rWek30jJkyU=; b=Xrgy3w06O+4WXaq1xWJA8uJh8uNyuBWP7QIqh9pC/nbMObYHcxj+ukCRQSkUJh2FYY 9IKXATQLALRTp6GkxhBfF/AJM6Qsh+S2zFn5mn7A88FR4vVLxWW/gmLK3SP5oy4ymctA SMibbWI7Ku+nA9FlPvgVbhcbIYaQRtztE6EhIEygaXHA7CesRNoudq17HMXDISZvtePy 5Vp+sg546Cb+KUucIVG/HJOmmNBY8n/UZxVQSdQ2FHe02Nd6tqQ2hHo2AHDVMlvoMI0M vqpzxyVM8yKIPLVxpOxvBWWAAw3RZlenbsOjzIifqJJrZ1nxYIutXa6tDs3e3jFjkuKL gFPw== X-Gm-Message-State: AHYfb5iz2JOW+dfr1Lhc9YBsDRgZoJ6kef5xGZ5ZNFOKDj0dPzVk1k0p PRvyo95AL9wh7mloEDE6PFX0PVeA3wLI X-Received: by 10.176.65.193 with SMTP id 59mr7104442uap.83.1502355126851; Thu, 10 Aug 2017 01:52:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.96.215 with HTTP; Thu, 10 Aug 2017 01:52:05 -0700 (PDT) Received: by 10.31.96.215 with HTTP; Thu, 10 Aug 2017 01:52:05 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Thu, 10 Aug 2017 10:52:05 +0200 Message-ID: To: Veikko Eeva Cc: Interledger Mailing List - IETF , public-interledger@w3.org Content-Type: multipart/alternative; boundary="001a114a766ca9afc00556624f4a" Archived-At: X-Mailman-Approved-At: Thu, 10 Aug 2017 06:42:23 -0700 Subject: Re: [Ledger] Plasma: Scalable Autonomous Smart Contracts (Ethereum, Poon & Buterin) X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Aug 2017 12:04:44 -0000 --001a114a766ca9afc00556624f4a Content-Type: text/plain; charset="UTF-8" Unfortunately is based on ethereum, which has many design flaws. Bitcoin or Bitcoin-like smart contracts are much more interesting to me. On 10 Aug 2017 11:41, "Veikko Eeva" wrote: > Hi! > > This could be an interesting piece of discussion: http://plasma.io/. I > have not the paper (yet), here's the the abstract > > Abstract: Plasma is a proposed framework for incentivized and enforced > execution of smart contracts which is scalable to a significant amount of > state updates per second (potentially billions) enabling the blockchain to > be able to represent a significant amount of decentralized financial > applications worldwide. These smart contracts are incentivized to continue > operation autonomously via network transaction fees, which is ultimately > reliant upon the underlying blockchain (e.g. Ethereum) to enforce > transactional state transitions. > > We propose a method for decentralized autonomous applications to scale to > process not only financial activity, but also construct economic incentives > for globally persistent data services, which may produce an alternative to > centralized server farms. > > Plasma is composed of two key parts of the design: Reframing all > blockchain computation into a set of MapReduce functions, and an optional > method to do Proof-of-Stake token bonding on top of existing blockchains > with the understanding that the Nakamoto Consensus incentives discourage > block withholding. > This construction is achieved by composing smart contracts on the main > blockchain using fraud proofs whereby state transitions can be enforced on > a parent blockchain. We compose blockchains into a tree hierarchy, and > treat each as an individual branch blockchain with enforced blockchain > history and MapReducable computation committed into merkle proofs. By > framing one's ledger entry into a child blockchain which is enforced by the > parent chain, one can enable incredible scale with minimized trust > (presuming root blockchain availability and correctness). > > The greatest complexity around global enforcement of non-global data > revolves around data availability and block withholding attacks, Plasma has > mitigations for this issue by allowing for exiting faulty chains while also > creating mechanisms to incentivize and enforce continued correct execution > of data. > > As only merkleized commitments are broadcast periodically to the root > blockchain (i.e. Ethereum) during non-faulty states, this can allow for > incredibly scalable, low cost transactions and computation. Plasma > enables persistently operating decentralized applications at high scale. > > Cheers, > Veikko Eeva > > --001a114a766ca9afc00556624f4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unfortunately is based on ethereum, which has many design= flaws. Bitcoin or Bitcoin-like smart contracts are much more interesting t= o me.

On 10 = Aug 2017 11:41, "Veikko Eeva" <veikko.eeva@waresign.com> wrote:
Hi!

This could be an interesting piece of discussion: http://plasma.io/. I have not= the paper (yet), here's the the abstract

Abstract: Plasma is a proposed framework for incentivized and enforced exec= ution of smart contracts which is scalable to a significant amount of state= updates per second (potentially billions) enabling the blockchain to be ab= le to represent a significant amount of decentralized financial application= s worldwide. These smart contracts are incentivized to continue operation a= utonomously via network transaction fees, which is ultimately reliant upon = the underlying blockchain (e.g. Ethereum) to enforce transactional state tr= ansitions.

We propose a method for decentralized autonomous applications to scale to p= rocess not only financial activity, but also construct economic incentives = for globally persistent data services, which may produce an alternative to = centralized server farms.

Plasma is composed of two key parts of the design: Reframing all blockchain= computation into a set of MapReduce functions, and an optional method to d= o Proof-of-Stake token bonding on top of existing blockchains with the unde= rstanding that the Nakamoto Consensus incentives discourage block withholdi= ng.
This construction is achieved by composing smart contracts on the main bloc= kchain using fraud proofs whereby state transitions can be enforced on a pa= rent blockchain. We compose blockchains into a tree hierarchy, and treat ea= ch as an individual branch blockchain with enforced blockchain history and = MapReducable computation committed into merkle proofs. By framing one's= ledger entry into a child blockchain which is enforced by the parent chain= , one can enable incredible scale with minimized trust (presuming root bloc= kchain availability and correctness).

The greatest complexity around global enforcement of non-global data revolv= es around data availability and block withholding attacks, Plasma has mitig= ations for this issue by allowing for exiting faulty chains while also crea= ting mechanisms to incentivize and enforce continued correct execution of d= ata.

As only merkleized commitments are broadcast periodically to the root block= chain (i.e. Ethereum) during non-faulty states, this can allow for incredib= ly scalable, low cost transactions=C2=A0 =C2=A0 =C2=A0 =C2=A0 and computati= on. Plasma enables persistently operating decentralized applications at hig= h scale.

Cheers,
Veikko Eeva

--001a114a766ca9afc00556624f4a-- From nobody Mon Aug 14 09:58:01 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB631323B0 for ; Mon, 14 Aug 2017 09:58:00 -0700 (PDT) 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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 jTqI1aI_6IAV for ; Mon, 14 Aug 2017 09:57:57 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 80ED61321B9 for ; Mon, 14 Aug 2017 09:57:57 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id f9so38871374uaf.4 for ; Mon, 14 Aug 2017 09:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=EgW6kMLW/eXzxVR2xtz/kvRMgFBYns3WzupHq6n4NgA=; b=NCzGvm3xw6MPHiFjFQb8Tp/7Gu6y6VYxgv8xZ0qB58t+o09nFFSZaVo5NIow3ysvuv lMyHIKvm95GCnszQXfM13jIo09/p3l+/lbafOxcl+C5Gvc48C/RHbKhVIBsKfbC6AFzo NLQ+YPdFe/343Y5NjPLnaegZlM2mjPCB77r/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EgW6kMLW/eXzxVR2xtz/kvRMgFBYns3WzupHq6n4NgA=; b=WUxBLpVnYqLd1zfzcAU3l8bUArsO74PCb+m5Mfpk5H/7QqLrluYGQ5xH0V+gwQ3Sy0 3wYQf7t8i9K/WOfDBNJACzW84Vc+Z/FkiFNL7Clc6FtGjPoy2qb6HF9dK5bVgZJirHOu z8XiGf7UyHcYNo3iW9VBws6KKExnU3S/FE0l7lAAUEF+Gly9WkEH4ytpZc/utoWT0zhn /s/AkRRizBgKY5tX4k53WnkmqkexHMdindoUKA6AbUZANRkXiM+dTHHI2KvAzFdEht4o 7zTAs712AmqwXDfIlFe9xg7hjwwHgss9K4oD2S/q/VZNStoZIite0PoLG6Chq+z9eiMy oFnQ== X-Gm-Message-State: AHYfb5i6MCM8VdJEgozANCJFO7O8TLXLHLwwhS1+1ROd7cuUFVbgSzNC +B15nlGxPDu9NOJNQHZdtQKEUlssDxex X-Received: by 10.159.57.201 with SMTP id p9mr17598853uag.209.1502729876135; Mon, 14 Aug 2017 09:57:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.62.90 with HTTP; Mon, 14 Aug 2017 09:57:55 -0700 (PDT) From: Adrian Hope-Bailie Date: Mon, 14 Aug 2017 18:57:55 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="f403045fe92c764a210556b990b1" Archived-At: Subject: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 16:58:00 -0000 --f403045fe92c764a210556b990b1 Content-Type: text/plain; charset="UTF-8" I have had an ongoing debate with a number of people about the correct way to architect the protocol layering for Interledger. This has been an excellent discussion and I've made some valuable realizations (and conceded some mistakes on my part) along the way but I am still convinced that we have some errors in our architecture which are making the whole stack unwieldy and making it difficult to progress on designs for other layers. There is a sense that we should not be changing the core packet definitions any more but I'm not sure what justifies this. We have a limited number of implementations and the specifics of the packet formats and encapsulation are confined to a single library in both. Furthermore, the fundamentals of the protocol don't change, just the packet formats and layering to better reflect the protocol and not be influenced so strongly by the implementation. This is my attempt to explain my rationale and solicit feedback from the community. Hopefully we can come to consensus on the right design (ignoring concerns about X is frozen; or "we said we aren't going to change Y anymore" or this will break Z). Once we have a design we consider correct, let's count the cost and decide if it's a v2 or we can implement it now. *Protocol Layering: Request/Response at the core* Protocol layering is a mature pattern. The layering is achieved through encapsulation. A packet contains headers and a payload, and the payload is the packet of the next layer up. In the Internet stack the internetworking layer is the IP layer. Packets are addressed using IP addresses and layers above rely on these addresses to introduce messaging semantics. Layers below are host-to-host protocols that carry the IP packet from one host to another. *All data in the host-to-host protocol is discarded* when the packet is de-framed and re-framed for the next hop. The internetworking layer in the ILP stack is the Interledger layer. At this layer packets are used to carry payments, quotes and errors and are addressed using an Interledger Address. Similar to IP there are host-to-host protocols that exist below ILP and carry the ILP packets over each hop and higher layer protocols that carry end-to-end data encapsulated in the payload of the ILP packet. Currently, ILP requires that data outside the packet be passed along with the packet instead of inside the packet, requiring special treatment of specific hots-to-host data and making it very difficult to add/change this data in future. A critical difference between IP and ILP is in the messaging semantics. IP has none. A packet simply contains a source and destination address and higher layers use these (and introduce additional properties such as ports) to establish reliable connections, sessions etc. In contrast, ILP only works if ILP packets exist as request/response pairs and the response packets follow exactly the same route as the request packets. As such an ILP request packet has no source address, as this is useless. A response packet can't simply be addressed to the source of the request and sent. *A response packet must retrace the route of the request.* One may argue (as I did before) that a request/response pair should then have a unique end-to-end identifier that nodes can use to associate a request with it's original response, however there is a danger in relying on this identifier as it could be manipulated to cause responses to fail. If you can't rely on it, why have it at all? As such, a node at the Interledger layer MUST maintain state and be able to, not only match request/response pairs at the host-to-host layer but also, *match an incoming request/response pair to an outgoing request/response pair.* How a host does this not defined in the protocol but it means that at a minimum the host-to-host protocols must allow request/response pairs to be matched AND uniquely identified. Example: When Host B receives Response A from Host C it must pass that on as Response 1 to Host A. This would have to be recorded during the routing of Request 1 to Request A. Host A Host B Host C --- Request 1 --> -- Request A --> <-- Response 1 -- <-- Response A -- In protocol stacks like IP and ILP the internetworking layer is the glue between lower host-to-host layers and higher end-to-end layers. To avoid overloading the internetworking packets themselves it should be possible to encapsulate higher level protocol packets in the internetworking layer payload. Another unique feature of ILP (where it differs from IP) is that some Interledger packets carry value. You can look at this two ways: 1. The ILP payment packet carries value end-to-end. 2. The ILP payment packet carries data end-to-end but the sender pays for this. There are two basic request types in ILP, those that carry data and those that carry both data and value. For all request types there is a valid response type but the response could also be an error. Example: the response to a payment is a fulfillment, the response to a quote by source amount request is a quote by source amount response. In summary: - ILP depends on request/response semantics at it's core (these are a requirement of the internetworking layer itself, not just higher level protocols). - As such, the internetworking layer packets must be either a request or a response and the protocol should define which responses are valid for which requests and all requests should have a response. - There are two primary request packet types (a request carrying data and a request carrying data and value). - There are two primary response types, a success and failure response. The success responses are sub-typed to match the sub-type of the request, however the error response could be returned for any request. Proposal: - All interledger layer messages should be ILP packets (including fulfillments) and be capable of carrying higher layer protocol payloads. - While it may make sense to split the interledger payment and interledger quoting protocols into new higher level protocols that seems like an unnecessary abstraction. Instead the packet definitions should just have some consistency and probably a common base/header. - We should define two base ILP packet types: request and response. - A payment packet should extend the request type and fulfillment and error should extend response. - The ILQP packets already roughly follow this pattern but perhaps a generic message packet is also required. *Ledgers and Trustlines* For some time there has been a debate about what constitutes the nodes and what the edges in the Interledger graph. As we've begun to appreciate the various different forms a line of trust between two peers can take it's become clear that ledgers are not actually core to the protocol (despite the name). If you consider senders, receivers and connectors to be the nodes, then edges are simply lines of trust between any two nodes. In other words the Interledger is made of nodes that are connected via financial agreements of some form that allow for two nodes to transfer value between one another. This agreement may or may not be underwritten by a ledger that supports conditional transfers. Where there is a ledger that both parties trust to perform conditional transfers correctly the parties no longer need to trust one another (they trust the ledger). The Interledger works because not only does it define a universal address space for this network, it also defines a universal signature scheme for payment requests and receipts that can be leveraged by individual trustlines on the route of a payment, for conditional transfers between two peers. When two disconnected nodes wish to setup a payment they exchange data so that the sender has, at a minimum, the address of the receiver, a condition that the receiver can fulfill and the amount (in the receiver's currency) that the receiver must receive. Next the sender finds a peer to send a local transfer to, to initiate the end-to-end payment. They package all of the end-to-end data in an ILP packet and make the local transfer (attaching the packet or sending it to the peer separately). The terms of the local transfer are: "Show me the signature from the receiver that proves they were paid and you get the proceeds of the local transfer." These terms can be enforced in a variety of ways, one of which is by making the transfer on a ledger that understands the condition and fulfillment format and supports conditional payments. This protects the sender from their upstream peer in the case where they are unable to produce the fulfillment but still want to claim the proceeds of the transfer. i.e. It simply changes who the sender trusts (the ledger instead of the peer) How the ILP packet is transferred to the peer and how the transfer is setup on the ledger *are very different concerns*. It is a mistake to assume that the communication mechanism between peers is the creation of the transfer on the ledger itself. I believe that some of the confusion around this comes from the design of 5-bells ledger where these are the same thing. Consider the following setup where the ledger supports conditional transfers but does not support notifications as an example. Peer A Ledger Peer B | -- LocalTransfer(LocalAmount,Condition) --> | | | <----------- Prepared --------------------- | | | -------------- ILP Payment Request (ILP Address, RemoteAmount, Condition) --------------------> | | | <--------- Check for pending transfer------------ | | <----------------------------------------- Ack ------------------------------------------------ | | - Poll for completed transfer (Optional) -> | | | | | --> Transfer | | | <-- Fulfillment | | <---------- Submit fulfillment------------------- | | <------------------------- ILP Payment Response(Fulfillment) ---------------------------------- | | - Confirm completed transfer (Optional) --> | | Note how the communication between peers, carrying the ILP packet, does not go through the ledger. Also, note how the ledger doesn't need to understand anything about ILP other than supporting the universal signature format (conditions and fulfillments). For simplicity this example excluded expiry but these could just as easily be included alongside the condition in the direct communication between the peers (i.e. in the ILP packet). The expiry in the packet is very similar to the TTL in an IP packet. Theoretically it can be modified at each hop to a value that the local sender considers safe for the outgoing local transfer and the trustline on which it is sent. Summary: - ILP is not about ledgers, it is about trustlines between nodes/hosts. - A trustline may be underwritten by a ledger to allow nodes to establish a trustline-by-proxy where they trust the ledger and not their peer. This is possible if the ledger supports conditional payments using ILP-style conditions. - The protocol should differentiate between the operation of preparing a transfer on a ledger and the operation of passing an ILP packet from one peer to another. Proposal: - The condition and timeout should be included in the ILP payment packet. - Where the fulfillment is a signature over the packet these can be zero'd out first as with the checksum in an IP packet. Look forward to your thoughts! --f403045fe92c764a210556b990b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have had an ongoing debate with a number of people about the correct wa= y to architect the protocol layering for Interledger. This has been an exce= llent discussion and I've made some valuable realizations (and conceded= some mistakes on my part) along the way but I am still convinced that we h= ave some errors in our architecture which are making the whole stack unwiel= dy and making it difficult to progress on designs for other layers.

=
There is a sense that we should not be changing the core packet = definitions any more but I'm not sure what justifies this. We have a li= mited number of implementations and the specifics of the packet formats and= encapsulation are confined to a single library in both. Furthermore, the f= undamentals of the protocol don't change, just the packet formats and l= ayering to better reflect the protocol and not be influenced so strongly by= the implementation.

This is my attempt to explain = my rationale and solicit feedback from the community. Hopefully we can come= to consensus on the right design (ignoring concerns about X is frozen; or = "we said we aren't going to change Y anymore" or this will br= eak Z). Once we have a design we consider correct, let's count the cost= and decide if it's a v2 or we can implement it now.

Pr= otocol Layering: Request/Response at the core

Protocol lay= ering is a mature pattern. The layering is achieved through encapsulation. = A packet contains headers and a payload, and the payload is the packet of t= he next layer up.

In the Internet stack the internetworking layer i= s the IP layer. Packets are addressed using IP addresses and layers above r= ely on these addresses to introduce messaging semantics. Layers below are h= ost-to-host protocols that carry the IP packet from one host to another. All data in the host-to-host protocol is discarded when the packet is = de-framed and re-framed for the next hop.

The internetworking = layer in the ILP stack is the Interledger layer. At this layer packets are = used to carry payments, quotes and errors and are addressed using an Interl= edger Address. Similar to IP there are host-to-host protocols that exist be= low ILP and carry the ILP packets over each hop and higher layer protocols = that carry end-to-end data encapsulated in the payload of the ILP packet.
Currently, ILP requires that data outside the packet be pa= ssed along with the packet instead of inside the packet, requiring special = treatment of specific hots-to-host data and making it very difficult to add= /change this data in future.

A critical difference = between IP and ILP is in the messaging semantics. IP has none. A packet sim= ply contains a source and destination address and higher layers use these (= and introduce additional properties such as ports) to establish reliable co= nnections, sessions etc. In contrast, ILP only works if ILP packets exist a= s request/response pairs and the response packets follow exactly the same r= oute as the request packets.

As such an ILP request packet has= no source address, as this is useless. A response packet can't simply = be addressed to the source of the request and sent. A response packet mu= st retrace the route of the request.

One may argue (as I did bef= ore) that a request/response pair should then have a unique end-to-end iden= tifier that nodes can use to associate a request with it's original res= ponse, however there is a danger in relying on this identifier as it could = be manipulated to cause responses to fail. If you can't rely on it, why= have it at all?

As such, a node at the Interledger layer MUST maint= ain state and be able to, not only match request/response pairs at the host= -to-host layer but also, match an incoming request/response pair to an o= utgoing request/response pair.

How a host= does this not defined in the protocol but it means that at a minimum the h= ost-to-host protocols must allow request/response pairs to be matched AND u= niquely identified.

Example:

When Host B rec= eives Response A from Host C it must pass that on as Response 1 to Host A. = This would have to be recorded during the routing of Request 1 to Request A= .

Host A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Host B=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ho= st C
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- Request 1 -->=C2=A0=C2=A0 =C2=A0 =C2= =A0=C2=A0=C2=A0 --=C2=A0 Request A -->
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <--= Response 1 --=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 <-- Response A= --

In protocol stacks like IP and ILP the internetwork= ing layer is the glue between lower host-to-host layers and higher end-to-e= nd layers. To avoid overloading the internetworking packets themselves it s= hould be possible to encapsulate higher level protocol packets in the inter= networking layer payload.

Another unique feature of = ILP (where it differs from IP) is that some Interledger packets carry value= . You can look at this two ways:
1. The ILP payment packet ca= rries value end-to-end.
2. The ILP payment packet carries dat= a end-to-end but the sender pays for this.

There are two basic reque= st types in ILP, those that carry data and those that carry both data and v= alue.

For all request types there is a valid response typ= e but the response could also be an error. Example: the response to a payme= nt is a fulfillment, the response to a quote by source amount request is a = quote by source amount response.

In summary:- ILP depends on request/response semantics at it's core (these are a= requirement of the internetworking layer itself, not just higher level pro= tocols).
- As such, the internetworking layer packets must be either a = request or a response and the protocol should define which responses are va= lid for which requests and all requests should have a response.
- There are two primary request packet types (a request carrying data an= d a request carrying data and value).
- There are two primary= response types, a success and failure response. The success responses are = sub-typed to match the sub-type of the request, however the error response = could be returned for any request.

Proposal:
- All interledger layer messages should be ILP packets (including fulfill= ments) and be capable of carrying higher layer protocol payloads.
=
- While it may make sense to split the interledger payment and interle= dger quoting protocols into new higher level protocols that seems like an u= nnecessary abstraction. Instead the packet definitions should just have som= e consistency and probably a common base/header.
- We should = define two base ILP packet types: request and response.
- A p= ayment packet should extend the request type and fulfillment and error shou= ld extend response.
- The ILQP packets already roughly follow= this pattern but perhaps a generic message packet is also required.

Ledgers and Trustlines

For = some time there has been a debate about what constitutes the nodes and what= the edges in the Interledger graph. As we've begun to appreciate the v= arious different forms a line of trust between two peers can take it's = become clear that ledgers are not actually core to the protocol (despite th= e name). If you consider senders, receivers and connectors to be the nodes,= then edges are simply lines of trust between any two nodes.

<= div>In other words the Interledger is made of nodes that are connected via = financial agreements of some form that allow for two nodes to transfer valu= e between one another. This agreement may or may not be underwritten by a l= edger that supports conditional transfers. Where there is a ledger that bot= h parties trust to perform conditional transfers correctly the parties no l= onger need to trust one another (they trust the ledger).

The Interle= dger works because not only does it define a universal address space for th= is network, it also defines a universal signature scheme for payment reques= ts and receipts that can be leveraged by individual trustlines on the route= of a payment, for conditional transfers between two peers.

When two disconnected nodes wish to setup a payment they exchange data s= o that the sender has, at a minimum, the address of the receiver, a conditi= on that the receiver can fulfill and the amount (in the receiver's curr= ency) that the receiver must receive. Next the sender finds a peer to send = a local transfer to, to initiate the end-to-end payment. They package all o= f the end-to-end data in an ILP packet and make the local transfer (attachi= ng the packet or sending it to the peer separately).

The = terms of the local transfer are: "Show me the signature from the recei= ver that proves they were paid and you get the proceeds of the local transf= er."

These terms can be enforced in a variety of way= s, one of which is by making the transfer on a ledger that understands the = condition and fulfillment format and supports conditional payments. This pr= otects the sender from their upstream peer in the case where they are unabl= e to produce the fulfillment but still want to claim the proceeds of the tr= ansfer. i.e. It simply changes who the sender trusts (the ledger instead of= the peer)

How the ILP packet is transferred to the peer = and how the transfer is setup on the ledger are very different concerns<= /b>. It is a mistake to assume that the communication mechanism between pee= rs is the creation of the transfer on the ledger itself. I believe that som= e of the confusion around this comes from the design of 5-bells ledger wher= e these are the same thing.

Consider the following setup = where the ledger supports conditional transfers but does not support notifi= cations as an example.

Peer A =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Ledger=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Peer B

= =C2=A0 | -- LocalTransfer(LocalAmount,Condition) --> |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0 | <----------- Prepare= d --------------------- |=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |<= /span>
=C2=A0 | -------------- ILP Payment R= equest (ILP Address, RemoteAmount, Condition) --------------------> |=C2=A0
=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | <--------- Check for pending transfer------------ |
=C2=A0 | <----------------------------------------- Ack -----------= ------------------------------------- |=C2=A0
=C2=A0 | - Poll for comple= ted transfer (Optional) -> |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | --> Transfer
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | <-- Fulfillment
= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | <---------- Submit fulfillment-----------= -------- |
=C2=A0= | <------------------------- ILP Payment Response(Fulfillment) --------= -------------------------- |=C2=A0
<= /span>
=C2=A0 | -= Confirm completed transfer (Optional) --> |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

Note how the communication between peers, carrying the ILP packet, does no= t go through the ledger. Also, note how the ledger doesn't need to unde= rstand anything about ILP other than supporting the universal signature for= mat (conditions and fulfillments). For simplicity this example excluded exp= iry but these could just as easily be included alongside the condition in t= he direct communication between the peers (i.e. in the ILP packet).

= The expiry in the packet is very similar to the TTL in an IP packet. Theore= tically it can be modified at each hop to a value that the local sender con= siders safe for the outgoing local transfer and the trustline on which it i= s sent.

Summary:

- ILP is not about led= gers, it is about trustlines between nodes/hosts.
- A trustline may be u= nderwritten by a ledger to allow nodes to establish a trustline-by-proxy wh= ere they trust the ledger and not their peer. This is possible if the ledge= r supports conditional payments using ILP-style conditions.
-= The protocol should differentiate between the operation of preparing a tra= nsfer on a ledger and the operation of passing an ILP packet from one peer = to another.

Proposal:
- The condition and t= imeout should be included in the ILP payment packet.
- Where = the fulfillment is a signature over the packet these can be zero'd out = first as with the checksum in an IP packet.

Lo= ok forward to your thoughts!








=
--f403045fe92c764a210556b990b1-- From nobody Mon Aug 14 13:04:03 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19D613240F for ; Mon, 14 Aug 2017 13:04:01 -0700 (PDT) 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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ripple.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 uBr-TrsvTOaC for ; Mon, 14 Aug 2017 13:03:57 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 B8BF8126E64 for ; Mon, 14 Aug 2017 13:03:56 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id a18so57894022qta.0 for ; Mon, 14 Aug 2017 13:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=UOpSmHM4i/v2lAqgD2pAHpOHraqrEOYyzRaOK0z7TZg=; b=TzgorUMnKz16dstSCyUEy+gcqGSgw82/KrWvJOjj/09+DzxpNdb6o77CDhEQRe2HXq 1OhDy1lObD9RUiN/Dp43C7F6bTdG/smbXdzYtpLKsfdWexQbZUyGTLD347iOOGCzKaMq 8M53HcvT91bNVlj1w/E2Wl4CImbTUguUW4YM0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=UOpSmHM4i/v2lAqgD2pAHpOHraqrEOYyzRaOK0z7TZg=; b=ok+gjCQPzVa/9gBa9JkdtS4YaUtyCfatPVmVbVksoUc++N2NDRwOziLpgc7h2YzX4Y r+fYLSF1CS6X1j1zVkkEAWhJK/NGQa/mrVMO87RPOsuCUuZtEbzhtNapo+vicv9ZpYX0 IvKUqtS+FnlrQioNH6SZske3nwQ0JoEewjKvHgJ4w1xPXhCS7JeV6HSEzv1MtM5NmQiy s/5HaLEouQ6DtiHYfTAJws/86P4oOkf89s47HViyMNjRaECB8oU4uu6g00Aw86yRk0qE aybzyFdJIUdYvDF4YXgAUGZ0NoISANBFEVAFUagzjJgTi6efiK0o3L4K0wdijdsEIZ6j qR9w== X-Gm-Message-State: AHYfb5jZ6Lsg/FFBbTb+PTSR2G7Evtudt5wFX6etZVIYPexvSeqIYH9g 8UuA9i0JT3O8zASQ617ktN/D65/M8ULa X-Received: by 10.200.41.118 with SMTP id z51mr35237465qtz.201.1502741035701; Mon, 14 Aug 2017 13:03:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Evan Schwartz Date: Mon, 14 Aug 2017 20:03:44 +0000 Message-ID: To: Adrian Hope-Bailie , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a113f2a489f6c6b0556bc292b" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 20:04:02 -0000 --001a113f2a489f6c6b0556bc292b Content-Type: text/plain; charset="UTF-8" I think this thread is going to get extremely unwieldy but here goes: > - All interledger layer messages should be ILP packets (including fulfillments) and be capable of carrying higher layer protocol payloads. Interledger has higher requirements than ILP for the lowest layer, specifically because we are carrying money and not just data. One of the requirements is being able to transmit a 32-byte fulfillment back along the same path that carried the payment originally. If we expect this of the lower layer, I don't see a point in putting the fulfillment into an ILP packet and transmitting it as Interledger data along the same path. All ledger-layer protocols will need to interpret the fulfillment passed in their protocol, not the one passed through the Interledger layer. > - While it may make sense to split the interledger payment and interledger quoting protocols into new higher level protocols that seems like an unnecessary abstraction. Instead the packet definitions should just have some consistency and probably a common base/header. The current protocols effectively have this header but it isn't separated out. There are two fields in the request header: type and destination address. There is one field in the response header: type. I don't think it makes that much of a big difference to separate these fields if all of the fields in that packet need to be interpreted together (for example, you can't understand a quote request if you strip off the destination address). > - We should define two base ILP packet types: request and response. Unless this adds some substantive benefit or new fields I don't think it's worth breaking all of the formats we have just to rearrange things. > - ILP is not about ledgers, it is about trustlines between nodes/hosts. A ledger is any system that tracks accounts and balances. When you use a trustline all of your messages still need to go through an accounting system (such as the plugin in the JS implementation) and then on to the other program logic. In that case, the plugin or whatever is doing the accounting is the ledger. Digital value is always tracked in ledgers, so I think it does make sense to think of this as the base layer. The reason to abstract the functionality you expect from the ledger layer is precisely so you can handle it in different ways, depending on what the underlying systems provide. I see 3 ways to think of the layer(s) underpinning ILP: 1. The "Ledger Layer" provides both messaging capabilities and some type of HTLA 2. There are separate plugins for messaging and for transfers and when you peer with someone you have to agree on a plugin for each 3. We standardize the messaging part and say that all goes over IP and then just have more minimal plugins for the on-ledger settlements Number 1 is what we have and I think that still makes the most sense. > - The protocol should differentiate between the operation of preparing a transfer on a ledger and the operation of passing an ILP packet from one peer to another. The protocol assumes your conditional transfer is underpinned by some HTLA . It doesn't care whether that's on-ledger or not. > - The condition and timeout should be included in the ILP payment packet. I strongly disagree with this. We had this debate a year ago and I was on your side but was convinced that this is not a good idea. The layer below ILP must be capable of doing conditional transfers based on sha256 hashlocks with 32-byte preimages. As a result, the original condition and the corresponding preimage MUST be expressed in that layer. Then the question is whether we should also include it in the packet that is forwarded. What ultimately convinced me is the following: All connectors MUST ignore the condition if it is in the packet, because they are only guaranteed their money back if they use the same condition from the incoming transfer they got. Also, the receiver will need to take out the condition in order to hash the packet for PSK or IPR. So basically, no one wants the condition in there. It feels like it ought to be in there, but literally none of the parties want the extra 32 bytes in there. The reason the timeout should not be in there is that there isn't a single timeout for the payment. There are multiple separate timeouts for each of the bilateral transfers. Those must go in the individual transfers and there is no sensible value to put in the Interledger packet. On Mon, Aug 14, 2017 at 12:58 PM Adrian Hope-Bailie wrote: > I have had an ongoing debate with a number of people about the correct way > to architect the protocol layering for Interledger. This has been an > excellent discussion and I've made some valuable realizations (and conceded > some mistakes on my part) along the way but I am still convinced that we > have some errors in our architecture which are making the whole stack > unwieldy and making it difficult to progress on designs for other layers. > > There is a sense that we should not be changing the core packet > definitions any more but I'm not sure what justifies this. We have a > limited number of implementations and the specifics of the packet formats > and encapsulation are confined to a single library in both. Furthermore, > the fundamentals of the protocol don't change, just the packet formats and > layering to better reflect the protocol and not be influenced so strongly > by the implementation. > > This is my attempt to explain my rationale and solicit feedback from the > community. Hopefully we can come to consensus on the right design (ignoring > concerns about X is frozen; or "we said we aren't going to change Y > anymore" or this will break Z). Once we have a design we consider correct, > let's count the cost and decide if it's a v2 or we can implement it now. > > > *Protocol Layering: Request/Response at the core* > Protocol layering is a mature pattern. The layering is achieved through > encapsulation. A packet contains headers and a payload, and the payload is > the packet of the next layer up. > > In the Internet stack the internetworking layer is the IP layer. Packets > are addressed using IP addresses and layers above rely on these addresses > to introduce messaging semantics. Layers below are host-to-host protocols > that carry the IP packet from one host to another. *All data in the > host-to-host protocol is discarded* when the packet is de-framed and > re-framed for the next hop. > > The internetworking layer in the ILP stack is the Interledger layer. At > this layer packets are used to carry payments, quotes and errors and are > addressed using an Interledger Address. Similar to IP there are > host-to-host protocols that exist below ILP and carry the ILP packets over > each hop and higher layer protocols that carry end-to-end data encapsulated > in the payload of the ILP packet. > > Currently, ILP requires that data outside the packet be passed along with > the packet instead of inside the packet, requiring special treatment of > specific hots-to-host data and making it very difficult to add/change this > data in future. > > A critical difference between IP and ILP is in the messaging semantics. IP > has none. A packet simply contains a source and destination address and > higher layers use these (and introduce additional properties such as ports) > to establish reliable connections, sessions etc. In contrast, ILP only > works if ILP packets exist as request/response pairs and the response > packets follow exactly the same route as the request packets. > > As such an ILP request packet has no source address, as this is useless. A > response packet can't simply be addressed to the source of the request and > sent. *A response packet must retrace the route of the request.* > > One may argue (as I did before) that a request/response pair should then > have a unique end-to-end identifier that nodes can use to associate a > request with it's original response, however there is a danger in relying > on this identifier as it could be manipulated to cause responses to fail. > If you can't rely on it, why have it at all? > > As such, a node at the Interledger layer MUST maintain state and be able > to, not only match request/response pairs at the host-to-host layer but > also, > *match an incoming request/response pair to an outgoing request/response > pair.* > > How a host does this not defined in the protocol but it means that at a > minimum the host-to-host protocols must allow request/response pairs to be > matched AND uniquely identified. > > Example: > > When Host B receives Response A from Host C it must pass that on as > Response 1 to Host A. This would have to be recorded during the routing of > Request 1 to Request A. > > Host A Host B Host C > --- Request 1 --> -- Request A --> > <-- Response 1 -- <-- Response A -- > > In protocol stacks like IP and ILP the internetworking layer is the glue > between lower host-to-host layers and higher end-to-end layers. To avoid > overloading the internetworking packets themselves it should be possible to > encapsulate higher level protocol packets in the internetworking layer > payload. > > Another unique feature of ILP (where it differs from IP) is that some > Interledger packets carry value. You can look at this two ways: > 1. The ILP payment packet carries value end-to-end. > 2. The ILP payment packet carries data end-to-end but the sender pays for > this. > > There are two basic request types in ILP, those that carry data and those > that carry both data and value. > > For all request types there is a valid response type but the response > could also be an error. Example: the response to a payment is a > fulfillment, the response to a quote by source amount request is a quote by > source amount response. > > In summary: > - ILP depends on request/response semantics at it's core (these are a > requirement of the internetworking layer itself, not just higher level > protocols). > - As such, the internetworking layer packets must be either a request or a > response and the protocol should define which responses are valid for which > requests and all requests should have a response. > - There are two primary request packet types (a request carrying data and > a request carrying data and value). > - There are two primary response types, a success and failure response. > The success responses are sub-typed to match the sub-type of the request, > however the error response could be returned for any request. > > Proposal: > - All interledger layer messages should be ILP packets (including > fulfillments) and be capable of carrying higher layer protocol payloads. > - While it may make sense to split the interledger payment and interledger > quoting protocols into new higher level protocols that seems like an > unnecessary abstraction. Instead the packet definitions should just have > some consistency and probably a common base/header. > - We should define two base ILP packet types: request and response. > - A payment packet should extend the request type and fulfillment and > error should extend response. > - The ILQP packets already roughly follow this pattern but perhaps a > generic message packet is also required. > > *Ledgers and Trustlines* > > For some time there has been a debate about what constitutes the nodes and > what the edges in the Interledger graph. As we've begun to appreciate the > various different forms a line of trust between two peers can take it's > become clear that ledgers are not actually core to the protocol (despite > the name). If you consider senders, receivers and connectors to be the > nodes, then edges are simply lines of trust between any two nodes. > > In other words the Interledger is made of nodes that are connected via > financial agreements of some form that allow for two nodes to transfer > value between one another. This agreement may or may not be underwritten by > a ledger that supports conditional transfers. Where there is a ledger that > both parties trust to perform conditional transfers correctly the parties > no longer need to trust one another (they trust the ledger). > > The Interledger works because not only does it define a universal address > space for this network, it also defines a universal signature scheme for > payment requests and receipts that can be leveraged by individual > trustlines on the route of a payment, for conditional transfers between two > peers. > > When two disconnected nodes wish to setup a payment they exchange data so > that the sender has, at a minimum, the address of the receiver, a condition > that the receiver can fulfill and the amount (in the receiver's currency) > that the receiver must receive. Next the sender finds a peer to send a > local transfer to, to initiate the end-to-end payment. They package all of > the end-to-end data in an ILP packet and make the local transfer (attaching > the packet or sending it to the peer separately). > > The terms of the local transfer are: "Show me the signature from the > receiver that proves they were paid and you get the proceeds of the local > transfer." > > These terms can be enforced in a variety of ways, one of which is by > making the transfer on a ledger that understands the condition and > fulfillment format and supports conditional payments. This protects the > sender from their upstream peer in the case where they are unable to > produce the fulfillment but still want to claim the proceeds of the > transfer. i.e. It simply changes who the sender trusts (the ledger instead > of the peer) > > How the ILP packet is transferred to the peer and how the transfer is > setup on the ledger *are very different concerns*. It is a mistake to > assume that the communication mechanism between peers is the creation of > the transfer on the ledger itself. I believe that some of the confusion > around this comes from the design of 5-bells ledger where these are the > same thing. > > Consider the following setup where the ledger supports conditional > transfers but does not support notifications as an example. > > Peer A > Ledger Peer B > > | -- LocalTransfer(LocalAmount,Condition) --> > | | > | <----------- Prepared --------------------- | > | > | -------------- ILP Payment Request (ILP Address, RemoteAmount, > Condition) --------------------> | > | | <--------- Check for > pending transfer------------ | > | <----------------------------------------- Ack > ------------------------------------------------ | > | - Poll for completed transfer (Optional) -> > | | > | | > | --> Transfer > | | > | <-- Fulfillment > | | <---------- Submit > fulfillment------------------- | > | <------------------------- ILP Payment Response(Fulfillment) > ---------------------------------- | > | - Confirm completed transfer (Optional) --> > | | > > Note how the communication between peers, carrying the ILP packet, does > not go through the ledger. Also, note how the ledger doesn't need to > understand anything about ILP other than supporting the universal signature > format (conditions and fulfillments). For simplicity this example excluded > expiry but these could just as easily be included alongside the condition > in the direct communication between the peers (i.e. in the ILP packet). > > The expiry in the packet is very similar to the TTL in an IP packet. > Theoretically it can be modified at each hop to a value that the local > sender considers safe for the outgoing local transfer and the trustline on > which it is sent. > > Summary: > > - ILP is not about ledgers, it is about trustlines between nodes/hosts. > - A trustline may be underwritten by a ledger to allow nodes to establish > a trustline-by-proxy where they trust the ledger and not their peer. This > is possible if the ledger supports conditional payments using ILP-style > conditions. > - The protocol should differentiate between the operation of preparing a > transfer on a ledger and the operation of passing an ILP packet from one > peer to another. > > Proposal: > - The condition and timeout should be included in the ILP payment packet. > - Where the fulfillment is a signature over the packet these can be zero'd > out first as with the checksum in an IP packet. > > Look forward to your thoughts! > > > > > > > > > _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger > -- Evan Schwartz Software Engineer Managing Director of Ripple Luxembourg --001a113f2a489f6c6b0556bc292b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this thread is going to get extremely unwieldy but= here goes:

>=C2=A0- All interledger layer messages should be ILP packets (including fulfill= ments) and be capable of carrying higher layer protocol payloads.

Interledger has higher requirements than ILP for the= lowest layer, specifically because we are carrying money and not just data= . One of the requirements is being able to transmit a 32-byte fulfillment b= ack along the same path that carried the payment originally. If we expect t= his of the lower layer, I don't see a point in putting the fulfillment = into an ILP packet and transmitting it as Interledger data along the same p= ath. All ledger-layer protocols will need to interpret the fulfillment pass= ed in their protocol, not the one passed through the Interledger layer.

>=C2=A0- While= it may make sense to split the interledger payment and interledger quoting= protocols into new higher level protocols that seems like an unnecessary a= bstraction. Instead the packet definitions should just have some consistenc= y and probably a common base/header.

Th= e current protocols effectively have this header but it isn't separated= out. There are two fields in the request header: type and destination addr= ess. There is one field in the response header: type. I don't think it = makes that much of a big difference to separate these fields if all of the = fields in that packet need to be interpreted together (for example, you can= 't understand a quote request if you strip off the destination address)= .

>=C2=A0- We should define two base ILP packet types: request and r= esponse.

Unless this adds some substantive benefit or new fields I don't thin= k it's worth breaking all of the formats we have just to rearrange thin= gs.

>=C2=A0= - ILP is not about ledgers, it is about trustlines between nodes/hosts.

A ledger is any system that= tracks accounts and balances. When you use a trustline all of your message= s still need to go through an accounting system (such as the plugin in the = JS implementation) and then on to the other program logic. In that case, th= e plugin or whatever is doing the accounting is the ledger. Digital value i= s always tracked in ledgers, so I think it does make sense to think of this= as the base layer. The reason to abstract the functionality you expect fro= m the ledger layer is precisely so you can handle it in different ways, dep= ending on what the underlying systems provide.

I s= ee 3 ways to think of the layer(s) underpinning ILP:
  1. The "Ledger Layer" provides both messaging capabilit= ies and some type of HT= LA
  2. There are separate plugins for messaging and for tran= sfers and when you peer with someone you have to agree on a plugin for each=
  3. We standardize the messaging part and say that all goes over IP an= d then just have more minimal plugins for the on-ledger settlements
    4. Number 1 is what we have and I think that still makes the most sense= .

>=C2=A0- The protocol should differentiate between the operation of preparing = a transfer on a ledger and the operation of passing an ILP packet from one = peer to another.

The pro= tocol assumes your conditional transfer is underpinned by some HTLA. It doesn't care wheth= er that's on-ledger or not.

>=C2=A0- The condition and timeout should be included = in the ILP payment packet.

I strongly disag= ree with this. We had this debate a year ago and I was on your side but was= convinced that this is not a good idea.

The layer= below ILP must be capable of doing conditional transfers based on sha256 h= ashlocks with 32-byte preimages. As a result, the original condition and th= e corresponding preimage MUST be expressed in that layer. Then the question= is whether we should also include it in the packet that is forwarded. What= ultimately convinced me is the following: All connectors MUST ignore the c= ondition if it is in the packet, because they are only guaranteed their mon= ey back if they use the same condition from the incoming transfer they got.= Also, the receiver will need to take out the condition in order to hash th= e packet for PSK or IPR. So basically, no one wants the condition in there.= It feels like it ought to be in there, but literally none of the parties w= ant the extra 32 bytes in there.

The reason the ti= meout should not be in there is that there isn't a single timeout for t= he payment. There are multiple separate timeouts for each of the bilateral = transfers. Those must go in the individual transfers and there is no sensib= le value to put in the Interledger packet.

On Mon, Aug 14, 2017 at 12:58 PM Adrian Hope-Bai= lie <adrian@hopebailie.com&= gt; wrote:
I have had an ongoing = debate with a number of people about the correct way to architect the proto= col layering for Interledger. This has been an excellent discussion and I&#= 39;ve made some valuable realizations (and conceded some mistakes on my par= t) along the way but I am still convinced that we have some errors in our a= rchitecture which are making the whole stack unwieldy and making it difficu= lt to progress on designs for other layers.

There is a se= nse that we should not be changing the core packet definitions any more but= I'm not sure what justifies this. We have a limited number of implemen= tations and the specifics of the packet formats and encapsulation are confi= ned to a single library in both. Furthermore, the fundamentals of the proto= col don't change, just the packet formats and layering to better reflec= t the protocol and not be influenced so strongly by the implementation.
=

This is my attempt to explain my rationale and solicit= feedback from the community. Hopefully we can come to consensus on the rig= ht design (ignoring concerns about X is frozen; or "we said we aren= 9;t going to change Y anymore" or this will break Z). Once we have a d= esign we consider correct, let's count the cost and decide if it's = a v2 or we can implement it now.

Protocol Layering: Request= /Response at the core

Protocol layering is a mature patter= n. The layering is achieved through encapsulation. A packet contains header= s and a payload, and the payload is the packet of the next layer up.
In the Internet stack the internetworking layer is the IP layer. Packets = are addressed using IP addresses and layers above rely on these addresses t= o introduce messaging semantics. Layers below are host-to-host protocols th= at carry the IP packet from one host to another. All data in the host-to= -host protocol is discarded when the packet is de-framed and re-framed = for the next hop.

The internetworking layer in the ILP stack i= s the Interledger layer. At this layer packets are used to carry payments, = quotes and errors and are addressed using an Interledger Address. Similar t= o IP there are host-to-host protocols that exist below ILP and carry the IL= P packets over each hop and higher layer protocols that carry end-to-end da= ta encapsulated in the payload of the ILP packet.

Current= ly, ILP requires that data outside the packet be passed along with the pack= et instead of inside the packet, requiring special treatment of specific ho= ts-to-host data and making it very difficult to add/change this data in fut= ure.

A critical difference between IP and ILP is in= the messaging semantics. IP has none. A packet simply contains a source an= d destination address and higher layers use these (and introduce additional= properties such as ports) to establish reliable connections, sessions etc.= In contrast, ILP only works if ILP packets exist as request/response pairs= and the response packets follow exactly the same route as the request pack= ets.

As such an ILP request packet has no source address, as t= his is useless. A response packet can't simply be addressed to the sour= ce of the request and sent. A response packet must retrace the route of = the request.

One may argue (as I did before) that a request/resp= onse pair should then have a unique end-to-end identifier that nodes can us= e to associate a request with it's original response, however there is = a danger in relying on this identifier as it could be manipulated to cause = responses to fail. If you can't rely on it, why have it at all?

= As such, a node at the Interledger layer MUST maintain state and be able to= , not only match request/response pairs at the host-to-host layer but also,= match an incoming request/response pair to an outgoing request/response= pair.

How a host does this not defined i= n the protocol but it means that at a minimum the host-to-host protocols mu= st allow request/response pairs to be matched AND uniquely identified.
<= br>
Example:

When Host B receives Response A from Ho= st C it must pass that on as Response 1 to Host A. This would have to be re= corded during the routing of Request 1 to Request A.

Host A =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Host B=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Host C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 --- Request 1 -->=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 --=C2=A0 = Request A -->
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-- Response 1 --=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 <-- Response A --

In protocol stacks like IP and ILP the internetworking layer is the glue b= etween lower host-to-host layers and higher end-to-end layers. To avoid ove= rloading the internetworking packets themselves it should be possible to en= capsulate higher level protocol packets in the internetworking layer payloa= d.

Another unique feature of ILP (where it differs f= rom IP) is that some Interledger packets carry value. You can look at this = two ways:
1. The ILP payment packet carries value end-to-end.=
2. The ILP payment packet carries data end-to-end but the se= nder pays for this.

There are two basic request types in ILP, those = that carry data and those that carry both data and value.

For all request types there is a valid response type but the response coul= d also be an error. Example: the response to a payment is a fulfillment, th= e response to a quote by source amount request is a quote by source amount = response.

In summary:
- ILP depends on requ= est/response semantics at it's core (these are a requirement of the int= ernetworking layer itself, not just higher level protocols).
- As such,= the internetworking layer packets must be either a request or a response a= nd the protocol should define which responses are valid for which requests = and all requests should have a response.
- There are two prim= ary request packet types (a request carrying data and a request carrying da= ta and value).
- There are two primary response types, a succ= ess and failure response. The success responses are sub-typed to match the = sub-type of the request, however the error response could be returned for a= ny request.

Proposal:
- All interledger lay= er messages should be ILP packets (including fulfillments) and be capable o= f carrying higher layer protocol payloads.
- While it may mak= e sense to split the interledger payment and interledger quoting protocols = into new higher level protocols that seems like an unnecessary abstraction.= Instead the packet definitions should just have some consistency and proba= bly a common base/header.
- We should define two base ILP pac= ket types: request and response.
- A payment packet should ex= tend the request type and fulfillment and error should extend response.
=
- The ILQP packets already roughly follow this pattern but perha= ps a generic message packet is also required.

= Ledgers and Trustlines

For some time there has bee= n a debate about what constitutes the nodes and what the edges in the Inter= ledger graph. As we've begun to appreciate the various different forms = a line of trust between two peers can take it's become clear that ledge= rs are not actually core to the protocol (despite the name). If you conside= r senders, receivers and connectors to be the nodes, then edges are simply = lines of trust between any two nodes.

In other words the = Interledger is made of nodes that are connected via financial agreements of= some form that allow for two nodes to transfer value between one another. = This agreement may or may not be underwritten by a ledger that supports con= ditional transfers. Where there is a ledger that both parties trust to perf= orm conditional transfers correctly the parties no longer need to trust one= another (they trust the ledger).

The Interledger works because not = only does it define a universal address space for this network, it also def= ines a universal signature scheme for payment requests and receipts that ca= n be leveraged by individual trustlines on the route of a payment, for cond= itional transfers between two peers.

When two disconnecte= d nodes wish to setup a payment they exchange data so that the sender has, = at a minimum, the address of the receiver, a condition that the receiver ca= n fulfill and the amount (in the receiver's currency) that the receiver= must receive. Next the sender finds a peer to send a local transfer to, to= initiate the end-to-end payment. They package all of the end-to-end data i= n an ILP packet and make the local transfer (attaching the packet or sendin= g it to the peer separately).

The terms of the local tran= sfer are: "Show me the signature from the receiver that proves they we= re paid and you get the proceeds of the local transfer."

=
These terms can be enforced in a variety of ways, one of which is by m= aking the transfer on a ledger that understands the condition and fulfillme= nt format and supports conditional payments. This protects the sender from = their upstream peer in the case where they are unable to produce the fulfil= lment but still want to claim the proceeds of the transfer. i.e. It simply = changes who the sender trusts (the ledger instead of the peer)

How the ILP packet is transferred to the peer and how the transfer is= setup on the ledger are very different concerns. It is a mistake to= assume that the communication mechanism between peers is the creation of t= he transfer on the ledger itself. I believe that some of the confusion arou= nd this comes from the design of 5-bells ledger where these are the same th= ing.

Consider the following setup where the ledger suppor= ts conditional transfers but does not support notifications as an example.<= br>
Peer A = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Ledger=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Peer B
=
=C2=A0 | -- LocalTransf= er(LocalAmount,Condition) --> |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0 | <----------- Prepared -------------------= -- |=C2=A0=C2=A0=C2= =A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0 | -------------- ILP Payment Request (ILP Address, = RemoteAmount, Condition) --------------------> |=C2=A0
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | <--------- Che= ck for pending transfer------------ |
=C2=A0 | <---= -------------------------------------- Ack --------------------------------= ---------------- |= =C2=A0
=C2=A0 | - Poll for completed transfer (Optio= nal) -> |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | --> Transfer
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | &= lt;-- Fulfillment
=
=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | <---------- Submit fulfillment------------------- |
= =C2=A0 | <--------------= ----------- ILP Payment Response(Fulfillment) -----------------------------= ----- |=C2=A0
=C2=A0 | - Confirm completed tr= ansfer (Optional) --> |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |

Note how the communi= cation between peers, carrying the ILP packet, does not go through the ledg= er. Also, note how the ledger doesn't need to understand anything about= ILP other than supporting the universal signature format (conditions and f= ulfillments). For simplicity this example excluded expiry but these could j= ust as easily be included alongside the condition in the direct communicati= on between the peers (i.e. in the ILP packet).

The expiry in the pac= ket is very similar to the TTL in an IP packet. Theoretically it can be mod= ified at each hop to a value that the local sender considers safe for the o= utgoing local transfer and the trustline on which it is sent.

=
Summary:

- ILP is not about ledgers, it is about tru= stlines between nodes/hosts.
- A trustline may be underwritten by a ledg= er to allow nodes to establish a trustline-by-proxy where they trust the le= dger and not their peer. This is possible if the ledger supports conditiona= l payments using ILP-style conditions.
- The protocol should = differentiate between the operation of preparing a transfer on a ledger and= the operation of passing an ILP packet from one peer to another.

Proposal:
- The condition and timeout should be incl= uded in the ILP payment packet.
- Where the fulfillment is a = signature over the packet these can be zero'd out first as with the che= cksum in an IP packet.

Look forward to your th= oughts!








_______________________________________________
Ledger mailing list
Ledger@ietf.org https://www.ietf.org/mailman/listinfo/ledger
--

Evan Schwartz

Sof= tware Engineer
Managing Director of Ripple Luxemb= ourg
--001a113f2a489f6c6b0556bc292b-- From nobody Tue Aug 15 03:04:41 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C122F1320CC for ; Tue, 15 Aug 2017 03:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 4DU11Itx603K for ; Tue, 15 Aug 2017 03:04:36 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::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 A4806132026 for ; Tue, 15 Aug 2017 03:04:35 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id d124so1263466vkf.2 for ; Tue, 15 Aug 2017 03:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W4fZz0jh07/oWb/nfe2ySwr9NU58YJNSpAo5TdAJWv0=; b=RShR8PEvXDltt1Yn+JSr05yIbozyAoWrOGsuuE3sYWiEb1s1MNmyPIOvLbXf3Rj+ya vDzcSgCWUMIeyTlWeIZ8HR4ePWRww/J9NG2oJrT7MdI8KSyAQuaQAZ9yeyu5Iv+CSvbe AAqhWM8zy4kqpVqB/JOfKGYYEueacMVua4J4s= 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=W4fZz0jh07/oWb/nfe2ySwr9NU58YJNSpAo5TdAJWv0=; b=kSnssH1EI3p/m1/oygwfOqxkTrVLRjB0VTHC9N0Yx2HiWbZ5O1D3DZ6boWyvFMQeQn gypuQKG6vJ3z2Wl5yG5xIqpR4R8HFa6LK210CnjE2+yk/L49R7607FetBSvTgw6TK8zf TTmbe3yX0CCaU6zSlbqRs5H3kDMuucHWb+fcEDgtspR2exd5Acyh7ieuRDQsN4huSLfp n3NZOxAinqXR5ihqL/h+XWQWshg5Eop3lQpPOzKNE/mxdWcn6mLPF/5YXNVKSemnxh0P sd1yBskMohw+k8VWrjDTiP5Re7Ho4rWIt84isfFV3YWyccJpS1YOKh9ZjrDrlQ5sfnxH bStw== X-Gm-Message-State: AHYfb5iQXpUkOTh5K2LnziPWzymE/ioxkRFpd5PyfB0cD084hqfpszUc QzOFXXWxddKXyIODWnLHgvrHd7AkxbR+tKg= X-Received: by 10.31.34.68 with SMTP id i65mr14846019vki.193.1502791474324; Tue, 15 Aug 2017 03:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.62.90 with HTTP; Tue, 15 Aug 2017 03:04:33 -0700 (PDT) In-Reply-To: References: From: Adrian Hope-Bailie Date: Tue, 15 Aug 2017 12:04:33 +0200 Message-ID: To: Evan Schwartz Cc: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a113dc8b4ffd7d10556c7e7ed" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 10:04:40 -0000 --001a113dc8b4ffd7d10556c7e7ed Content-Type: text/plain; charset="UTF-8" On 14 August 2017 at 22:03, Evan Schwartz wrote: > I think this thread is going to get extremely unwieldy but here goes: > > > - All interledger layer messages should be ILP packets (including > fulfillments) and be capable of carrying higher layer protocol payloads. > > Interledger has higher requirements than ILP for the lowest layer, > specifically because we are carrying money and not just data. One of the > requirements is being able to transmit a 32-byte fulfillment back along the > same path that carried the payment originally. If we expect this of the > lower layer, I don't see a point in putting the fulfillment into an ILP > packet and transmitting it as Interledger data along the same path. All > ledger-layer protocols will need to interpret the fulfillment passed in > their protocol, not the one passed through the Interledger layer. > This is not correct. There is no requirement on ledger layer protocols to transmit or understand the fulfillment. You are looking at this through the lens of existing implementations from the bottom up instead of starting at the interledger layer. The primary function of the condition and fulfillment is as a signed end-to-end receipt. If the sender agrees a condition with a receiver and then gets back the valid fulfillment they don't care what happened in the middle. The receiver has signed a receipt saying they have their money. The value of using a standard for the receipt and signature is that each transfer along the way CAN re-use it. One the one hand you can have a transfer between two peers that have zero trust and the ledger they use supports conditional payments completely. On the other extreme you can have two peers that have a full trust and ignore the condition and fulfillment completely. The ledger layer protocols carry ILP packets. Payment requests and either fulfillment or error responses. If a ledger layer protocol wants to use the condition and fulfillment for their own operations they can extract these from the ILP packets and use them. > > - While it may make sense to split the interledger payment and > interledger quoting protocols into new higher level protocols that seems > like an unnecessary abstraction. Instead the packet definitions should just > have some consistency and probably a common base/header. > > The current protocols effectively have this header but it isn't separated > out. There are two fields in the request header: type and destination > address. There is one field in the response header: type. I don't think it > makes that much of a big difference to separate these fields if all of the > fields in that packet need to be interpreted together (for example, you > can't understand a quote request if you strip off the destination address). > I agree that we don't HAVE to explicitly separate them out but I think ti would make it clearer how the stack is architected if there was a header that was consistent across all packets. Currently the only thing that is consitent across all ILP packets is that they are defined int he same file. > > > - We should define two base ILP packet types: request and response. > > Unless this adds some substantive benefit or new fields I don't think it's > worth breaking all of the formats we have just to rearrange things. > The goal of this exercise is to tease out the best design and ignore the cost of change until we can compare the results with the current design. > > > - ILP is not about ledgers, it is about trustlines between nodes/hosts. > > A ledger is any system that tracks accounts and balances. When you use a > trustline all of your messages still need to go through an accounting > system (such as the plugin in the JS implementation) and then on to the > other program logic. > As above, this is incorrect. There is no requirement for "all messages to go through an accounting system". Since designing the first implementation of 5-bells ledger we have assumed that passing the ILP packet MUST be done by the ledger because that is how we implemented it. But that is not true. It is perfectly valid for the passing of an ILP packet from one peer to another to be simply an exchange of data. The receiving peer makes a decision about whether or not to forward the packet based on the current financial position they have with the sending peer. It is convenient if the ledger that records the net positions of the peers also forwards the messaging and even better if it natively supports conditional payments and can use the condition and the fulfillment from the ILP packet for those but that's all it is, convenient. > In that case, the plugin or whatever is doing the accounting is the > ledger. Digital value is always tracked in ledgers, so I think it does make > sense to think of this as the base layer. The reason to abstract the > functionality you expect from the ledger layer is precisely so you can > handle it in different ways, depending on what the underlying systems > provide. > > I see 3 ways to think of the layer(s) underpinning ILP: > > 1. The "Ledger Layer" provides both messaging capabilities and some > type of HTLA > > 2. There are separate plugins for messaging and for transfers and when > you peer with someone you have to agree on a plugin for each > 3. We standardize the messaging part and say that all goes over IP and > then just have more minimal plugins for the on-ledger settlements > > Number 1 is what we have and I think that still makes the most sense. > I think you're confusing implementation details and defining of interfaces with definition of a protocol stack. The only differences between the tree examples you have above is in implementation. >From the perspective of the Interledger Protocol the implementation of the lower layers is not important, that's the whole point of layering. By forcing important aspects of ILP like the condition, fulfillment and expiry down into those layers you muddy the waters and we now have to standardize those protocols too. Instead we should just be defining the functions they must provide and then leave it up to implementations to provide those functions. I know we want to define a standard to bootstrap the system (CLP) but that's misleading us into thinking it's an essential part of the stack. It's perfectly valid for two peers to not use CLP and still be part of the Interledger. That said, you raise an interesting consideration about the layers below ILP and actually I think it makes sense to split these. We keep trying to force messaging through the ledger layer and actually that's the wrong place to put it if we can split the ledger layer into a messaging layer and a ledger layer. That way we can stop trying to think of all HLTAs as ledgers. A thought, why not use sub-layers as is common in other stacks: 1. Link layer: Layer upon which two peers that have a direct link, or participate in the same payment network, communicate 2. Transfer/ ledger: Layer on which financial positions between two peers are recorded This reflects the already emerging HTLA model and many of our existing plugins and ledger integrations. Link Layer: XRP Paychan, Lightning Ledger Layer: XRP Ledger, Bitcoin This doesn't prevent us from defining a standard binary protocol that defines all of the operations for both layers (like CLP) but I see value in distinguishing between these two. > > > - The protocol should differentiate between the operation of preparing > a transfer on a ledger and the operation of passing an ILP packet from one > peer to another. > > The protocol assumes your conditional transfer is underpinned by some HTLA > . > It doesn't care whether that's on-ledger or not. > What do you mean when you say "the protocol"? In my statement I am referring to ILP. My point above being that ILP expects ILP packets to be passed from peer to peer but has no expectations about transfers. It's perfectly legal (from an ILP perspective) for two peers to exchange ILP packets with no transfers. Clearly if a node routes a packet on and has no incoming transfer it's going to lose money but that's a consideration for that node. It doesn't affect anyone else in the chain. ILP doesn't assume anything about transfers at all, let alone conditional transfers. It provides useful semantics for conditional transfers to be used by two peers to transact as part of a larger ILP payment. > > > - The condition and timeout should be included in the ILP payment > packet. > > I strongly disagree with this. We had this debate a year ago and I was on > your side but was convinced that this is not a good idea. > Yes, I recall this and I'm sorry I didn't push harder on this point. Unfortunately I think the decision to pull it out of the packet is mostly driven by how our prototypes were implemented rather than good architecture. > > The layer below ILP must be capable of doing conditional transfers based > on sha256 hashlocks with 32-byte preimages. > This is not true and I think it would be useful for us to agree on this as this seems to be the argument I am coming up against most often. The peers participating in a transfer that is part of an ILP payment may wish to use conditional transfers as a way to enforce their agreement but this is not a requirement of the protocol. The agreement between any two peers is: "I will pay you X if you can provide a receipt that Y was paid Z before T". ILP provides a standard for expressing this agreement so that these can be chained together BUT it is not a requirement that every agreement in the chain uses the condition, and fulfillment provided at the ILP layer. > > As a result, the original condition and the corresponding preimage MUST be > expressed in that layer. > As I have shown above, this is not true. > Then the question is whether we should also include it in the packet that > is forwarded. What ultimately convinced me is the following: All connectors > MUST ignore the condition if it is in the packet, because they are only > guaranteed their money back if they use the same condition from the > incoming transfer they got. > Here is where the layering is being corrupted. All connectors MUST inspect the condition in the ILP packet as part of their decision to route the packet or not. When the local transfer module of the connectors stack passes the ILP packet up to the ILP module it should indicate the properties of the incoming transfer that carried the packet. This is essential firstly so that the routing logic in the ILP module can record the incoming transfer identifier so it is able to use the correct response id when it passes back the fulfillment or error. The other properties that the ILP module should look at are the condition and expiry on the incoming transfer. If the incoming route uses conditional transfers and these are supposed to match the condition and expiry in the ILP packet then the ILP module should compare them and reject the packet if: a) the conditions don't match OR b) the expiry is too short We should still discuss if the expiry should be set by the sender and left unchanged or used like a TTL and decremented by each node. > Also, the receiver will need to take out the condition in order to hash > the packet for PSK or IPR. > This is completely normal. Zeroing a checksum field in a header before calculating the checksum is VERY common precisely because it's long been accepted that the right place to put that data is in the headers and the work of zero'ing it out to calculate the checksum (or signature in our case) is not material. > So basically, no one wants the condition in there. It feels like it ought > to be in there, but literally none of the parties want the extra 32 bytes > in there. > "Nobody wants it there" is a terrible reason to abandon the correct design. The whole purpose of a good architecture is you accept that there may be cases in future that haven't been considered now so designing just for the known cases is a bad idea. Good architecture is not the same as optimization. Taking stuff out (even when it feels wrong) to save a few bytes is a good sign that it's a bad idea. > > The reason the timeout should not be in there is that there isn't a single > timeout for the payment. There are multiple separate timeouts for each of > the bilateral transfers. Those must go in the individual transfers and > there is no sensible value to put in the Interledger packet. > As above, this is somewhat equivalent to the TTL in an IP packet. I'm open to discussing if it should be a fixed value set by the sender where each node uses their own value but has the sender-defined value as a reference or it is actually decremented at each hop. Either way, this is part of ILP not the ledger layer just like the condition and fulfillment. It may be used by the ledger layer but that's implementation specific. It belongs in the ILP packet. > > > --001a113dc8b4ffd7d10556c7e7ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 14 August 2017 at 22:03, Evan Schwartz <evan@ripple.com> wrote:
I think this th= read is going to get extremely unwieldy but here goes:
>=C2=A0- All interle= dger layer messages should be ILP packets (including fulfillments) and be c= apable of carrying higher layer protocol payloads.

Interledger has higher requirements than ILP for the lowest = layer, specifically because we are carrying money and not just data. One of= the requirements is being able to transmit a 32-byte fulfillment back alon= g the same path that carried the payment originally. If we expect this of t= he lower layer, I don't see a point in putting the fulfillment into an = ILP packet and transmitting it as Interledger data along the same path. All= ledger-layer protocols will need to interpret the fulfillment passed in th= eir protocol, not the one passed through the Interledger layer.
=

This is not correct. There is no requirement on= ledger layer protocols to transmit or understand the fulfillment. You are = looking at this through the lens of existing implementations from the botto= m up instead of starting at the interledger layer.

The primary function of the condition and fulfillment is a= s a signed end-to-end receipt. If the sender agrees a condition with a rece= iver and then gets back the valid fulfillment they don't care what happ= ened in the middle. The receiver has signed a receipt saying they have thei= r money.

The value of using a stand= ard for the receipt and signature is that each transfer along the way CAN r= e-use it. One the one hand you can have a transfer between two peers that h= ave zero trust and the ledger they use supports conditional payments comple= tely. On the other extreme you can have two peers that have a full trust an= d ignore the condition and fulfillment completely.
=C2=A0
The ledger layer protocols carry ILP packets. P= ayment requests and either fulfillment or error responses. If a ledger laye= r protocol wants to use the condition and fulfillment for their own operati= ons they can extract these from the ILP packets and use them.


>=C2=A0<= span style=3D"color:rgb(33,33,33)">- While it may make sense to split the i= nterledger payment and interledger quoting protocols into new higher level = protocols that seems like an unnecessary abstraction. Instead the packet de= finitions should just have some consistency and probably a common base/head= er.

<= /span>
The current protocols effect= ively have this header but it isn't separated out. There are two fields= in the request header: type and destination address. There is one field in= the response header: type. I don't think it makes that much of a big d= ifference to separate these fields if all of the fields in that packet need= to be interpreted together (for example, you can't understand a quote = request if you strip off the destination address).

I agree that we don't HAVE to explicitly sep= arate them out but I think ti would make it clearer how the stack is archit= ected if there was a header that was consistent across all packets. Current= ly the only thing that is consitent across all ILP packets is that they are= defined int he same file.
=C2=A0

>=C2= =A0- We should define two base I= LP packet types: request and response.

Unless this ad= ds some substantive benefit or new fields I don't think it's worth = breaking all of the formats we have just to rearrange things.

The goal of this exercise is to tease out th= e best design and ignore the cost of change until we can compare the result= s with the current design.
=C2=A0

>=C2=A0- ILP is not about ledgers, it is about t= rustlines between nodes/hosts.

A ledger is any system that tracks accounts and balances. Whe= n you use a trustline all of your messages still need to go through an acco= unting system (such as the plugin in the JS implementation) and then on to = the other program logic.

As ab= ove, this is incorrect. There is no requirement for "all messages to g= o through an accounting system".

Since designing the= first implementation of 5-bells ledger we have assumed that passing the IL= P packet MUST be done by the ledger because that is how we implemented it. = But that is not true. It is perfectly valid for the passing of an ILP packe= t from one peer to another to be simply an exchange of data.

<= div>The receiving peer makes a decision about whether or not to forward the= packet based on the current financial position they have with the sending = peer.

It is convenient if the ledger that reco= rds the net positions of the peers also forwards the messaging and even bet= ter if it natively supports conditional payments and can use the condition = and the fulfillment from the ILP packet for those but that's all it is,= convenient.

=C2=A0
<= div dir=3D"ltr">
In that case, the plugin or whatever is doing the acco= unting is the ledger. Digital value is always tracked in ledgers, so I thin= k it does make sense to think of this as the base layer. The reason to abst= ract the functionality you expect from the ledger layer is precisely so you= can handle it in different ways, depending on what the underlying systems = provide.

I see 3 ways to think of the layer(s) und= erpinning ILP:
  1. The "Ledger Layer&qu= ot; provides both messaging capabilities and some type of HTLA
    2. There are separate plugins for messaging and for transfers and when you p= eer with someone you have to agree on a plugin for each
  2. We standard= ize the messaging part and say that all goes over IP and then just have mor= e minimal plugins for the on-ledger settlements
Number 1 is w= hat we have and I think that still makes the most sense.
<= /blockquote>
I think you're confusing implementation details and def= ining of interfaces with definition of a protocol stack. The only differenc= es between the tree examples you have above is in implementation.

Fr= om the perspective of the Interledger Protocol the implementation of the lo= wer layers is not important, that's the whole point of layering. By for= cing important aspects of ILP like the condition, fulfillment and expiry do= wn into those layers you muddy the waters and we now have to standardize th= ose protocols too. Instead we should just be defining the functions they mu= st provide and then leave it up to implementations to provide those functio= ns.

I know we want to define a stan= dard to bootstrap the system (CLP) but that's misleading us into thinki= ng it's an essential part of the stack. It's perfectly valid for tw= o peers to not use CLP and still be part of the Interledger.

That said, = you raise an interesting consideration about the layers below ILP and actua= lly I think it makes sense to split these.

We keep trying= to force messaging through the ledger layer and actually that's the wr= ong place to put it if we can split the ledger layer into a messaging layer= and a ledger layer. That way we can stop trying to think of all HLTAs as l= edgers.

A thought, why not use sub-layers as is common in= other stacks:

1. Link layer: Layer upon which two peers = that have a direct link, or participate in the same payment network, commun= icate
2. Transfer/ ledger: Layer on which financial positions= between two peers are recorded

This reflects the already emerging H= TLA model and many of our existing plugins and ledger integrations.
Link Layer: XRP Paychan, Lightning
Ledger Layer: XRP L= edger, Bitcoin

This doesn't prevent us fro= m defining a standard binary protocol that defines all of the operations fo= r both layers (like CLP) but I see value in distinguishing between these tw= o.
=C2=A0

>=C2=A0- The protocol should differentiate between the operation of prep= aring a transfer on a ledger and the operation of passing an ILP packet fro= m one peer to another.

The protocol assumes your conditional transfer is underpinned by some= HTLA= . It doesn't care whether that's on-ledger or not.
<= /blockquote>

What do you mean when you say "the protocol= "? In my statement I am referring to ILP.
My point above being tha= t ILP expects ILP packets to be passed from peer to peer but has no expecta= tions about transfers.

It's per= fectly legal (from an ILP perspective) for two peers to exchange ILP packet= s with no transfers. Clearly if a node routes a packet on and has no incomi= ng transfer it's going to lose money but that's a consideration for= that node. It doesn't affect anyone else in the chain.

ILP doesn't assume anything about transfers at= all, let alone conditional transfers. It provides useful semantics for con= ditional transfers to be used by two peers to transact as part of a larger = ILP payment.
=C2=A0

>= =C2=A0- The condition and timeout shoul= d be included in the ILP payment packet.

=
I strongly disagree with this. We had this debate a year ago and I was= on your side but was convinced that this is not a good idea.

Yes, I recall this and I'm sorry I didn&= #39;t push harder on this point. Unfortunately I think the decision to pull= it out of the packet is mostly driven by how our prototypes were implement= ed rather than good architecture.
<= div dir=3D"ltr">

The layer below ILP must be capable of = doing conditional transfers based on sha256 hashlocks with 32-byte preimage= s.

This is not true and I thin= k it would be useful for us to agree on this as this seems to be the argume= nt I am coming up against most often. The peers participating in a transfer= that is part of an ILP payment may wish to use conditional transfers as a = way to enforce their agreement but this is not a requirement of the protoco= l.

The agreement between any two peers is: "I will p= ay you X if you can provide a receipt that Y was paid Z before T".
=
ILP provides a standard for expressing this agreement so that th= ese can be chained together BUT it is not a requirement that every agreemen= t in the chain uses the condition, and fulfillment provided at the ILP laye= r.

=C2=A0
= As a result, the original condition and the corresponding preimage MUST be = expressed in that layer.

As I = have shown above, this is not true.
=C2=A0
Then the question is whether we sho= uld also include it in the packet that is forwarded. What ultimately convin= ced me is the following: All connectors MUST ignore the condition if it is = in the packet, because they are only guaranteed their money back if they us= e the same condition from the incoming transfer they got.

Here is where the layerin= g is being corrupted.

All connectors MUST inspect the condition in t= he ILP packet as part of their decision to route the packet or not.
When the local transfer module of the connecto= rs stack passes the ILP packet up to the ILP module it should indicate the = properties of the incoming transfer that carried the packet.
This is essential firstly so that the routing logic i= n the ILP module can record the incoming transfer identifier so it is able = to use the correct response id when it passes back the fulfillment or error= .
The other properties that the ILP module should look at are the condit= ion and expiry on the incoming transfer.

If the incoming route uses conditional transfers and = these are supposed to match the condition and expiry in the ILP packet then= the ILP module should compare them and reject the packet if:
a) the conditions don't match OR
b) the expiry is too sh= ort

We should still discuss if the expiry should be set b= y the sender and left unchanged or used like a TTL and decremented by each = node.
=C2=A0
Also, the receiver will need to take out the condition in order t= o hash the packet for PSK or IPR.

<= div>This is completely normal. Zeroing a checksum field in a header before = calculating the checksum is VERY common precisely because it's long bee= n accepted that the right place to put that data is in the headers and the = work of zero'ing it out to calculate the checksum (or signature in our = case) is not material.
=C2=A0
So basically, no one wants the condition in ther= e. It feels like it ought to be in there, but literally none of the parties= want the extra 32 bytes in there.

<= div>"Nobody wants it there" is a terrible reason to abandon the c= orrect design. The whole purpose of a good architecture is you accept that = there may be cases in future that haven't been considered now so design= ing just for the known cases is a bad idea.

Good architec= ture is not the same as optimization. Taking stuff out (even when it feels = wrong) to save a few bytes is a good sign that it's a bad idea.
=C2=A0
The reason the timeout should not be in there is that there isn= 't a single timeout for the payment. There are multiple separate timeou= ts for each of the bilateral transfers. Those must go in the individual tra= nsfers and there is no sensible value to put in the Interledger packet.
=C2=A0
As above, this is somewhat equiv= alent to the TTL in an IP packet. I'm open to discussing if it should b= e a fixed value set by the sender where each node uses their own value but = has the sender-defined value as a reference or it is actually decremented a= t each hop.

Either way, this is part of ILP not the ledge= r layer just like the condition and fulfillment. It may be used by the ledg= er layer but that's implementation specific. It belongs in the ILP pack= et.
=C2=A0


= --001a113dc8b4ffd7d10556c7e7ed-- From nobody Tue Aug 15 08:02:47 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5B91320DC for ; Tue, 15 Aug 2017 04:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_LOW=-0.7, 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 BDQ6ZE7WLSpI for ; Tue, 15 Aug 2017 04:12:40 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 00B2D13208E for ; Tue, 15 Aug 2017 04:12:39 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id m34so3106719iti.1 for ; Tue, 15 Aug 2017 04:12:39 -0700 (PDT) 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=2WMWW1+NojWfaHzJIcd2su1Y0MAT64zaeV2KNIUlJX0=; b=LR5/I2PYDfUQ2/mJgeo05TM9gjdNQxRsZlQNAHMS+doibwIugCmHKA7fiiXzABiFq8 FaVl+kWriqG40FPkmdo7/+vMeq7KNU29phEQFoevNcfBQFpoek8UW8378//v2v01Ih+a x5cQyt9cLrQxrH3TNSWErD/iU5JIW0A6/fpqsE65q6dVKKQnJtZKWokH9CBR23/34diz HkkCHSmeHDGeKzQIu0z+mBYv58CSb8vHQ9aeMilZte/8Q5RUalRMqnpAX5FRlH2sPmsT yRFv5Yprjggw50mmj6R/cnblpgBQhHw0Cfz1TfVsGZqWF69h+WZ0i89hEi3HsskhvcQT sZwA== 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=2WMWW1+NojWfaHzJIcd2su1Y0MAT64zaeV2KNIUlJX0=; b=UpCqYeTtjfkYQIOZS4kM7UynEgTtPe9D2nZkoex5Jji5o9p1VS7VHJL4pCi2WC8IHL +MWwv9j8MaD33RQjfXivn0HIgZ9ZLjN5dynNCE88V7CcDB8mS/o4pnId51Nfmo5v680d stpMKFfdLpg4b05JRoBFhRaoSYLnxHuyS8aYcsqshWxNPRSU3qVhtoPpe1JeA7viSpRD bRe5QbkmbSJ/ANNOK6ZAFi6azVmpszK14dgmhr6B7iAJNrbuc5U7NlENlOxEUPqR1so8 2h2oqHXDt+8h5neXN9P/jmMh6i6xIGvvkTBvvgVoA9rORbhc1d1sfOPl46VDNDyny29X u1sA== X-Gm-Message-State: AHYfb5jJ8YShzY6b7DDnrGwVkcILuqv15GwQqbjBpFqMwhVfahfxcsvZ BhqSrdEBVB6JSgkC/Mz/Eo01mwg+dQ== X-Received: by 10.36.245.68 with SMTP id k65mr1460651ith.110.1502795559320; Tue, 15 Aug 2017 04:12:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.70 with HTTP; Tue, 15 Aug 2017 04:12:38 -0700 (PDT) In-Reply-To: References: From: Melvin Carvalho Date: Tue, 15 Aug 2017 13:12:38 +0200 Message-ID: To: Adrian Hope-Bailie Cc: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="94eb2c04bcf27bc3520556c8dbef" Archived-At: X-Mailman-Approved-At: Tue, 15 Aug 2017 08:02:45 -0700 Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 11:12:44 -0000 --94eb2c04bcf27bc3520556c8dbef Content-Type: text/plain; charset="UTF-8" On 14 August 2017 at 18:57, Adrian Hope-Bailie wrote: > I have had an ongoing debate with a number of people about the correct way > to architect the protocol layering for Interledger. This has been an > excellent discussion and I've made some valuable realizations (and conceded > some mistakes on my part) along the way but I am still convinced that we > have some errors in our architecture which are making the whole stack > unwieldy and making it difficult to progress on designs for other layers. > > There is a sense that we should not be changing the core packet > definitions any more but I'm not sure what justifies this. We have a > limited number of implementations and the specifics of the packet formats > and encapsulation are confined to a single library in both. Furthermore, > the fundamentals of the protocol don't change, just the packet formats and > layering to better reflect the protocol and not be influenced so strongly > by the implementation. > > This is my attempt to explain my rationale and solicit feedback from the > community. Hopefully we can come to consensus on the right design (ignoring > concerns about X is frozen; or "we said we aren't going to change Y > anymore" or this will break Z). Once we have a design we consider correct, > let's count the cost and decide if it's a v2 or we can implement it now. > > > *Protocol Layering: Request/Response at the core* > Protocol layering is a mature pattern. The layering is achieved through > encapsulation. A packet contains headers and a payload, and the payload is > the packet of the next layer up. > > In the Internet stack the internetworking layer is the IP layer. Packets > are addressed using IP addresses and layers above rely on these addresses > to introduce messaging semantics. Layers below are host-to-host protocols > that carry the IP packet from one host to another. *All data in the > host-to-host protocol is discarded* when the packet is de-framed and > re-framed for the next hop. > > The internetworking layer in the ILP stack is the Interledger layer. At > this layer packets are used to carry payments, quotes and errors and are > addressed using an Interledger Address. Similar to IP there are > host-to-host protocols that exist below ILP and carry the ILP packets over > each hop and higher layer protocols that carry end-to-end data encapsulated > in the payload of the ILP packet. > > Currently, ILP requires that data outside the packet be passed along with > the packet instead of inside the packet, requiring special treatment of > specific hots-to-host data and making it very difficult to add/change this > data in future. > > A critical difference between IP and ILP is in the messaging semantics. IP > has none. A packet simply contains a source and destination address and > higher layers use these (and introduce additional properties such as ports) > to establish reliable connections, sessions etc. In contrast, ILP only > works if ILP packets exist as request/response pairs and the response > packets follow exactly the same route as the request packets. > This is a great point. IP and ILP do differ in this way. This is something that has always struck me. As such it is easy for IP to facilitate Turing complete infrastructures, of which HTTP and other protocols provide open ended semantics, via specifications (e.g. JSON-LD). ILP seems to be the solution to a specific pain point, which seems a reasonable approach. If at this point, changing the packet structure will cause too much friction, why not work on ILP 1.0 and ILP 2.0? Im sure some lessons will be learnt from the first version. ILP is quite high on my list to convert to a scale free architecture closely aligned with the web. Finding time is always a challenge, tho. It's something I'd love to see developed further. > > As such an ILP request packet has no source address, as this is useless. A > response packet can't simply be addressed to the source of the request and > sent. *A response packet must retrace the route of the request.* > > One may argue (as I did before) that a request/response pair should then > have a unique end-to-end identifier that nodes can use to associate a > request with it's original response, however there is a danger in relying > on this identifier as it could be manipulated to cause responses to fail. > If you can't rely on it, why have it at all? > > As such, a node at the Interledger layer MUST maintain state and be able > to, not only match request/response pairs at the host-to-host layer but > also, > *match an incoming request/response pair to an outgoing request/response > pair.* > > How a host does this not defined in the protocol but it means that at a > minimum the host-to-host protocols must allow request/response pairs to be > matched AND uniquely identified. > > Example: > > When Host B receives Response A from Host C it must pass that on as > Response 1 to Host A. This would have to be recorded during the routing of > Request 1 to Request A. > > Host A Host B Host C > --- Request 1 --> -- Request A --> > <-- Response 1 -- <-- Response A -- > > In protocol stacks like IP and ILP the internetworking layer is the glue > between lower host-to-host layers and higher end-to-end layers. To avoid > overloading the internetworking packets themselves it should be possible to > encapsulate higher level protocol packets in the internetworking layer > payload. > > Another unique feature of ILP (where it differs from IP) is that some > Interledger packets carry value. You can look at this two ways: > 1. The ILP payment packet carries value end-to-end. > 2. The ILP payment packet carries data end-to-end but the sender pays for > this. > > There are two basic request types in ILP, those that carry data and those > that carry both data and value. > > For all request types there is a valid response type but the response > could also be an error. Example: the response to a payment is a > fulfillment, the response to a quote by source amount request is a quote by > source amount response. > > In summary: > - ILP depends on request/response semantics at it's core (these are a > requirement of the internetworking layer itself, not just higher level > protocols). > - As such, the internetworking layer packets must be either a request or a > response and the protocol should define which responses are valid for which > requests and all requests should have a response. > - There are two primary request packet types (a request carrying data and > a request carrying data and value). > - There are two primary response types, a success and failure response. > The success responses are sub-typed to match the sub-type of the request, > however the error response could be returned for any request. > > Proposal: > - All interledger layer messages should be ILP packets (including > fulfillments) and be capable of carrying higher layer protocol payloads. > - While it may make sense to split the interledger payment and interledger > quoting protocols into new higher level protocols that seems like an > unnecessary abstraction. Instead the packet definitions should just have > some consistency and probably a common base/header. > - We should define two base ILP packet types: request and response. > - A payment packet should extend the request type and fulfillment and > error should extend response. > - The ILQP packets already roughly follow this pattern but perhaps a > generic message packet is also required. > > *Ledgers and Trustlines* > > For some time there has been a debate about what constitutes the nodes and > what the edges in the Interledger graph. As we've begun to appreciate the > various different forms a line of trust between two peers can take it's > become clear that ledgers are not actually core to the protocol (despite > the name). If you consider senders, receivers and connectors to be the > nodes, then edges are simply lines of trust between any two nodes. > > In other words the Interledger is made of nodes that are connected via > financial agreements of some form that allow for two nodes to transfer > value between one another. This agreement may or may not be underwritten by > a ledger that supports conditional transfers. Where there is a ledger that > both parties trust to perform conditional transfers correctly the parties > no longer need to trust one another (they trust the ledger). > > The Interledger works because not only does it define a universal address > space for this network, it also defines a universal signature scheme for > payment requests and receipts that can be leveraged by individual > trustlines on the route of a payment, for conditional transfers between two > peers. > > When two disconnected nodes wish to setup a payment they exchange data so > that the sender has, at a minimum, the address of the receiver, a condition > that the receiver can fulfill and the amount (in the receiver's currency) > that the receiver must receive. Next the sender finds a peer to send a > local transfer to, to initiate the end-to-end payment. They package all of > the end-to-end data in an ILP packet and make the local transfer (attaching > the packet or sending it to the peer separately). > > The terms of the local transfer are: "Show me the signature from the > receiver that proves they were paid and you get the proceeds of the local > transfer." > > These terms can be enforced in a variety of ways, one of which is by > making the transfer on a ledger that understands the condition and > fulfillment format and supports conditional payments. This protects the > sender from their upstream peer in the case where they are unable to > produce the fulfillment but still want to claim the proceeds of the > transfer. i.e. It simply changes who the sender trusts (the ledger instead > of the peer) > > How the ILP packet is transferred to the peer and how the transfer is > setup on the ledger *are very different concerns*. It is a mistake to > assume that the communication mechanism between peers is the creation of > the transfer on the ledger itself. I believe that some of the confusion > around this comes from the design of 5-bells ledger where these are the > same thing. > > Consider the following setup where the ledger supports conditional > transfers but does not support notifications as an example. > > Peer A > Ledger Peer B > > | -- LocalTransfer(LocalAmount,Condition) --> > | | > | <----------- Prepared --------------------- | > | > | -------------- ILP Payment Request (ILP Address, RemoteAmount, > Condition) --------------------> | > | | <--------- Check for > pending transfer------------ | > | <----------------------------------------- Ack > ------------------------------------------------ | > | - Poll for completed transfer (Optional) -> > | | > | | > | --> Transfer > | | > | <-- Fulfillment > | | <---------- Submit > fulfillment------------------- | > | <------------------------- ILP Payment Response(Fulfillment) > ---------------------------------- | > | - Confirm completed transfer (Optional) --> > | | > > Note how the communication between peers, carrying the ILP packet, does > not go through the ledger. Also, note how the ledger doesn't need to > understand anything about ILP other than supporting the universal signature > format (conditions and fulfillments). For simplicity this example excluded > expiry but these could just as easily be included alongside the condition > in the direct communication between the peers (i.e. in the ILP packet). > > The expiry in the packet is very similar to the TTL in an IP packet. > Theoretically it can be modified at each hop to a value that the local > sender considers safe for the outgoing local transfer and the trustline on > which it is sent. > > Summary: > > - ILP is not about ledgers, it is about trustlines between nodes/hosts. > - A trustline may be underwritten by a ledger to allow nodes to establish > a trustline-by-proxy where they trust the ledger and not their peer. This > is possible if the ledger supports conditional payments using ILP-style > conditions. > - The protocol should differentiate between the operation of preparing a > transfer on a ledger and the operation of passing an ILP packet from one > peer to another. > > Proposal: > - The condition and timeout should be included in the ILP payment packet. > - Where the fulfillment is a signature over the packet these can be zero'd > out first as with the checksum in an IP packet. > > Look forward to your thoughts! > > > > > > > > > --94eb2c04bcf27bc3520556c8dbef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 14 August 2017 at 18:57, Adrian Hope-Bailie <adrian@hopebailie.= com> wrote:
I have had an= ongoing debate with a number of people about the correct way to architect = the protocol layering for Interledger. This has been an excellent discussio= n and I've made some valuable realizations (and conceded some mistakes = on my part) along the way but I am still convinced that we have some errors= in our architecture which are making the whole stack unwieldy and making i= t difficult to progress on designs for other layers.

Ther= e is a sense that we should not be changing the core packet definitions any= more but I'm not sure what justifies this. We have a limited number of= implementations and the specifics of the packet formats and encapsulation = are confined to a single library in both. Furthermore, the fundamentals of = the protocol don't change, just the packet formats and layering to bett= er reflect the protocol and not be influenced so strongly by the implementa= tion.

This is my attempt to explain my rationale an= d solicit feedback from the community. Hopefully we can come to consensus o= n the right design (ignoring concerns about X is frozen; or "we said w= e aren't going to change Y anymore" or this will break Z). Once we= have a design we consider correct, let's count the cost and decide if = it's a v2 or we can implement it now.

Protocol Layering= : Request/Response at the core

Protocol layering is a matu= re pattern. The layering is achieved through encapsulation. A packet contai= ns headers and a payload, and the payload is the packet of the next layer u= p.

In the Internet stack the internetworking layer is the IP layer.= Packets are addressed using IP addresses and layers above rely on these ad= dresses to introduce messaging semantics. Layers below are host-to-host pro= tocols that carry the IP packet from one host to another. All data in th= e host-to-host protocol is discarded when the packet is de-framed and r= e-framed for the next hop.

The internetworking layer in the IL= P stack is the Interledger layer. At this layer packets are used to carry p= ayments, quotes and errors and are addressed using an Interledger Address. = Similar to IP there are host-to-host protocols that exist below ILP and car= ry the ILP packets over each hop and higher layer protocols that carry end-= to-end data encapsulated in the payload of the ILP packet.

Currently, ILP requires that data outside the packet be passed along with= the packet instead of inside the packet, requiring special treatment of sp= ecific hots-to-host data and making it very difficult to add/change this da= ta in future.

A critical difference between IP and = ILP is in the messaging semantics. IP has none. A packet simply contains a = source and destination address and higher layers use these (and introduce a= dditional properties such as ports) to establish reliable connections, sess= ions etc. In contrast, ILP only works if ILP packets exist as request/respo= nse pairs and the response packets follow exactly the same route as the req= uest packets.

This is a great point.=C2=A0 IP and ILP do differ in= this way.=C2=A0 This is something that has always struck me.=C2=A0 As such= it is easy for IP to facilitate Turing complete infrastructures, of which = HTTP and other protocols provide open ended semantics, via specifications (= e.g. JSON-LD).=C2=A0 ILP seems to be the solution to a specific pain point,= which seems a reasonable approach.=C2=A0

If at this poi= nt, changing the packet structure will cause too much friction, why not wor= k on ILP 1.0 and ILP 2.0?=C2=A0 Im sure some lessons will be learnt from th= e first version.

ILP is quite high on my list to convert = to a scale free architecture closely aligned with the web.=C2=A0 Finding ti= me is always a challenge, tho.=C2=A0 It's something I'd love to see= developed further.
=C2=A0

As such an = ILP request packet has no source address, as this is useless. A response pa= cket can't simply be addressed to the source of the request and sent. <= b>A response packet must retrace the route of the request.

One m= ay argue (as I did before) that a request/response pair should then have a = unique end-to-end identifier that nodes can use to associate a request with= it's original response, however there is a danger in relying on this i= dentifier as it could be manipulated to cause responses to fail. If you can= 't rely on it, why have it at all?

As such, a node at the Interl= edger layer MUST maintain state and be able to, not only match request/resp= onse pairs at the host-to-host layer but also, match an incoming request= /response pair to an outgoing request/response pair.
How a host does this not defined in the protocol but it means t= hat at a minimum the host-to-host protocols must allow request/response pai= rs to be matched AND uniquely identified.

Example:

When Host B receives Response A from Host C it must pass that on as = Response 1 to Host A. This would have to be recorded during the routing of = Request 1 to Request A.

Host A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Host B=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Host C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- Request 1 -->= =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 --=C2=A0 Request A -->
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <-- Response 1 --=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0 <-- Response A --

In protocol stacks like = IP and ILP the internetworking layer is the glue between lower host-to-host= layers and higher end-to-end layers. To avoid overloading the internetwork= ing packets themselves it should be possible to encapsulate higher level pr= otocol packets in the internetworking layer payload.

Another unique feature of ILP (where it differs from IP) is that some Inte= rledger packets carry value. You can look at this two ways:
1= . The ILP payment packet carries value end-to-end.
2. The ILP= payment packet carries data end-to-end but the sender pays for this.
There are two basic request types in ILP, those that carry data and those= that carry both data and value.

For all request types th= ere is a valid response type but the response could also be an error. Examp= le: the response to a payment is a fulfillment, the response to a quote by = source amount request is a quote by source amount response.
<= br>
In summary:
- ILP depends on request/response semantics at= it's core (these are a requirement of the internetworking layer itself= , not just higher level protocols).
- As such, the internetworking laye= r packets must be either a request or a response and the protocol should de= fine which responses are valid for which requests and all requests should h= ave a response.
- There are two primary request packet types = (a request carrying data and a request carrying data and value).
<= div>- There are two primary response types, a success and failure response.= The success responses are sub-typed to match the sub-type of the request, = however the error response could be returned for any request.

=
Proposal:
- All interledger layer messages should be ILP= packets (including fulfillments) and be capable of carrying higher layer p= rotocol payloads.
- While it may make sense to split the inte= rledger payment and interledger quoting protocols into new higher level pro= tocols that seems like an unnecessary abstraction. Instead the packet defin= itions should just have some consistency and probably a common base/header.=
- We should define two base ILP packet types: request and re= sponse.
- A payment packet should extend the request type and= fulfillment and error should extend response.
- The ILQP pac= kets already roughly follow this pattern but perhaps a generic message pack= et is also required.

Ledgers and Trustlines=

For some time there has been a debate about what con= stitutes the nodes and what the edges in the Interledger graph. As we'v= e begun to appreciate the various different forms a line of trust between t= wo peers can take it's become clear that ledgers are not actually core = to the protocol (despite the name). If you consider senders, receivers and = connectors to be the nodes, then edges are simply lines of trust between an= y two nodes.

In other words the Interledger is made of no= des that are connected via financial agreements of some form that allow for= two nodes to transfer value between one another. This agreement may or may= not be underwritten by a ledger that supports conditional transfers. Where= there is a ledger that both parties trust to perform conditional transfers= correctly the parties no longer need to trust one another (they trust the = ledger).

The Interledger works because not only does it define a uni= versal address space for this network, it also defines a universal signatur= e scheme for payment requests and receipts that can be leveraged by individ= ual trustlines on the route of a payment, for conditional transfers between= two peers.

When two disconnected nodes wish to setup a p= ayment they exchange data so that the sender has, at a minimum, the address= of the receiver, a condition that the receiver can fulfill and the amount = (in the receiver's currency) that the receiver must receive. Next the s= ender finds a peer to send a local transfer to, to initiate the end-to-end = payment. They package all of the end-to-end data in an ILP packet and make = the local transfer (attaching the packet or sending it to the peer separate= ly).

The terms of the local transfer are: "Show me t= he signature from the receiver that proves they were paid and you get the p= roceeds of the local transfer."

These terms can be e= nforced in a variety of ways, one of which is by making the transfer on a l= edger that understands the condition and fulfillment format and supports co= nditional payments. This protects the sender from their upstream peer in th= e case where they are unable to produce the fulfillment but still want to c= laim the proceeds of the transfer. i.e. It simply changes who the sender tr= usts (the ledger instead of the peer)

How the ILP packet = is transferred to the peer and how the transfer is setup on the ledger a= re very different concerns. It is a mistake to assume that the communic= ation mechanism between peers is the creation of the transfer on the ledger= itself. I believe that some of the confusion around this comes from the de= sign of 5-bells ledger where these are the same thing.

Co= nsider the following setup where the ledger supports conditional transfers = but does not support notifications as an example.

Peer A =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ledger=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Peer B

=C2=A0 | -- LocalTransfer(LocalAmount,Condition) --> |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0 | <----------- Prepared --------------------- |=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0 | -------------- ILP Payment Request (ILP Address, Rem= oteAmount, Condition) --------------------> |=C2=A0
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | <--------- = Check for pending transfer------------ |
=C2=A0 | <= ----------------------------------------- Ack ------------------------= ------------------------ |=C2=A0
=C2=A0 | - Poll for completed tran= sfer (Optional) -> |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0 |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | --> Transfer
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | <-- Fulfillment
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | <---------- Su= bmit fulfillment------------------- |
=C2=A0 | <------------------------- ILP Payment Res= ponse(Fulfillment) ---------------------------------- |=C2=A0
=C2=A0 | - Confirm completed transfer (Optional) --&g= t; |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |

Note how the communication between = peers, carrying the ILP packet, does not go through the ledger. Also, note = how the ledger doesn't need to understand anything about ILP other than= supporting the universal signature format (conditions and fulfillments). F= or simplicity this example excluded expiry but these could just as easily b= e included alongside the condition in the direct communication between the = peers (i.e. in the ILP packet).

The expiry in the packet is very sim= ilar to the TTL in an IP packet. Theoretically it can be modified at each h= op to a value that the local sender considers safe for the outgoing local t= ransfer and the trustline on which it is sent.

Summary:
- ILP is not about ledgers, it is about trustlines between= nodes/hosts.
- A trustline may be underwritten by a ledger to allow nod= es to establish a trustline-by-proxy where they trust the ledger and not th= eir peer. This is possible if the ledger supports conditional payments usin= g ILP-style conditions.
- The protocol should differentiate b= etween the operation of preparing a transfer on a ledger and the operation = of passing an ILP packet from one peer to another.

Propos= al:
- The condition and timeout should be included in the ILP= payment packet.
- Where the fulfillment is a signature over = the packet these can be zero'd out first as with the checksum in an IP = packet.

Look forward to your thoughts!









--94eb2c04bcf27bc3520556c8dbef-- From nobody Tue Aug 15 08:02:53 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65FE1321D8 for ; Tue, 15 Aug 2017 07:00:39 -0700 (PDT) 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, 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 (1024-bit key) header.d=ripple.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 GrDZyc6XEpfJ for ; Tue, 15 Aug 2017 07:00:35 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 C49A81321D2 for ; Tue, 15 Aug 2017 07:00:34 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id b65so3447805wrd.0 for ; Tue, 15 Aug 2017 07:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vzWz9vAZnZ7ijsy+Rp8eHyeDNyajZJ/kNH7LLg5jHSQ=; b=nyGPhrUn0BHNGPz3znZWvr3kV+sN9TuIGEUjEkzUOHxbw4hdwSXhBgKkaxflm7w6Ht JPy0sne2aWUcNek+POGj4bMpLCW0yGyhkqKZ0chiMeAlZIninRF/Jz4LLtd8fm7BBEVN DTc78UlMqrCsUaHvSkxOlTMR16GTVTq4J25bk= 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=vzWz9vAZnZ7ijsy+Rp8eHyeDNyajZJ/kNH7LLg5jHSQ=; b=YbUUcWpTQ9UJT3uhuoWgYG1HHXTOnaReDZcB3Ks1gQh4E1NVz7aHGSslWiBfdIW6/T 7v6kyQGMiJ3/8VrDZNLy05S2Kpf1PKhl+UdiYENy1LfeRU3TBqqRosx/JIhScDg93+Kl vzMtF1R4dyPvKTY8QszyP5etqY3B6sITpt5OrEcL8k7Vprb4+J3Ri0AIwx8y1s64ftYb vk8mUx6qaSjIMDEA78x2Up49Oh0EF4P0zwMriagcCnUjBMUpOkp2bnaSo5RpydKmJ66h aUhxYVciv/kAxbQDTWJi86XzZi2Bt3hKKloIuMVH/OTz4buLbRVsDnDlJqkN5orj3tVn E52g== X-Gm-Message-State: AHYfb5hNgJWk/Oq6WmlYoNFWqutGjlMj+JiFz1sg1h49mjcDBZ7wAsJC JEHQHq7Fze6ZjNRX6guxMJ62O4SZ3C2P X-Received: by 10.223.186.138 with SMTP id p10mr5027824wrg.181.1502805633043; Tue, 15 Aug 2017 07:00:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.60.135 with HTTP; Tue, 15 Aug 2017 07:00:32 -0700 (PDT) In-Reply-To: References: From: Ben Sharafian Date: Tue, 15 Aug 2017 16:00:32 +0200 Message-ID: To: Adrian Hope-Bailie Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="089e0821150cecb7220556cb3385" Archived-At: X-Mailman-Approved-At: Tue, 15 Aug 2017 08:02:45 -0700 Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 14:00:40 -0000 --089e0821150cecb7220556cb3385 Content-Type: text/plain; charset="UTF-8" > > In that case, the plugin or whatever is doing the accounting is the >>> ledger. Digital value is always tracked in ledgers, so I think it does make >>> sense to think of this as the base layer. The reason to abstract the >>> functionality you expect from the ledger layer is precisely so you can >>> handle it in different ways, depending on what the underlying systems >>> provide. >> >> I see 3 ways to think of the layer(s) underpinning ILP: >> >> 1. The "Ledger Layer" provides both messaging capabilities and some >> type of HTLA >> >> >> >> 1. There are separate plugins for messaging and for transfers and >> when you peer with someone you have to agree on a plugin for each >> >> >> 1. We standardize the messaging part and say that all goes over IP >> and then just have more minimal plugins for the on-ledger settlements >> >> Number 1 is what we have and I think that still makes the most sense. > > I think you're confusing implementation details and defining of interfaces > with definition of a protocol stack. The only differences between the tree > examples you have above is in implementation. I had to scroll up after reading this to make sure it was @adrian talking, because that seems like the opposite of what you were arguing for. The proposal that you're arguing for is basically asserting that we're going to be using CLP, because it makes the assumption that the connectors (who understand ILP) are managing the HTLA logic. In the current model, the CLP/trustline model and the direct ledger model both work without having to treat anything on the ILP layer differently. We're favoring on-ledger messaging because of our implementation, yes, but we've been able to switch most all of our plugins from on-ledger messaging to RPC-based messaging without changing the ILP layer at all. With the ledger-level abstraction, we were able to switch from our ledger-based mode of thinking to the CLP/trustline based way without changing anything other than the plugin. Your argument comes from an assumption of a CLP-style ledger protocol with some underlying ledger, which we can't assume is always the case. >From the perspective of the Interledger Protocol the implementation of the > lower layers is not important, that's the whole point of layering. By > forcing important aspects of ILP like the condition, fulfillment and expiry > down into those layers you muddy the waters and we now have to standardize > those protocols too. Instead we should just be defining the functions they > must provide and then leave it up to implementations to provide those > functions. I don't agree with this point; the condition and fulfillment have actual meaning to the ledger layer. You've said that the ledger often doesn't care about fulfillment and condition, but the ledger _layer_'s (where transfers are done) role is to take in condition and fulfillment and make a transfer which satisfies its HTLA. If the ledger layer has to look into the ILP packet to do so, that is a blatant breaking of layering. By putting the condition, fulfillment, and expiry on the ledger layer, we leave it open for any ledger type to work, rather than forcing all ledger-layer software to understand ILP. I agree that Interledger defines how conditions, fulfillments, and expiries should be chained together, but it makes no assertions about their data format. ILP says you should send your outgoing transfer with the same condition as the incoming one, and a lower expiry. But because ILP allows for many different types of ledgers, it doesn't make sense to assert how these are encoded. IP doesn't tell you how to encode an ethernet packet. It doesn't even know whether it's going over a computer or a hand-written letter carried by a pigeon. IP takes for granted that you can send data over one connection by putting it in a lower level. Even though IP tells you how to chain these connections together, it doesn't have to put the things it's chaining on the internetworking level. IP also assumes that if you get some incoming data on a connection you can copy it and send it out on the next connection. Because you can already send data over a connection, all IP adds is the missing piece: a packet that tells you where to go. With ILP, we assume that there is a way to prepare a conditional transfer, expire a conditional transfer, and fulfill a conditional transfer. We also assume that if you get an incoming transfer you can create an outgoing transfer with the same condition. The abstraction we made means that conditions and fulfillments are already carried in the lower levels. We could have assumed that no ledgers ever support conditional transfers, and said the only thing ILP gets from lower levels is the ability to send a transfer. But if we want to support the case where any of them do, we have to keep the conditions and fulfillments in the layer where they're actually used. On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie wrote: > > > On 14 August 2017 at 22:03, Evan Schwartz wrote: > >> I think this thread is going to get extremely unwieldy but here goes: >> >> > - All interledger layer messages should be ILP packets (including >> fulfillments) and be capable of carrying higher layer protocol payloads. >> >> Interledger has higher requirements than ILP for the lowest layer, >> specifically because we are carrying money and not just data. One of the >> requirements is being able to transmit a 32-byte fulfillment back along the >> same path that carried the payment originally. If we expect this of the >> lower layer, I don't see a point in putting the fulfillment into an ILP >> packet and transmitting it as Interledger data along the same path. All >> ledger-layer protocols will need to interpret the fulfillment passed in >> their protocol, not the one passed through the Interledger layer. >> > > This is not correct. There is no requirement on ledger layer protocols to > transmit or understand the fulfillment. You are looking at this through the > lens of existing implementations from the bottom up instead of starting at > the interledger layer. > > The primary function of the condition and fulfillment is as a signed > end-to-end receipt. If the sender agrees a condition with a receiver and > then gets back the valid fulfillment they don't care what happened in the > middle. The receiver has signed a receipt saying they have their money. > > The value of using a standard for the receipt and signature is that each > transfer along the way CAN re-use it. One the one hand you can have a > transfer between two peers that have zero trust and the ledger they use > supports conditional payments completely. On the other extreme you can have > two peers that have a full trust and ignore the condition and fulfillment > completely. > > The ledger layer protocols carry ILP packets. Payment requests and either > fulfillment or error responses. If a ledger layer protocol wants to use the > condition and fulfillment for their own operations they can extract these > from the ILP packets and use them. > > >> > - While it may make sense to split the interledger payment and >> interledger quoting protocols into new higher level protocols that seems >> like an unnecessary abstraction. Instead the packet definitions should just >> have some consistency and probably a common base/header. >> >> The current protocols effectively have this header but it isn't separated >> out. There are two fields in the request header: type and destination >> address. There is one field in the response header: type. I don't think it >> makes that much of a big difference to separate these fields if all of the >> fields in that packet need to be interpreted together (for example, you >> can't understand a quote request if you strip off the destination address). >> > > I agree that we don't HAVE to explicitly separate them out but I think ti > would make it clearer how the stack is architected if there was a header > that was consistent across all packets. Currently the only thing that is > consitent across all ILP packets is that they are defined int he same file. > > >> >> > - We should define two base ILP packet types: request and response. >> >> Unless this adds some substantive benefit or new fields I don't think >> it's worth breaking all of the formats we have just to rearrange things. >> > > The goal of this exercise is to tease out the best design and ignore the > cost of change until we can compare the results with the current design. > > >> >> > - ILP is not about ledgers, it is about trustlines between nodes/hosts. >> >> A ledger is any system that tracks accounts and balances. When you use a >> trustline all of your messages still need to go through an accounting >> system (such as the plugin in the JS implementation) and then on to the >> other program logic. >> > > As above, this is incorrect. There is no requirement for "all messages to > go through an accounting system". > > Since designing the first implementation of 5-bells ledger we have assumed > that passing the ILP packet MUST be done by the ledger because that is how > we implemented it. But that is not true. It is perfectly valid for the > passing of an ILP packet from one peer to another to be simply an exchange > of data. > > The receiving peer makes a decision about whether or not to forward the > packet based on the current financial position they have with the sending > peer. > > It is convenient if the ledger that records the net positions of the peers > also forwards the messaging and even better if it natively supports > conditional payments and can use the condition and the fulfillment from the > ILP packet for those but that's all it is, convenient. > > > >> In that case, the plugin or whatever is doing the accounting is the >> ledger. Digital value is always tracked in ledgers, so I think it does make >> sense to think of this as the base layer. The reason to abstract the >> functionality you expect from the ledger layer is precisely so you can >> handle it in different ways, depending on what the underlying systems >> provide. >> >> I see 3 ways to think of the layer(s) underpinning ILP: >> >> 1. The "Ledger Layer" provides both messaging capabilities and some >> type of HTLA >> >> 2. There are separate plugins for messaging and for transfers and >> when you peer with someone you have to agree on a plugin for each >> 3. We standardize the messaging part and say that all goes over IP >> and then just have more minimal plugins for the on-ledger settlements >> >> Number 1 is what we have and I think that still makes the most sense. >> > > I think you're confusing implementation details and defining of interfaces > with definition of a protocol stack. The only differences between the tree > examples you have above is in implementation. > > From the perspective of the Interledger Protocol the implementation of the > lower layers is not important, that's the whole point of layering. By > forcing important aspects of ILP like the condition, fulfillment and expiry > down into those layers you muddy the waters and we now have to standardize > those protocols too. Instead we should just be defining the functions they > must provide and then leave it up to implementations to provide those > functions. > > I know we want to define a standard to bootstrap the system (CLP) but > that's misleading us into thinking it's an essential part of the stack. > It's perfectly valid for two peers to not use CLP and still be part of the > Interledger. > > That said, you raise an interesting consideration about the layers below > ILP and actually I think it makes sense to split these. > > We keep trying to force messaging through the ledger layer and actually > that's the wrong place to put it if we can split the ledger layer into a > messaging layer and a ledger layer. That way we can stop trying to think of > all HLTAs as ledgers. > > A thought, why not use sub-layers as is common in other stacks: > > 1. Link layer: Layer upon which two peers that have a direct link, or > participate in the same payment network, communicate > 2. Transfer/ ledger: Layer on which financial positions between two peers > are recorded > > This reflects the already emerging HTLA model and many of our existing > plugins and ledger integrations. > Link Layer: XRP Paychan, Lightning > Ledger Layer: XRP Ledger, Bitcoin > > This doesn't prevent us from defining a standard binary protocol that > defines all of the operations for both layers (like CLP) but I see value in > distinguishing between these two. > > >> >> > - The protocol should differentiate between the operation of preparing >> a transfer on a ledger and the operation of passing an ILP packet from one >> peer to another. >> >> The protocol assumes your conditional transfer is underpinned by some >> HTLA >> . >> It doesn't care whether that's on-ledger or not. >> > > What do you mean when you say "the protocol"? In my statement I am > referring to ILP. > My point above being that ILP expects ILP packets to be passed from peer > to peer but has no expectations about transfers. > > It's perfectly legal (from an ILP perspective) for two peers to exchange > ILP packets with no transfers. Clearly if a node routes a packet on and has > no incoming transfer it's going to lose money but that's a consideration > for that node. It doesn't affect anyone else in the chain. > > ILP doesn't assume anything about transfers at all, let alone conditional > transfers. It provides useful semantics for conditional transfers to be > used by two peers to transact as part of a larger ILP payment. > > >> >> > - The condition and timeout should be included in the ILP payment >> packet. >> >> I strongly disagree with this. We had this debate a year ago and I was on >> your side but was convinced that this is not a good idea. >> > > Yes, I recall this and I'm sorry I didn't push harder on this point. > Unfortunately I think the decision to pull it out of the packet is mostly > driven by how our prototypes were implemented rather than good architecture. > >> >> The layer below ILP must be capable of doing conditional transfers based >> on sha256 hashlocks with 32-byte preimages. >> > > This is not true and I think it would be useful for us to agree on this as > this seems to be the argument I am coming up against most often. The peers > participating in a transfer that is part of an ILP payment may wish to use > conditional transfers as a way to enforce their agreement but this is not a > requirement of the protocol. > > The agreement between any two peers is: "I will pay you X if you can > provide a receipt that Y was paid Z before T". > ILP provides a standard for expressing this agreement so that these can be > chained together BUT it is not a requirement that every agreement in the > chain uses the condition, and fulfillment provided at the ILP layer. > > >> >> As a result, the original condition and the corresponding preimage MUST >> be expressed in that layer. >> > > As I have shown above, this is not true. > > >> Then the question is whether we should also include it in the packet that >> is forwarded. What ultimately convinced me is the following: All connectors >> MUST ignore the condition if it is in the packet, because they are only >> guaranteed their money back if they use the same condition from the >> incoming transfer they got. >> > > Here is where the layering is being corrupted. > > All connectors MUST inspect the condition in the ILP packet as part of > their decision to route the packet or not. > When the local transfer module of the connectors stack passes the ILP > packet up to the ILP module it should indicate the properties of the > incoming transfer that carried the packet. > This is essential firstly so that the routing logic in the ILP module can > record the incoming transfer identifier so it is able to use the correct > response id when it passes back the fulfillment or error. > The other properties that the ILP module should look at are the condition > and expiry on the incoming transfer. > > If the incoming route uses conditional transfers and these are supposed to > match the condition and expiry in the ILP packet then the ILP module should > compare them and reject the packet if: > a) the conditions don't match OR > b) the expiry is too short > > We should still discuss if the expiry should be set by the sender and left > unchanged or used like a TTL and decremented by each node. > > >> Also, the receiver will need to take out the condition in order to hash >> the packet for PSK or IPR. >> > > This is completely normal. Zeroing a checksum field in a header before > calculating the checksum is VERY common precisely because it's long been > accepted that the right place to put that data is in the headers and the > work of zero'ing it out to calculate the checksum (or signature in our > case) is not material. > > >> So basically, no one wants the condition in there. It feels like it ought >> to be in there, but literally none of the parties want the extra 32 bytes >> in there. >> > > "Nobody wants it there" is a terrible reason to abandon the correct > design. The whole purpose of a good architecture is you accept that there > may be cases in future that haven't been considered now so designing just > for the known cases is a bad idea. > > Good architecture is not the same as optimization. Taking stuff out (even > when it feels wrong) to save a few bytes is a good sign that it's a bad > idea. > > >> >> The reason the timeout should not be in there is that there isn't a >> single timeout for the payment. There are multiple separate timeouts for >> each of the bilateral transfers. Those must go in the individual transfers >> and there is no sensible value to put in the Interledger packet. >> > > As above, this is somewhat equivalent to the TTL in an IP packet. I'm open > to discussing if it should be a fixed value set by the sender where each > node uses their own value but has the sender-defined value as a reference > or it is actually decremented at each hop. > > Either way, this is part of ILP not the ledger layer just like the > condition and fulfillment. It may be used by the ledger layer but that's > implementation specific. It belongs in the ILP packet. > >> >> >> > --089e0821150cecb7220556cb3385 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In that case, the plugin or whatever is doing the accounting is = the ledger. Digital value is always tracked in ledgers, so I think it does = make sense to think of this as the base layer. The reason to abstract the f= unctionality you expect from the ledger layer is precisely so you can handl= e it in different ways, depending on what the underlying systems provide.I see 3 ways to think of the layer(s) underpinning ILP:
  1. The "Ledger Layer" pro= vides both messaging capabilities and some type of=C2=A0HTLA
    1. There are separate plugins for messagin= g and for transfers and when you peer with someone you have to agree on a p= lugin for each
    1. We standardize t= he messaging part and say that all goes over IP and then just have more min= imal plugins for the on-ledger settlements
    Number 1 is what we hav= e and I think that still makes the most sense.

I think you're confusing implementation details a= nd defining of interfaces with definition of a protocol stack. The only dif= ferences between the tree examples you have above is in implementation.

I had to scroll up after reading this t= o make sure it was @adrian talking, because that seems like the opposite of= what you were arguing for. The proposal that you're arguing for is bas= ically asserting that we're going to be using CLP, because it makes the= assumption that the connectors (who understand ILP) are managing the HTLA = logic.

In the current model, the CLP/trustline mod= el and the direct ledger model both work without having to treat anything o= n the ILP layer differently. We're favoring on-ledger messaging because= of our implementation, yes, but we've been able to switch most all of = our plugins from on-ledger messaging to RPC-based messaging without changin= g the ILP layer at all.

With the ledger-level abst= raction, we were able to switch from our ledger-based mode of thinking to t= he CLP/trustline based way without changing anything other than the plugin.= Your argument comes from an assumption of a CLP-style ledger protocol with= some underlying ledger, which we can't assume is always the case.

From the perspective of the Interledger Protocol th= e implementation of the lower layers is not important, that's the whole= point of layering. By forcing important aspects of ILP like the condition,= fulfillment and expiry down into those layers you muddy the waters and we = now have to standardize those protocols too. Instead we should just be defi= ning the functions they must provide and then leave it up to implementation= s to provide those functions.

I don&= #39;t agree with this point; the condition and fulfillment have actual mean= ing to the ledger layer. You've said that the ledger often doesn't = care about fulfillment and condition, but the ledger _layer_'s (where t= ransfers are done) role is to take in condition and fulfillment and make a = transfer which satisfies its HTLA. If the ledger layer has to look into the= ILP packet to do so, that is a blatant breaking of layering. By putting th= e condition, fulfillment, and expiry on the ledger layer, we leave it open = for any ledger type to work, rather than forcing all ledger-layer software = to understand ILP.

I agree that Interledger define= s how conditions, fulfillments, and expiries should be chained together, bu= t it makes no assertions about their data format. ILP says you should send = your outgoing transfer with the same condition as the incoming one, and a l= ower expiry. But because ILP allows for many different types of ledgers, it= doesn't make sense to assert how these are encoded.

IP doesn't tell you how to encode an ethernet packet. It doesn&#= 39;t even know whether it's going over a computer or a hand-written let= ter carried by a pigeon. IP takes for granted that you can send data over o= ne connection by putting it in a lower level. Even though IP tells you how = to chain these connections together, it doesn't have to put the things = it's chaining on the internetworking level. IP also assumes that if you= get some incoming data on a connection you can copy it and send it out on = the next connection. Because you can already send data over a connection, a= ll IP adds is the missing piece: a packet that tells you where to go.
=

With ILP, we assume that there is a way to prepare a co= nditional transfer, expire a conditional transfer, and fulfill a conditiona= l transfer. We also assume that if you get an incoming transfer you can cre= ate an outgoing transfer with the same condition. The abstraction we made m= eans that conditions and fulfillments are already carried in the lower leve= ls.

We could have assumed that no ledgers ever sup= port conditional transfers, and said the only thing ILP gets from lower lev= els is the ability to send a transfer. But if we want to support the case w= here any of them do, we have to keep the conditions and fulfillments in the= layer where they're actually used.

On Tue, Aug 15, 2017 at 12:04 PM, Adrian = Hope-Bailie <adrian@hopebailie.com> wrote:


On 14 August 2017 at 22:03, Evan = Schwartz <evan@ripple.com> wrote:
I think this thread is going to get extremely unwiel= dy but here goes:

>=C2=A0- All interledger layer messages should be ILP packets (inclu= ding fulfillments) and be capable of carrying higher layer protocol payload= s.

Interledger has higher requiremen= ts than ILP for the lowest layer, specifically because we are carrying mone= y and not just data. One of the requirements is being able to transmit a 32= -byte fulfillment back along the same path that carried the payment origina= lly. If we expect this of the lower layer, I don't see a point in putti= ng the fulfillment into an ILP packet and transmitting it as Interledger da= ta along the same path. All ledger-layer protocols will need to interpret t= he fulfillment passed in their protocol, not the one passed through the Int= erledger layer.

This is not c= orrect. There is no requirement on ledger layer protocols to transmit or un= derstand the fulfillment. You are looking at this through the lens of exist= ing implementations from the bottom up instead of starting at the interledg= er layer.

The primary function of = the condition and fulfillment is as a signed end-to-end receipt. If the sen= der agrees a condition with a receiver and then gets back the valid fulfill= ment they don't care what happened in the middle. The receiver has sign= ed a receipt saying they have their money.

The value of using a standard for the receipt and signature is that= each transfer along the way CAN re-use it. One the one hand you can have a= transfer between two peers that have zero trust and the ledger they use su= pports conditional payments completely. On the other extreme you can have t= wo peers that have a full trust and ignore the condition and fulfillment co= mpletely.
=C2=A0
The ledger la= yer protocols carry ILP packets. Payment requests and either fulfillment or= error responses. If a ledger layer protocol wants to use the condition and= fulfillment for their own operations they can extract these from the ILP p= ackets and use them.


>=C2=A0= - While it may make sense to split the interledger payment and interledger = quoting protocols into new higher level protocols that seems like an unnece= ssary abstraction. Instead the packet definitions should just have some con= sistency and probably a common base/header.

The current protocols effectively have this header but it isn&#= 39;t separated out. There are two fields in the request header: type and de= stination address. There is one field in the response header: type. I don&#= 39;t think it makes that much of a big difference to separate these fields = if all of the fields in that packet need to be interpreted together (for ex= ample, you can't understand a quote request if you strip off the destin= ation address).

I= agree that we don't HAVE to explicitly separate them out but I think t= i would make it clearer how the stack is architected if there was a header = that was consistent across all packets. Currently the only thing that is co= nsitent across all ILP packets is that they are defined int he same file.
=C2=A0

>=C2=A0- We should define two base ILP packet types: requ= est and response.

Unless this ad= ds some substantive benefit or new fields I don't think it's worth = breaking all of the formats we have just to rearrange things.

The goal of this exercise is to tease= out the best design and ignore the cost of change until we can compare the= results with the current design.
=C2=A0

>=C2=A0- ILP is not about ledgers, = it is about trustlines between nodes/hosts.

A ledger is any system that tracks accounts and = balances. When you use a trustline all of your messages still need to go th= rough an accounting system (such as the plugin in the JS implementation) an= d then on to the other program logic.

As above, this is incorrect. There is no requirement for &qu= ot;all messages to go through an accounting system".

Since designing the first implementation of 5-bells ledger we have assumed= that passing the ILP packet MUST be done by the ledger because that is how= we implemented it. But that is not true. It is perfectly valid for the pas= sing of an ILP packet from one peer to another to be simply an exchange of = data.

The receiving peer makes a decision about whether o= r not to forward the packet based on the current financial position they ha= ve with the sending peer.

It is convenient if = the ledger that records the net positions of the peers also forwards the me= ssaging and even better if it natively supports conditional payments and ca= n use the condition and the fulfillment from the ILP packet for those but t= hat's all it is, convenient.

=C2=A0<= /div>
In that case, the= plugin or whatever is doing the accounting is the ledger. Digital value is= always tracked in ledgers, so I think it does make sense to think of this = as the base layer. The reason to abstract the functionality you expect from= the ledger layer is precisely so you can handle it in different ways, depe= nding on what the underlying systems provide.

I se= e 3 ways to think of the layer(s) underpinning ILP:
  1. The "Ledger Layer" provides both messaging capabiliti= es and some type of HTLA
  2. There are separate plugins for messa= ging and for transfers and when you peer with someone you have to agree on = a plugin for each
  3. We standardize the messaging part and say that al= l goes over IP and then just have more minimal plugins for the on-ledger se= ttlements
Number 1 is what we have and I think that still mak= es the most sense.

I think you'= ;re confusing implementation details and defining of interfaces with defini= tion of a protocol stack. The only differences between the tree examples yo= u have above is in implementation.

From the perspective of the Inter= ledger Protocol the implementation of the lower layers is not important, th= at's the whole point of layering. By forcing important aspects of ILP l= ike the condition, fulfillment and expiry down into those layers you muddy = the waters and we now have to standardize those protocols too. Instead we s= hould just be defining the functions they must provide and then leave it up= to implementations to provide those functions.

I know we want to define a standard to bootstrap the system (C= LP) but that's misleading us into thinking it's an essential part o= f the stack. It's perfectly valid for two peers to not use CLP and stil= l be part of the Interledger.

That said, you raise an interesting consid= eration about the layers below ILP and actually I think it makes sense to s= plit these.

We keep trying to force messaging through the= ledger layer and actually that's the wrong place to put it if we can s= plit the ledger layer into a messaging layer and a ledger layer. That way w= e can stop trying to think of all HLTAs as ledgers.

A tho= ught, why not use sub-layers as is common in other stacks:

1. Link layer: Layer upon which two peers that have a direct link, or par= ticipate in the same payment network, communicate
2. Transfer= / ledger: Layer on which financial positions between two peers are recorded=

This reflects the already emerging HTLA model and many of our exist= ing plugins and ledger integrations.
Link Layer: XRP Paychan,= Lightning
Ledger Layer: XRP Ledger, Bitcoin
This doesn't prevent us from defining a standard binary pr= otocol that defines all of the operations for both layers (like CLP) but I = see value in distinguishing between these two.
=C2=A0
<= br>
>=C2=A0- The protocol = should differentiate between the operation of preparing a transfer on a led= ger and the operation of passing an ILP packet from one peer to another.

The protocol assume= s your conditional transfer is underpinned by some HTLA. It doesn't care= whether that's on-ledger or not.

What do you mean when you say "the protocol"? In my stat= ement I am referring to ILP.
My point above being that ILP expects ILP = packets to be passed from peer to peer but has no expectations about transf= ers.

It's perfectly legal (from= an ILP perspective) for two peers to exchange ILP packets with no transfer= s. Clearly if a node routes a packet on and has no incoming transfer it'= ;s going to lose money but that's a consideration for that node. It doe= sn't affect anyone else in the chain.

ILP doesn't assume anything about transfers at all, let alone co= nditional transfers. It provides useful semantics for conditional transfers= to be used by two peers to transact as part of a larger ILP payment.
= =C2=A0

>=C2=A0- The condition and timeout should be include= d in the ILP payment packet.

I stron= gly disagree with this. We had this debate a year ago and I was on your sid= e but was convinced that this is not a good idea.
<= div>
Yes, I recall this and I'm sorry I didn't= push harder on this point. Unfortunately I think the decision to pull it o= ut of the packet is mostly driven by how our prototypes were implemented ra= ther than good architecture.

The layer below ILP must be= capable of doing conditional transfers based on sha256 hashlocks with 32-b= yte preimages.

This is = not true and I think it would be useful for us to agree on this as this see= ms to be the argument I am coming up against most often. The peers particip= ating in a transfer that is part of an ILP payment may wish to use conditio= nal transfers as a way to enforce their agreement but this is not a require= ment of the protocol.

The agreement between any two peers= is: "I will pay you X if you can provide a receipt that Y was paid Z = before T".
ILP provides a standard for expressing this a= greement so that these can be chained together BUT it is not a requirement = that every agreement in the chain uses the condition, and fulfillment provi= ded at the ILP layer.

=C2=A0
As a result, the original condition and= the corresponding preimage MUST be expressed in that layer.

As I have shown above, this is not tr= ue.
=C2=A0
Then the question is whether we should also includ= e it in the packet that is forwarded. What ultimately convinced me is the f= ollowing: All connectors MUST ignore the condition if it is in the packet, = because they are only guaranteed their money back if they use the same cond= ition from the incoming transfer they got.
Here is where the layering is bei= ng corrupted.

All connectors MUST inspect the condition in the ILP p= acket as part of their decision to route the packet or not.
When the local transfer module of the connectors stack= passes the ILP packet up to the ILP module it should indicate the properti= es of the incoming transfer that carried the packet.
This is essential firstly so that the routing logic in the IL= P module can record the incoming transfer identifier so it is able to use t= he correct response id when it passes back the fulfillment or error.
The= other properties that the ILP module should look at are the condition and = expiry on the incoming transfer.
<= br>
If the incoming route uses conditional transfers and these ar= e supposed to match the condition and expiry in the ILP packet then the ILP= module should compare them and reject the packet if:
a) the = conditions don't match OR
b) the expiry is too short
<= br>
We should still discuss if the expiry should be set by the se= nder and left unchanged or used like a TTL and decremented by each node.
=C2=A0
Also, the receiver will need to take out the condition i= n order to hash the packet for PSK or IPR.
This is completely normal. Zeroing a checksum field in = a header before calculating the checksum is VERY common precisely because i= t's long been accepted that the right place to put that data is in the = headers and the work of zero'ing it out to calculate the checksum (or s= ignature in our case) is not material.
=C2= =A0
So basically,= no one wants the condition in there. It feels like it ought to be in there= , but literally none of the parties want the extra 32 bytes in there.
=

"Nobody wants it there&q= uot; is a terrible reason to abandon the correct design. The whole purpose = of a good architecture is you accept that there may be cases in future that= haven't been considered now so designing just for the known cases is a= bad idea.

Good architecture is not the same as optimizat= ion. Taking stuff out (even when it feels wrong) to save a few bytes is a g= ood sign that it's a bad idea.
=C2=A0

The = reason the timeout should not be in there is that there isn't a single = timeout for the payment. There are multiple separate timeouts for each of t= he bilateral transfers. Those must go in the individual transfers and there= is no sensible value to put in the Interledger packet.
=C2=A0
As above, this is somewhat equivalent to = the TTL in an IP packet. I'm open to discussing if it should be a fixed= value set by the sender where each node uses their own value but has the s= ender-defined value as a reference or it is actually decremented at each ho= p.

Either way, this is part of ILP not the ledger layer j= ust like the condition and fulfillment. It may be used by the ledger layer = but that's implementation specific. It belongs in the ILP packet.
=C2=A0



--089e0821150cecb7220556cb3385-- From nobody Tue Aug 15 09:35:52 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255F3126BF3 for ; Tue, 15 Aug 2017 09:35:51 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 VNWA1HVD_wbB for ; Tue, 15 Aug 2017 09:35:46 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 C386A12426E for ; Tue, 15 Aug 2017 09:35:45 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id n125so4282756vke.1 for ; Tue, 15 Aug 2017 09:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t94ts94vQtFFDGSDx/qjTK/rTz0NbGuGgBBc0VrrfaQ=; b=fKsuJ7N+kR+fG5kJSjz+K5NJna6zmmI0FjJl1/o/OiNQOSehtfqF9vFXp5z2mPBBSF dpyMOlDhH8fZIMh1Kyur41pekHPqVwrOJvkn2J7wRQlpghQPyoUvRNL9+F95ciARYFPz +HjVS7bUv/We4w6rX0NO9KIaO56WoMiRg4wO4= 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=t94ts94vQtFFDGSDx/qjTK/rTz0NbGuGgBBc0VrrfaQ=; b=csKvMoBwweHv1RiV0+efw6oQegcBEkttqDRPLne9FVQm9yFoh8yX4/BRdAbe1tQsbp Mm/WCHUwwiQYhLRkJxyKf+ROfkzNiOByhe3U7XWu9sRvpxP4oZ5NyuE1EpwRW3m4WTjH sdu8bNf5v350OtucfHkD0TWzsoemO+9JiKkeC//a6xbD61JBtPLTRZxgKVsrn9jnCyIM JtEbklJtAsZPuatcv8BLiD+oOqDikbeHTyVWqxPFBG/DaZ1Ha8P5+TH65yY5lUujXKKh JCCHfBY6Yqv/hgJhojgc6S5PDO5/m+X0LLtLcxOulsTqAvotJjCFZvf77wp/aoF9MJFM +RpQ== X-Gm-Message-State: AHYfb5gEcu6MM7fDBEm3TKqtlpbnsU+ib5P+CKSMwNVQ30TM2XXX4Obn g8+CN2irj9RIuBCvlvB8ScqGo9MyX8zl X-Received: by 10.31.188.81 with SMTP id m78mr17743809vkf.207.1502814944558; Tue, 15 Aug 2017 09:35:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.62.90 with HTTP; Tue, 15 Aug 2017 09:35:43 -0700 (PDT) In-Reply-To: References: From: Adrian Hope-Bailie Date: Tue, 15 Aug 2017 18:35:43 +0200 Message-ID: To: Ben Sharafian Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1143b724ef17110556cd5ed7" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 16:35:51 -0000 --001a1143b724ef17110556cd5ed7 Content-Type: text/plain; charset="UTF-8" On 15 August 2017 at 16:00, Ben Sharafian wrote: > In that case, the plugin or whatever is doing the accounting is the >>>> ledger. Digital value is always tracked in ledgers, so I think it does make >>>> sense to think of this as the base layer. The reason to abstract the >>>> functionality you expect from the ledger layer is precisely so you can >>>> handle it in different ways, depending on what the underlying systems >>>> provide. >>> >>> I see 3 ways to think of the layer(s) underpinning ILP: >>> >>> 1. The "Ledger Layer" provides both messaging capabilities and some >>> type of HTLA >>> >>> >>> >>> 1. There are separate plugins for messaging and for transfers and >>> when you peer with someone you have to agree on a plugin for each >>> >>> >>> 1. We standardize the messaging part and say that all goes over IP >>> and then just have more minimal plugins for the on-ledger settlements >>> >>> Number 1 is what we have and I think that still makes the most sense. >> >> > I think you're confusing implementation details and defining of interfaces >> with definition of a protocol stack. The only differences between the tree >> examples you have above is in implementation. > > > I had to scroll up after reading this to make sure it was @adrian talking, > because that seems like the opposite of what you were arguing for. > I don't think so. But I think that is part of the problem. We are not all focused on the same thing. I am actually not very interested in CLP at all. It is one of potentially many protocols that may exist below the ILP layer. All we're doing by defining CLP is bootstrapping the network by defining a protocol for everyone to use to get started. In designing the ILP layer properly we should try and forget everything we know about the lower layers other than what features we require of them. There is a misconception that ILP requires the lower layers to support conditional transfers, that is not true. All we actually need from a lower layer protocol is to transfer data back and forth and provide a way to reliably map requests to responses. What ILP provides lower layers is a way to reward your peer for passing on the packet. The Internetworking layer defines a condition, a reward that must be paid to the receiver for the fulfillment and the time allowed to claim this reward. Because of this, within lower-layer protocols that offer the basic request/response features we need, we could add conditional payment semantics that use the condition, expiry and fulfillment provided by ILP. This would allow a node to offer a reward to their next peer to for delivering the packet they send them and to make the local financial transaction contingent on the end-to-end transaction. But crucially, adding that semantic to the lower layer protocol provides nothing extra to the ILP layer. The value is purely derived from the two peers who use that protocol and can now use conditional payments to protect themselves from their peers. > The proposal that you're arguing for is basically asserting that we're > going to be using CLP, because it makes the assumption that the connectors > (who understand ILP) are managing the HTLA logic. > Not at all. I am asserting that it doesn't matter what protocol you use below the ILP layer because it shouldn't matter. All of this talk about ILP being different because money is more important than data is nonsense. The difference between ILP and IP that makes ILP suitable for value transfer and IP not is at the internetworking layer. ILP requires that all packets are either a request or response and that the responses follow the same path as the requests. Further ILP defines a signature scheme that gives the sender a way to be certain the request was received by the receiver. *This could be done entirely without money* but then there would be little incentive to sign the receipt or deliver the signature back to the original sender. So, if you add money then you add economic incentives to the mix. At each hop the sender promises the next upstream peer a payment if they can return the receipt. The net effect is that this can be used to transfer money from the sender to the receiver by simply defining up front the amount that the receiver must get to produce the signature. > > In the current model, the CLP/trustline model and the direct ledger model > both work without having to treat anything on the ILP layer differently. > We're favoring on-ledger messaging because of our implementation, yes, but > we've been able to switch most all of our plugins from on-ledger messaging > to RPC-based messaging without changing the ILP layer at all. > > With the ledger-level abstraction, we were able to switch from our > ledger-based mode of thinking to the CLP/trustline based way without > changing anything other than the plugin. Your argument comes from an > assumption of a CLP-style ledger protocol with some underlying ledger, > which we can't assume is always the case. > I'm not sure what any of that proves tbh. These are all implementation concerns. They don't change the fact that the condition, expiry and fulfillment are part of ILP not the lower layer protocols. > > > From the perspective of the Interledger Protocol the implementation of the >> lower layers is not important, that's the whole point of layering. By >> forcing important aspects of ILP like the condition, fulfillment and expiry >> down into those layers you muddy the waters and we now have to standardize >> those protocols too. Instead we should just be defining the functions they >> must provide and then leave it up to implementations to provide those >> functions. > > > I don't agree with this point; the condition and fulfillment have actual > meaning to the ledger layer. > NO THEY DON'T! They have meaning to SOME ledgers that implement SOME lower layer protocols, IF they choose to use them. Excuse the shouting but this is the crux of the issue. We need to all agree that it is entirely possible for a transfer to be done that doesn't use the condition and fulfillment and that if this was in the middle of a 10-hop ILP payment it would have no effect on the sender and receiver. > > You've said that the ledger often doesn't care about fulfillment and > condition, but the ledger _layer_'s (where transfers are done) role is to > take in condition and fulfillment and make a transfer which satisfies its > HTLA. > No, the ledger's role is to keep a tab of net financial positions between two peers. It MAY use conditions and fulfillments that it pulls from the ILP layer to help it do that in a way both peers agree on. Note that a "layer" doesn't have a role. I think there is some confusion about the difference between layering the protocol and abstracting functionality into different components. > If the ledger layer has to look into the ILP packet to do so, that is a > blatant breaking of layering. > Not at all! The module acting at the layers *below* the internetworking layer shouldn't modify anything inside the packets of the higher layers but they can definitely inspect them and adjust their behavior based on what they to find. In fact the prevalence of this is the subject of a lot of debate at the IETF currently because endpoints are often encrypting their payloads and in some cases this makes it difficult for middle-boxes to be effective at their jobs. By putting the condition, fulfillment, and expiry on the ledger layer, we > leave it open for any ledger type to work, rather than forcing all > ledger-layer software to understand ILP. > Actually you do the opposite. You make it a requirement of every protocol below the ILP layer to define a way to carry these data elements and encode and decode them, even if they don't use them Ledger layer components don't have to understand ILP unless they choose to re-use the condition for their own local transfer. Ledgers themselves *never* have to understand ILP. Remember a ledger layer protocol could use a completely different conditional payments scheme, like atomic mode ILP, where it takes the end-to-end condition and creates a new compound condition that depends on the fulfillment and some notary signature. There will be a component in a connector's stack that must pass the ILP packet to the next peer. If it does this using a transfer protocol that uses conditional transfers and wants to use the same condition as the ILP packet then it must decode the packet. But, it will likely do something with that condition before sending the transfer to the ledger like encoding it differently or rehashing it (lightning?) so that it's in the form expected by the ledger. That's an implementation decision of the lower layer protocol used between those two peers. > > I agree that Interledger defines how conditions, fulfillments, and > expiries should be chained together, but it makes no assertions about their > data format. > ILP doesn't define how anything is chained together. From the perspective of ILP the condition and fulfillment are end-to-end data. They are agreed by the two endpoints who don't care how they get from Alice to Bob and back. The design of ILP is such that it facilitates the design of lower level protocols that can be used to carry the ILP packets across multiple hops (networks) using economic incentives such that the sender pays enough for the first hop to ensure that all nodes in between can extract the fee they want and the receiver will still get the amount they expected.. > ILP says you should send your outgoing transfer with the same condition as > the incoming one, and a lower expiry. > No it doesn't. An internetworking protocol can't prescribe that kind of thing to lower level protocols. An incoming and outgoing transfer could be sent using completely different protocols and the financial agreement with the peers on those two routes could be vastly different too. The only service ILP requires of lower level protocols is that they can map a response to an original request. This requirement is okay because it is isolated to a single route/link at a time not a requirement that crosses the inter-network boundary that ILP crosses. > But because ILP allows for many different types of ledgers, it doesn't > make sense to assert how these are encoded. > By putting them in the ILP packet you do the opposite. You make no assertions about how they are encoded if they are used at lower layers, or how they may be combined with other conditions or even used to derive new conditions. > > IP doesn't tell you how to encode an ethernet packet. It doesn't even know > whether it's going over a computer or a hand-written letter carried by a > pigeon. IP takes for granted that you can send data over one connection by > putting it in a lower level. > Correct, but if a link layer protocol wanted to look into the IP packet headers of a packet it wants to transfer and use some data from there in its internal logic (or even reuse data in it's own frame) that would be totally fine. > Even though IP tells you how to chain these connections together, it > doesn't have to put the things it's chaining on the internetworking level. > IP doesn't tell you how to chain things together. IP simply defines the end-to end data envelope and address space. Because of this nodes that implement the multiple lower layer protocols are able to push IP packets down a link and expect the node on the other side to understand the headers and route it onward on another link. Everything needed by the IP module to decide what to do with the packet is in the IP packet headers. i.e. Has it exceeded a TTL? Is there a route for this destination? Is it corrupted (checksum fails)? But also, everything that is needed by the endpoint (like the source address) is also in there. There is no dependency on nodes to be good citizens and always pass certain other data from the lower layers into the next link. That would be breaking the layering. > IP also assumes that if you get some incoming data on a connection you can > copy it and send it out on the next connection. Because you can already > send data over a connection, all IP adds is the missing piece: a packet > that tells you where to go. > > With ILP, we assume that there is a way to prepare a conditional transfer, > expire a conditional transfer, and fulfill a conditional transfer. > No we don't! We assume that if we deliver the packet as intended we'll get back a response packet with a signature that matches the condition in the packet. So, if we have an agreement with someone that they will pay us when we present that signature then we are prepared to enter a similar agreement with the next peer because we expect that signature to come all the way back along the interledger layer route.. > We also assume that if you get an incoming transfer you can create an > outgoing transfer with the same condition. The abstraction we made means > that conditions and fulfillments are already carried in the lower levels. > That is a bad assumption that comes from the broken layering. What if my outgoing link doesn't support conditional transfers? So now where do I put the condition? > > > We could have assumed that no ledgers ever support conditional transfers, > and said the only thing ILP gets from lower levels is the ability to send a > transfer. But if we want to support the case where any of them do, we have > to keep the conditions and fulfillments in the layer where they're actually > used. > I don't follow that logic at all. If we want to support the case where any of them do then we must ensure the condition and expiry are always carried in a consistent place at the internetworking layer so that if they do want to use them they know where to find them. > > On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < > adrian@hopebailie.com> wrote: > >> >> >> On 14 August 2017 at 22:03, Evan Schwartz wrote: >> >>> I think this thread is going to get extremely unwieldy but here goes: >>> >>> > - All interledger layer messages should be ILP packets (including >>> fulfillments) and be capable of carrying higher layer protocol payloads. >>> >>> Interledger has higher requirements than ILP for the lowest layer, >>> specifically because we are carrying money and not just data. One of the >>> requirements is being able to transmit a 32-byte fulfillment back along the >>> same path that carried the payment originally. If we expect this of the >>> lower layer, I don't see a point in putting the fulfillment into an ILP >>> packet and transmitting it as Interledger data along the same path. All >>> ledger-layer protocols will need to interpret the fulfillment passed in >>> their protocol, not the one passed through the Interledger layer. >>> >> >> This is not correct. There is no requirement on ledger layer protocols to >> transmit or understand the fulfillment. You are looking at this through the >> lens of existing implementations from the bottom up instead of starting at >> the interledger layer. >> >> The primary function of the condition and fulfillment is as a signed >> end-to-end receipt. If the sender agrees a condition with a receiver and >> then gets back the valid fulfillment they don't care what happened in the >> middle. The receiver has signed a receipt saying they have their money. >> >> The value of using a standard for the receipt and signature is that each >> transfer along the way CAN re-use it. One the one hand you can have a >> transfer between two peers that have zero trust and the ledger they use >> supports conditional payments completely. On the other extreme you can have >> two peers that have a full trust and ignore the condition and fulfillment >> completely. >> >> The ledger layer protocols carry ILP packets. Payment requests and either >> fulfillment or error responses. If a ledger layer protocol wants to use the >> condition and fulfillment for their own operations they can extract these >> from the ILP packets and use them. >> >> >>> > - While it may make sense to split the interledger payment and >>> interledger quoting protocols into new higher level protocols that seems >>> like an unnecessary abstraction. Instead the packet definitions should just >>> have some consistency and probably a common base/header. >>> >>> The current protocols effectively have this header but it isn't >>> separated out. There are two fields in the request header: type and >>> destination address. There is one field in the response header: type. I >>> don't think it makes that much of a big difference to separate these fields >>> if all of the fields in that packet need to be interpreted together (for >>> example, you can't understand a quote request if you strip off the >>> destination address). >>> >> >> I agree that we don't HAVE to explicitly separate them out but I think ti >> would make it clearer how the stack is architected if there was a header >> that was consistent across all packets. Currently the only thing that is >> consitent across all ILP packets is that they are defined int he same file. >> >> >>> >>> > - We should define two base ILP packet types: request and response. >>> >>> Unless this adds some substantive benefit or new fields I don't think >>> it's worth breaking all of the formats we have just to rearrange things. >>> >> >> The goal of this exercise is to tease out the best design and ignore the >> cost of change until we can compare the results with the current design. >> >> >>> >>> > - ILP is not about ledgers, it is about trustlines between >>> nodes/hosts. >>> >>> A ledger is any system that tracks accounts and balances. When you use a >>> trustline all of your messages still need to go through an accounting >>> system (such as the plugin in the JS implementation) and then on to the >>> other program logic. >>> >> >> As above, this is incorrect. There is no requirement for "all messages to >> go through an accounting system". >> >> Since designing the first implementation of 5-bells ledger we have >> assumed that passing the ILP packet MUST be done by the ledger because that >> is how we implemented it. But that is not true. It is perfectly valid for >> the passing of an ILP packet from one peer to another to be simply an >> exchange of data. >> >> The receiving peer makes a decision about whether or not to forward the >> packet based on the current financial position they have with the sending >> peer. >> >> It is convenient if the ledger that records the net positions of the >> peers also forwards the messaging and even better if it natively supports >> conditional payments and can use the condition and the fulfillment from the >> ILP packet for those but that's all it is, convenient. >> >> >> >>> In that case, the plugin or whatever is doing the accounting is the >>> ledger. Digital value is always tracked in ledgers, so I think it does make >>> sense to think of this as the base layer. The reason to abstract the >>> functionality you expect from the ledger layer is precisely so you can >>> handle it in different ways, depending on what the underlying systems >>> provide. >>> >>> I see 3 ways to think of the layer(s) underpinning ILP: >>> >>> 1. The "Ledger Layer" provides both messaging capabilities and some >>> type of HTLA >>> >>> 2. There are separate plugins for messaging and for transfers and >>> when you peer with someone you have to agree on a plugin for each >>> 3. We standardize the messaging part and say that all goes over IP >>> and then just have more minimal plugins for the on-ledger settlements >>> >>> Number 1 is what we have and I think that still makes the most sense. >>> >> >> I think you're confusing implementation details and defining of >> interfaces with definition of a protocol stack. The only differences >> between the tree examples you have above is in implementation. >> >> From the perspective of the Interledger Protocol the implementation of >> the lower layers is not important, that's the whole point of layering. By >> forcing important aspects of ILP like the condition, fulfillment and expiry >> down into those layers you muddy the waters and we now have to standardize >> those protocols too. Instead we should just be defining the functions they >> must provide and then leave it up to implementations to provide those >> functions. >> >> I know we want to define a standard to bootstrap the system (CLP) but >> that's misleading us into thinking it's an essential part of the stack. >> It's perfectly valid for two peers to not use CLP and still be part of the >> Interledger. >> >> That said, you raise an interesting consideration about the layers below >> ILP and actually I think it makes sense to split these. >> >> We keep trying to force messaging through the ledger layer and actually >> that's the wrong place to put it if we can split the ledger layer into a >> messaging layer and a ledger layer. That way we can stop trying to think of >> all HLTAs as ledgers. >> >> A thought, why not use sub-layers as is common in other stacks: >> >> 1. Link layer: Layer upon which two peers that have a direct link, or >> participate in the same payment network, communicate >> 2. Transfer/ ledger: Layer on which financial positions between two peers >> are recorded >> >> This reflects the already emerging HTLA model and many of our existing >> plugins and ledger integrations. >> Link Layer: XRP Paychan, Lightning >> Ledger Layer: XRP Ledger, Bitcoin >> >> This doesn't prevent us from defining a standard binary protocol that >> defines all of the operations for both layers (like CLP) but I see value in >> distinguishing between these two. >> >> >>> >>> > - The protocol should differentiate between the operation of >>> preparing a transfer on a ledger and the operation of passing an ILP packet >>> from one peer to another. >>> >>> The protocol assumes your conditional transfer is underpinned by some >>> HTLA >>> . >>> It doesn't care whether that's on-ledger or not. >>> >> >> What do you mean when you say "the protocol"? In my statement I am >> referring to ILP. >> My point above being that ILP expects ILP packets to be passed from peer >> to peer but has no expectations about transfers. >> >> It's perfectly legal (from an ILP perspective) for two peers to exchange >> ILP packets with no transfers. Clearly if a node routes a packet on and has >> no incoming transfer it's going to lose money but that's a consideration >> for that node. It doesn't affect anyone else in the chain. >> >> ILP doesn't assume anything about transfers at all, let alone conditional >> transfers. It provides useful semantics for conditional transfers to be >> used by two peers to transact as part of a larger ILP payment. >> >> >>> >>> > - The condition and timeout should be included in the ILP payment >>> packet. >>> >>> I strongly disagree with this. We had this debate a year ago and I was >>> on your side but was convinced that this is not a good idea. >>> >> >> Yes, I recall this and I'm sorry I didn't push harder on this point. >> Unfortunately I think the decision to pull it out of the packet is mostly >> driven by how our prototypes were implemented rather than good architecture. >> >>> >>> The layer below ILP must be capable of doing conditional transfers based >>> on sha256 hashlocks with 32-byte preimages. >>> >> >> This is not true and I think it would be useful for us to agree on this >> as this seems to be the argument I am coming up against most often. The >> peers participating in a transfer that is part of an ILP payment may wish >> to use conditional transfers as a way to enforce their agreement but this >> is not a requirement of the protocol. >> >> The agreement between any two peers is: "I will pay you X if you can >> provide a receipt that Y was paid Z before T". >> ILP provides a standard for expressing this agreement so that these can >> be chained together BUT it is not a requirement that every agreement in the >> chain uses the condition, and fulfillment provided at the ILP layer. >> >> >>> >>> As a result, the original condition and the corresponding preimage MUST >>> be expressed in that layer. >>> >> >> As I have shown above, this is not true. >> >> >>> Then the question is whether we should also include it in the packet >>> that is forwarded. What ultimately convinced me is the following: All >>> connectors MUST ignore the condition if it is in the packet, because they >>> are only guaranteed their money back if they use the same condition from >>> the incoming transfer they got. >>> >> >> Here is where the layering is being corrupted. >> >> All connectors MUST inspect the condition in the ILP packet as part of >> their decision to route the packet or not. >> When the local transfer module of the connectors stack passes the ILP >> packet up to the ILP module it should indicate the properties of the >> incoming transfer that carried the packet. >> This is essential firstly so that the routing logic in the ILP module can >> record the incoming transfer identifier so it is able to use the correct >> response id when it passes back the fulfillment or error. >> The other properties that the ILP module should look at are the condition >> and expiry on the incoming transfer. >> >> If the incoming route uses conditional transfers and these are supposed >> to match the condition and expiry in the ILP packet then the ILP module >> should compare them and reject the packet if: >> a) the conditions don't match OR >> b) the expiry is too short >> >> We should still discuss if the expiry should be set by the sender and >> left unchanged or used like a TTL and decremented by each node. >> >> >>> Also, the receiver will need to take out the condition in order to hash >>> the packet for PSK or IPR. >>> >> >> This is completely normal. Zeroing a checksum field in a header before >> calculating the checksum is VERY common precisely because it's long been >> accepted that the right place to put that data is in the headers and the >> work of zero'ing it out to calculate the checksum (or signature in our >> case) is not material. >> >> >>> So basically, no one wants the condition in there. It feels like it >>> ought to be in there, but literally none of the parties want the extra 32 >>> bytes in there. >>> >> >> "Nobody wants it there" is a terrible reason to abandon the correct >> design. The whole purpose of a good architecture is you accept that there >> may be cases in future that haven't been considered now so designing just >> for the known cases is a bad idea. >> >> Good architecture is not the same as optimization. Taking stuff out (even >> when it feels wrong) to save a few bytes is a good sign that it's a bad >> idea. >> >> >>> >>> The reason the timeout should not be in there is that there isn't a >>> single timeout for the payment. There are multiple separate timeouts for >>> each of the bilateral transfers. Those must go in the individual transfers >>> and there is no sensible value to put in the Interledger packet. >>> >> >> As above, this is somewhat equivalent to the TTL in an IP packet. I'm >> open to discussing if it should be a fixed value set by the sender where >> each node uses their own value but has the sender-defined value as a >> reference or it is actually decremented at each hop. >> >> Either way, this is part of ILP not the ledger layer just like the >> condition and fulfillment. It may be used by the ledger layer but that's >> implementation specific. It belongs in the ILP packet. >> >>> >>> >>> >> > --001a1143b724ef17110556cd5ed7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 15 August 2017 at 16:00, Ben Sharafian <sharafian@ripple.com= > wrote:
In that case, = the plugin or whatever is doing the accounting is the ledger. Digital value= is always tracked in ledgers, so I think it does make sense to think of th= is as the base layer. The reason to abstract the functionality you expect f= rom the ledger layer is precisely so you can handle it in different ways, d= epending on what the underlying systems provide.
I see 3 ways t= o think of the layer(s) underpinning ILP:
  1. The "Ledger Layer" provides both messaging capa= bilities and some type of=C2=A0HTLA
  1. There are separate plugins for messaging and for transfers and w= hen you peer with someone you have to agree on a plugin for each
<= ol>
  • We standardize the messaging part and say= that all goes over IP and then just have more minimal plugins for the on-l= edger settlements
    • Number 1 is what we have and I think that still = makes the most sense.

    I t= hink you're confusing implementation details and defining of interfaces= with definition of a protocol stack. The only differences between the tree= examples you have above is in implementation.

    =
    I had to scroll up after reading this to make sure it was= @adrian talking, because that seems like the opposite of what you were arg= uing for.

    I don't think so= . But I think that is part of the problem. We are not all focused on the sa= me thing. I am actually not very interested in CLP at all. It is one of pot= entially many protocols that may exist below the ILP layer. All we're d= oing by defining CLP is bootstrapping the network by defining a protocol fo= r everyone to use to get started.

    In designing the ILP la= yer properly we should try and forget everything we know about the lower la= yers other than what features we require of them.

    There i= s a misconception that ILP requires the lower layers to support conditional= transfers, that is not true.

    All we actually need from a= lower layer protocol is to transfer data back and forth and provide a way = to reliably map requests to responses.

    What ILP provides = lower layers is a way to reward your peer for passing on the packet. The In= ternetworking layer defines a condition, a reward that must be paid to the = receiver for the fulfillment and the time allowed to claim this reward.
    =

    Because of this, within lower-layer protocols tha= t offer the basic request/response features we need, we could add condition= al payment semantics that use the condition, expiry and fulfillment provide= d by ILP. This would allow a node to offer a reward to=C2=A0 their next pee= r to for delivering the packet they send them and to make the local financi= al transaction contingent on the end-to-end transaction.

    = But crucially, adding that semantic to the lower layer protocol provides no= thing extra to the ILP layer. The value is purely derived from the two peer= s who use that protocol and can now use conditional payments to protect the= mselves from their peers.
    =C2=A0
    The proposal that you'= re arguing for is basically asserting that we're going to be using CLP,= because it makes the assumption that the connectors (who understand ILP) a= re managing the HTLA logic.

    Not= at all. I am asserting that it doesn't matter what protocol you use be= low the ILP layer because it shouldn't matter. All of this talk about I= LP being different because money is more important than data is nonsense.
    The difference between ILP and IP that makes ILP suitable for v= alue transfer and IP not is at the internetworking layer. ILP requires that= all packets are either a request or response and that the responses follow= the same path as the requests. Further ILP defines a signature scheme that= gives the sender a way to be certain the request was received by the recei= ver.

    This could be done entirely= without money but then there would be little incentive to sign the rec= eipt or deliver the signature back to the original sender.

    So, if you add money then you add economic incentiv= es to the mix. At each hop the sender promises the next upstream peer a pay= ment if they can return the receipt. The net effect is that this can be use= d to transfer money from the sender to the receiver by simply defining up f= ront the amount that the receiver must get to produce the signature.
    =C2=A0

    <= /div>
    In the current model, the CLP/trustline model and the direct ledg= er model both work without having to treat anything on the ILP layer differ= ently. We're favoring on-ledger messaging because of our implementation= , yes, but we've been able to switch most all of our plugins from on-le= dger messaging to RPC-based messaging without changing the ILP layer at all= .

    With the ledger-level abstraction, we were able = to switch from our ledger-based mode of thinking to the CLP/trustline based= way without changing anything other than the plugin. Your argument comes f= rom an assumption of a CLP-style ledger protocol with some underlying ledge= r, which we can't assume is always the case.

    I'm not sure what any of that proves tbh. These are all im= plementation concerns. They don't change the fact that the condition, e= xpiry and fulfillment are part of ILP not the lower layer protocols.
    =C2=A0

    = >From the perspective of the Interledger Protocol the implementation of the = lower layers is not important, that's the whole point of layering. By f= orcing important aspects of ILP like the condition, fulfillment and expiry = down into those layers you muddy the waters and we now have to standardize = those protocols too. Instead we should just be defining the functions they = must provide and then leave it up to implementations to provide those funct= ions.

    I don't agree with = this point; the condition and fulfillment have actual meaning to the ledger= layer.

    NO THEY DON'T! The= y have meaning to SOME ledgers that implement SOME lower layer protocols, I= F they choose to use them.

    Excuse the shouting but this i= s the crux of the issue. We need to all agree that it is entirely possible = for a transfer to be done that doesn't use the condition and fulfillmen= t and that if this was in the middle of a 10-hop ILP payment it would have = no effect on the sender and receiver.
    =C2=A0
    You've said that the = ledger often doesn't care about fulfillment and condition, but the ledg= er _layer_'s (where transfers are done) role is to take in condition an= d fulfillment and make a transfer which satisfies its HTLA.

    No, the ledger's role is to keep a tab of net = financial positions between two peers. It MAY use conditions and fulfillmen= ts that it pulls from the ILP layer to help it do that in a way both peers = agree on.

    Note that a "layer&q= uot; doesn't have a role. I think there is some confusion about the dif= ference between layering the protocol and abstracting functionality into di= fferent components.
    =C2=A0
    <= div dir=3D"ltr">
    If the ledger layer has to look into the ILP packet to= do so, that is a blatant breaking of layering.

    Not at all! The module acting at the layers below = the internetworking layer shouldn't modify anything inside the packets = of the higher layers but they can definitely inspect them and adjust their = behavior based on what they to find.

    In fact the prevalence of= this is the subject of a lot of debate at the IETF currently because endpo= ints are often encrypting their payloads and in some cases this makes it di= fficult for middle-boxes to be effective at their jobs.

    By putting the condition, fulfillment, and expiry on the = ledger layer, we leave it open for any ledger type to work, rather than for= cing all ledger-layer software to understand ILP.
    <= div>
    Actually you do the opposite. You make it a requirement = of every protocol below the ILP layer to define a way to carry these data e= lements and encode and decode them, even if they don't use them

    =
    Ledger layer components don't have to understand ILP unless = they choose to re-use the condition for their own local transfer. Ledgers t= hemselves never have to understand ILP.

    Remember a ledger la= yer protocol could use a completely different conditional payments scheme, = like atomic mode ILP, where it takes the end-to-end condition and creates a= new compound condition that depends on the fulfillment and some notary sig= nature.

    There will be a component in a connector's st= ack that must pass the ILP packet to the next peer. If it does this using a= transfer protocol that uses conditional transfers and wants to use the sam= e condition as the ILP packet then it must decode the packet.

    =
    But, it will likely do something with that condition before sending th= e transfer to the ledger like encoding it differently or rehashing it (ligh= tning?) so that it's in the form expected by the ledger.
    =
    That's an implementation decision of the lower layer pro= tocol used between those two peers.
    =C2=A0

    I= agree that Interledger defines how conditions, fulfillments, and expiries = should be chained together, but it makes no assertions about their data for= mat.

    ILP doesn't define ho= w anything is chained together. From the perspective of ILP the condition a= nd fulfillment are end-to-end data. They are agreed by the two endpoints wh= o don't care how they get from Alice to Bob and back.

    The design of ILP is such that it facilitates the design of lower level pr= otocols that can be used to carry the ILP packets across multiple hops (net= works) using economic incentives such that the sender pays enough for the f= irst hop to ensure that all nodes in between can extract the fee they want = and the receiver will still get the amount they expected..

    =C2=A0
    ILP says you should send your outgoing transfer with the same co= ndition as the incoming one, and a lower expiry.
    <= div>
    No it doesn't. An internetworking protocol can't= prescribe that kind of thing to lower level protocols. An incoming and out= going transfer could be sent using completely different protocols and the f= inancial agreement with the peers on those two routes could be vastly diffe= rent too.

    The only service ILP requires of lower level protocols is = that they can map a response to an original request. This requirement is ok= ay because it is isolated to a single route/link at a time not a requiremen= t that crosses the inter-network boundary that ILP crosses.
    = =C2=A0
    But because ILP allows for many different types of ledgers, it doe= sn't make sense to assert how these are encoded.

    By putting them in the ILP packet you do the opposite= . You make no assertions about how they are encoded if they are used at low= er layers, or how they may be combined with other conditions or even used t= o derive new conditions.

    IP doesn't tell you how= to encode an ethernet packet. It doesn't even know whether it's go= ing over a computer or a hand-written letter carried by a pigeon. IP takes = for granted that you can send data over one connection by putting it in a l= ower level.

    Correct, but if a = link layer protocol wanted to look into the IP packet headers of a packet i= t wants to transfer and use some data from there in its internal logic (or = even reuse data in it's own frame) that would be totally fine.
    =C2=A0
    Even though IP tells you how to chain these connections toge= ther, it doesn't have to put the things it's chaining on the intern= etworking level.

    IP doesn'= t tell you how to chain things together. IP simply defines the end-to end d= ata envelope and address space. Because of this nodes that implement the mu= ltiple lower layer protocols are able to push IP packets down a link and ex= pect the node on the other side to understand the headers and route it onwa= rd on another link.

    Everything needed by the IP module to= decide what to do with the packet is in the IP packet headers. i.e. Has it= exceeded a TTL? Is there a route for this destination? Is it corrupted (ch= ecksum fails)? But also, everything that is needed by the endpoint (like th= e source address) is also in there.

    There is no dependenc= y on nodes to be good citizens and always pass certain other data from the = lower layers into the next link. That would be breaking the layering.
    =C2=A0
    IP also assumes that if you get some incoming data on a c= onnection you can copy it and send it out on the next connection. Because y= ou can already send data over a connection, all IP adds is the missing piec= e: a packet that tells you where to go.

    With ILP, = we assume that there is a way to prepare a conditional transfer, expire a c= onditional transfer, and fulfill a conditional transfer.

    No we don't! We assume that if we deliver th= e packet as intended we'll get back a response packet with a signature = that matches the condition in the packet. So, if we have an agreement with = someone that they will pay us when we present that signature then we are pr= epared to enter a similar agreement with the next peer because we expect th= at signature to come all the way back along the interledger layer route..
    =C2=A0
    =
    We also assume that if you get an incoming transfer y= ou can create an outgoing transfer with the same condition. The abstraction= we made means that conditions and fulfillments are already carried in the = lower levels.

    That is a bad ass= umption that comes from the broken layering. What if my outgoing link doesn= 't support conditional transfers? So now where do I put the condition?<= br>
    =C2=A0

    We could have assumed that no ledgers ever sup= port conditional transfers, and said the only thing ILP gets from lower lev= els is the ability to send a transfer. But if we want to support the case w= here any of them do, we have to keep the conditions and fulfillments in the= layer where they're actually used.

    I don't follow that logic at all. If we want to support the ca= se where any of them do then we must ensure the condition and expiry are al= ways carried in a consistent place at the internetworking layer so that if = they do want to use them they know where to find them.
    =C2=A0=

    On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    =
    On 14 August 2017 at 22:03, Evan Schwartz = <= evan@ripple.com> wrote:
    I think this thread is going to get extrem= ely unwieldy but here goes:

    >=C2=A0- All interledger layer messages should be ILP pac= kets (including fulfillments) and be capable of carrying higher layer proto= col payloads.

    Interledger has higher= requirements than ILP for the lowest layer, specifically because we are ca= rrying money and not just data. One of the requirements is being able to tr= ansmit a 32-byte fulfillment back along the same path that carried the paym= ent originally. If we expect this of the lower layer, I don't see a poi= nt in putting the fulfillment into an ILP packet and transmitting it as Int= erledger data along the same path. All ledger-layer protocols will need to = interpret the fulfillment passed in their protocol, not the one passed thro= ugh the Interledger layer.

    Th= is is not correct. There is no requirement on ledger layer protocols to tra= nsmit or understand the fulfillment. You are looking at this through the le= ns of existing implementations from the bottom up instead of starting at th= e interledger layer.

    The primary f= unction of the condition and fulfillment is as a signed end-to-end receipt.= If the sender agrees a condition with a receiver and then gets back the va= lid fulfillment they don't care what happened in the middle. The receiv= er has signed a receipt saying they have their money.

    The value of using a standard for the receipt and signat= ure is that each transfer along the way CAN re-use it. One the one hand you= can have a transfer between two peers that have zero trust and the ledger = they use supports conditional payments completely. On the other extreme you= can have two peers that have a full trust and ignore the condition and ful= fillment completely.
    =C2=A0
    Th= e ledger layer protocols carry ILP packets. Payment requests and either ful= fillment or error responses. If a ledger layer protocol wants to use the co= ndition and fulfillment for their own operations they can extract these fro= m the ILP packets and use them.


    >=C2=A0- While it may make sense to split the interledger payme= nt and interledger quoting protocols into new higher level protocols that s= eems like an unnecessary abstraction. Instead the packet definitions should= just have some consistency and probably a common base/header.
    =

    The current protocols effectively have this = header but it isn't separated out. There are two fields in the request = header: type and destination address. There is one field in the response he= ader: type. I don't think it makes that much of a big difference to sep= arate these fields if all of the fields in that packet need to be interpret= ed together (for example, you can't understand a quote request if you s= trip off the destination address).

    =
    I agree that we don't HAVE to explicitly separate the= m out but I think ti would make it clearer how the stack is architected if = there was a header that was consistent across all packets. Currently the on= ly thing that is consitent across all ILP packets is that they are defined = int he same file.
    =C2=A0

    >= ;=C2=A0- We should define two ba= se ILP packet types: request and response.

    Unless this adds some substantive be= nefit or new fields I don't think it's worth breaking all of the fo= rmats we have just to rearrange things.

    The goal of this exercise is to tease out the best design a= nd ignore the cost of change until we can compare the results with the curr= ent design.
    =C2=A0

    >=C2=A0- ILP is not about ledgers, it is about tr= ustlines between nodes/hosts.

    A ledger is any system that tracks accounts and balances. When= you use a trustline all of your messages still need to go through an accou= nting system (such as the plugin in the JS implementation) and then on to t= he other program logic.

    As above, this is incorrect. There is no requirement for "all message= s to go through an accounting system".

    Since designi= ng the first implementation of 5-bells ledger we have assumed that passing = the ILP packet MUST be done by the ledger because that is how we implemente= d it. But that is not true. It is perfectly valid for the passing of an ILP= packet from one peer to another to be simply an exchange of data.

    <= /div>
    The receiving peer makes a decision about whether or not to forwa= rd the packet based on the current financial position they have with the se= nding peer.

    It is convenient if the ledger tha= t records the net positions of the peers also forwards the messaging and ev= en better if it natively supports conditional payments and can use the cond= ition and the fulfillment from the ILP packet for those but that's all = it is, convenient.

    =C2=A0
    In that case, the plugi= n or whatever is doing the accounting is the ledger. Digital value is alway= s tracked in ledgers, so I think it does make sense to think of this as the= base layer. The reason to abstract the functionality you expect from the l= edger layer is precisely so you can handle it in different ways, depending = on what the underlying systems provide.

    I see 3 wa= ys to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messaging capabilities an= d some type of HTLA
    2. There are separate plugins for messagin= g and for transfers and when you peer with someone you have to agree on a p= lugin for each
    3. We standardize the messaging part and say that all g= oes over IP and then just have more minimal plugins for the on-ledger settl= ements
    Number 1 is what we have and I think that still makes = the most sense.

    I think you're= confusing implementation details and defining of interfaces with definitio= n of a protocol stack. The only differences between the tree examples you h= ave above is in implementation.

    From the perspective of the Interled= ger Protocol the implementation of the lower layers is not important, that&= #39;s the whole point of layering. By forcing important aspects of ILP like= the condition, fulfillment and expiry down into those layers you muddy the= waters and we now have to standardize those protocols too. Instead we shou= ld just be defining the functions they must provide and then leave it up to= implementations to provide those functions.

    I know we want to define a standard to bootstrap the system (CLP)= but that's misleading us into thinking it's an essential part of t= he stack. It's perfectly valid for two peers to not use CLP and still b= e part of the Interledger.

    That said, you raise an interesting considera= tion about the layers below ILP and actually I think it makes sense to spli= t these.

    We keep trying to force messaging through the le= dger layer and actually that's the wrong place to put it if we can spli= t the ledger layer into a messaging layer and a ledger layer. That way we c= an stop trying to think of all HLTAs as ledgers.

    A though= t, why not use sub-layers as is common in other stacks:

    1= . Link layer: Layer upon which two peers that have a direct link, or partic= ipate in the same payment network, communicate
    2. Transfer/ l= edger: Layer on which financial positions between two peers are recorded
    This reflects the already emerging HTLA model and many of our existing= plugins and ledger integrations.
    Link Layer: XRP Paychan, Li= ghtning
    Ledger Layer: XRP Ledger, Bitcoin

    <= /div>
    This doesn't prevent us from defining a standard binary proto= col that defines all of the operations for both layers (like CLP) but I see= value in distinguishing between these two.
    =C2=A0
    <= div>
    >=C2=A0- The prot= ocol should differentiate between the operation of preparing a transfer on = a ledger and the operation of passing an ILP packet from one peer to anothe= r.

    The protocol a= ssumes your conditional transfer is underpinned by some HTLA. It doesn't= care whether that's on-ledger or not.
    What do you mean when you say "the protocol"? In my= statement I am referring to ILP.
    My point above being that ILP expects= ILP packets to be passed from peer to peer but has no expectations about t= ransfers.

    It's perfectly legal = (from an ILP perspective) for two peers to exchange ILP packets with no tra= nsfers. Clearly if a node routes a packet on and has no incoming transfer i= t's going to lose money but that's a consideration for that node. I= t doesn't affect anyone else in the chain.

    ILP doesn't assume anything about transfers at all, let alo= ne conditional transfers. It provides useful semantics for conditional tran= sfers to be used by two peers to transact as part of a larger ILP payment.<= br>=C2=A0

    >= =C2=A0- The condition and timeout shoul= d be included in the ILP payment packet.

    =
    I strongly disagree with this. We had this debate a year ago and I was= on your side but was convinced that this is not a good idea.

    Yes, I recall this and I'm sorry = I didn't push harder on this point. Unfortunately I think the decision = to pull it out of the packet is mostly driven by how our prototypes were im= plemented rather than good architecture.

    The l= ayer below ILP must be capable of doing conditional transfers based on sha2= 56 hashlocks with 32-byte preimages.

    This is not true and I think it would be useful for us to agr= ee on this as this seems to be the argument I am coming up against most oft= en. The peers participating in a transfer that is part of an ILP payment ma= y wish to use conditional transfers as a way to enforce their agreement but= this is not a requirement of the protocol.

    The agreement= between any two peers is: "I will pay you X if you can provide a rece= ipt that Y was paid Z before T".
    ILP provides a standard= for expressing this agreement so that these can be chained together BUT it= is not a requirement that every agreement in the chain uses the condition,= and fulfillment provided at the ILP layer.

    =C2=A0
    As a resu= lt, the original condition and the corresponding preimage MUST be expressed= in that layer.

    As I ha= ve shown above, this is not true.
    =C2=A0
    Then the que= stion is whether we should also include it in the packet that is forwarded.= What ultimately convinced me is the following: All connectors MUST ignore = the condition if it is in the packet, because they are only guaranteed thei= r money back if they use the same condition from the incoming transfer they= got.

    Here is where the layering is being corrupted.

    All connectors M= UST inspect the condition in the ILP packet as part of their decision to ro= ute the packet or not.
    When the local t= ransfer module of the connectors stack passes the ILP packet up to the ILP = module it should indicate the properties of the incoming transfer that carr= ied the packet.
    This is essential first= ly so that the routing logic in the ILP module can record the incoming tran= sfer identifier so it is able to use the correct response id when it passes= back the fulfillment or error.
    The other properties that the ILP module= should look at are the condition and expiry on the incoming transfer.
    <= /div>

    If the incoming route u= ses conditional transfers and these are supposed to match the condition and= expiry in the ILP packet then the ILP module should compare them and rejec= t the packet if:
    a) the conditions don't match OR
    b) the expiry is too short

    We should still discuss= if the expiry should be set by the sender and left unchanged or used like = a TTL and decremented by each node.
    =C2=A0
    Also, the = receiver will need to take out the condition in order to hash the packet fo= r PSK or IPR.

    This is c= ompletely normal. Zeroing a checksum field in a header before calculating t= he checksum is VERY common precisely because it's long been accepted th= at the right place to put that data is in the headers and the work of zero&= #39;ing it out to calculate the checksum (or signature in our case) is not = material.
    =C2=A0
    So basically, no one wants the condi= tion in there. It feels like it ought to be in there, but literally none of= the parties want the extra 32 bytes in there.

    "Nobody wants it there" is a terrible reas= on to abandon the correct design. The whole purpose of a good architecture = is you accept that there may be cases in future that haven't been consi= dered now so designing just for the known cases is a bad idea.

    Good architecture is not the same as optimization. Taking stuff out (= even when it feels wrong) to save a few bytes is a good sign that it's = a bad idea.
    =C2=A0

    The reason the time= out should not be in there is that there isn't a single timeout for the= payment. There are multiple separate timeouts for each of the bilateral tr= ansfers. Those must go in the individual transfers and there is no sensible= value to put in the Interledger packet.
    =C2= =A0
    As above, this is somewhat equivalent to the TTL in an= IP packet. I'm open to discussing if it should be a fixed value set by= the sender where each node uses their own value but has the sender-defined= value as a reference or it is actually decremented at each hop.

    Either way, this is part of ILP not the ledger layer just like the = condition and fulfillment. It may be used by the ledger layer but that'= s implementation specific. It belongs in the ILP packet.
    =C2=A0



    --001a1143b724ef17110556cd5ed7-- From nobody Tue Aug 15 09:58:37 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8474513235C for ; Tue, 15 Aug 2017 09:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ripple.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 iReaPUoYOhhW for ; Tue, 15 Aug 2017 09:52:43 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 112541321CB for ; Tue, 15 Aug 2017 09:52:43 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id i66so14250572wmg.0 for ; Tue, 15 Aug 2017 09:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bfr2xkcgcweGMNyBNlFMnSLI+5IwU892m8pxH7sh6x8=; b=MiL03uj2vXdC694/8M9Xhy7/PaPl6EzYug5/+J+Dzj23KB7/6KDw1ECpeEHxgdECz8 h3hdHVaZAWnQbXhnQze6WFX817obpw6dMFBT/VEl8YABZ4d6tT7Ne8AqE7bpNzYIlBNh OCx5StCGhGxPn55feehGSVf/uuU3Bq0Dkv60w= 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=bfr2xkcgcweGMNyBNlFMnSLI+5IwU892m8pxH7sh6x8=; b=aTPll1/Xo9v6FxdED/7UW90QecW4hKZFW+J5SZUXYywH8iT+G4+YW/vGHs4WsmVU/p eCHlVGmAoFEKEPSQHBIty4X4b1FCCEaUC9Yr85y7UvTYNPaB7xDnX8DsA1blmMoo4Gpv gPa6anJ+0ppTgyM0q5NV7vKZQpyaL5sFUQbhif3ayFtjqWrgqPurkQ1a71d24duD0pys FbG/fvvA/Q3u7fgUnp5C/a9tmrQIyCjLx/YY+WvMXyAVE9T+RNkco0ZRgOum08LhmCXB syF6CGusTogP8Ja4Z67yQLL2ZkV7ZmpsHjVtuFfZ49q0EWPG/694LNP64slOtrVx3ycA +RBA== X-Gm-Message-State: AHYfb5hZbz5Ww1L7ZaBOat8Yn6/0pZHrYYnbzzt70EReG5KV7BEjM+Wy dSuJ4M1qv3r4u0cAy6KaxOscgt7Gy1oJ X-Received: by 10.28.236.211 with SMTP id h80mr2043982wmi.145.1502815961379; Tue, 15 Aug 2017 09:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.60.135 with HTTP; Tue, 15 Aug 2017 09:52:40 -0700 (PDT) In-Reply-To: References: From: Ben Sharafian Date: Tue, 15 Aug 2017 18:52:40 +0200 Message-ID: To: Adrian Hope-Bailie Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a11464f008a97440556cd9bf3" Archived-At: X-Mailman-Approved-At: Tue, 15 Aug 2017 09:58:35 -0700 Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 16:52:47 -0000 --001a11464f008a97440556cd9bf3 Content-Type: text/plain; charset="UTF-8" Ok, I think I have a better idea of what you're saying. It sounds like you're saying the ILP layer contains all information that is common between every hop (destination, destination amount, opaque data, condition, fulfillment, expiry). The lower level would then be used for all the transfer-local details (source amount, next connector account, custom/local data). If the lower level wanted to do anything related to the every-hop payment, i.e. escrow funds until the receipt has been produced, it would look into the ILP layer for that information. If the lower level didn't do any escrow or expiries that require every-hop details, it would simply function as a communication method. Is that right? On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie wrote: > > > On 15 August 2017 at 16:00, Ben Sharafian wrote: > >> In that case, the plugin or whatever is doing the accounting is the >>>>> ledger. Digital value is always tracked in ledgers, so I think it does make >>>>> sense to think of this as the base layer. The reason to abstract the >>>>> functionality you expect from the ledger layer is precisely so you can >>>>> handle it in different ways, depending on what the underlying systems >>>>> provide. >>>> >>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>> >>>> 1. The "Ledger Layer" provides both messaging capabilities and some >>>> type of HTLA >>>> >>>> >>>> >>>> 1. There are separate plugins for messaging and for transfers and >>>> when you peer with someone you have to agree on a plugin for each >>>> >>>> >>>> 1. We standardize the messaging part and say that all goes over IP >>>> and then just have more minimal plugins for the on-ledger settlements >>>> >>>> Number 1 is what we have and I think that still makes the most sense. >>> >>> >> I think you're confusing implementation details and defining of >>> interfaces with definition of a protocol stack. The only differences >>> between the tree examples you have above is in implementation. >> >> >> I had to scroll up after reading this to make sure it was @adrian >> talking, because that seems like the opposite of what you were arguing for. >> > > I don't think so. But I think that is part of the problem. We are not all > focused on the same thing. I am actually not very interested in CLP at all. > It is one of potentially many protocols that may exist below the ILP layer. > All we're doing by defining CLP is bootstrapping the network by defining a > protocol for everyone to use to get started. > > In designing the ILP layer properly we should try and forget everything we > know about the lower layers other than what features we require of them. > > There is a misconception that ILP requires the lower layers to support > conditional transfers, that is not true. > > All we actually need from a lower layer protocol is to transfer data back > and forth and provide a way to reliably map requests to responses. > > What ILP provides lower layers is a way to reward your peer for passing on > the packet. The Internetworking layer defines a condition, a reward that > must be paid to the receiver for the fulfillment and the time allowed to > claim this reward. > > Because of this, within lower-layer protocols that offer the basic > request/response features we need, we could add conditional payment > semantics that use the condition, expiry and fulfillment provided by ILP. > This would allow a node to offer a reward to their next peer to for > delivering the packet they send them and to make the local financial > transaction contingent on the end-to-end transaction. > > But crucially, adding that semantic to the lower layer protocol provides > nothing extra to the ILP layer. The value is purely derived from the two > peers who use that protocol and can now use conditional payments to protect > themselves from their peers. > > >> The proposal that you're arguing for is basically asserting that we're >> going to be using CLP, because it makes the assumption that the connectors >> (who understand ILP) are managing the HTLA logic. >> > > Not at all. I am asserting that it doesn't matter what protocol you use > below the ILP layer because it shouldn't matter. All of this talk about ILP > being different because money is more important than data is nonsense. > > The difference between ILP and IP that makes ILP suitable for value > transfer and IP not is at the internetworking layer. ILP requires that all > packets are either a request or response and that the responses follow the > same path as the requests. Further ILP defines a signature scheme that > gives the sender a way to be certain the request was received by the > receiver. > > *This could be done entirely without money* but then there would be > little incentive to sign the receipt or deliver the signature back to the > original sender. > > So, if you add money then you add economic incentives to the mix. At each > hop the sender promises the next upstream peer a payment if they can return > the receipt. The net effect is that this can be used to transfer money from > the sender to the receiver by simply defining up front the amount that the > receiver must get to produce the signature. > > >> >> In the current model, the CLP/trustline model and the direct ledger model >> both work without having to treat anything on the ILP layer differently. >> We're favoring on-ledger messaging because of our implementation, yes, but >> we've been able to switch most all of our plugins from on-ledger messaging >> to RPC-based messaging without changing the ILP layer at all. >> >> With the ledger-level abstraction, we were able to switch from our >> ledger-based mode of thinking to the CLP/trustline based way without >> changing anything other than the plugin. Your argument comes from an >> assumption of a CLP-style ledger protocol with some underlying ledger, >> which we can't assume is always the case. >> > > I'm not sure what any of that proves tbh. These are all implementation > concerns. They don't change the fact that the condition, expiry and > fulfillment are part of ILP not the lower layer protocols. > >> >> >> From the perspective of the Interledger Protocol the implementation of >>> the lower layers is not important, that's the whole point of layering. By >>> forcing important aspects of ILP like the condition, fulfillment and expiry >>> down into those layers you muddy the waters and we now have to standardize >>> those protocols too. Instead we should just be defining the functions they >>> must provide and then leave it up to implementations to provide those >>> functions. >> >> >> I don't agree with this point; the condition and fulfillment have actual >> meaning to the ledger layer. >> > > NO THEY DON'T! They have meaning to SOME ledgers that implement SOME lower > layer protocols, IF they choose to use them. > > Excuse the shouting but this is the crux of the issue. We need to all > agree that it is entirely possible for a transfer to be done that doesn't > use the condition and fulfillment and that if this was in the middle of a > 10-hop ILP payment it would have no effect on the sender and receiver. > >> >> You've said that the ledger often doesn't care about fulfillment and >> condition, but the ledger _layer_'s (where transfers are done) role is to >> take in condition and fulfillment and make a transfer which satisfies its >> HTLA. >> > > No, the ledger's role is to keep a tab of net financial positions between > two peers. It MAY use conditions and fulfillments that it pulls from the > ILP layer to help it do that in a way both peers agree on. > > Note that a "layer" doesn't have a role. I think there is some confusion > about the difference between layering the protocol and abstracting > functionality into different components. > > >> If the ledger layer has to look into the ILP packet to do so, that is a >> blatant breaking of layering. >> > > Not at all! The module acting at the layers *below* the internetworking > layer shouldn't modify anything inside the packets of the higher layers but > they can definitely inspect them and adjust their behavior based on what > they to find. > > In fact the prevalence of this is the subject of a lot of debate at the > IETF currently because endpoints are often encrypting their payloads and in > some cases this makes it difficult for middle-boxes to be effective at > their jobs. > > By putting the condition, fulfillment, and expiry on the ledger layer, we >> leave it open for any ledger type to work, rather than forcing all >> ledger-layer software to understand ILP. >> > > Actually you do the opposite. You make it a requirement of every protocol > below the ILP layer to define a way to carry these data elements and encode > and decode them, even if they don't use them > > Ledger layer components don't have to understand ILP unless they choose to > re-use the condition for their own local transfer. Ledgers themselves > *never* have to understand ILP. > > Remember a ledger layer protocol could use a completely different > conditional payments scheme, like atomic mode ILP, where it takes the > end-to-end condition and creates a new compound condition that depends on > the fulfillment and some notary signature. > > There will be a component in a connector's stack that must pass the ILP > packet to the next peer. If it does this using a transfer protocol that > uses conditional transfers and wants to use the same condition as the ILP > packet then it must decode the packet. > > But, it will likely do something with that condition before sending the > transfer to the ledger like encoding it differently or rehashing it > (lightning?) so that it's in the form expected by the ledger. > > That's an implementation decision of the lower layer protocol used between > those two peers. > > >> >> I agree that Interledger defines how conditions, fulfillments, and >> expiries should be chained together, but it makes no assertions about their >> data format. >> > > ILP doesn't define how anything is chained together. From the perspective > of ILP the condition and fulfillment are end-to-end data. They are agreed > by the two endpoints who don't care how they get from Alice to Bob and back. > > The design of ILP is such that it facilitates the design of lower level > protocols that can be used to carry the ILP packets across multiple hops > (networks) using economic incentives such that the sender pays enough for > the first hop to ensure that all nodes in between can extract the fee they > want and the receiver will still get the amount they expected.. > > > >> ILP says you should send your outgoing transfer with the same condition >> as the incoming one, and a lower expiry. >> > > No it doesn't. An internetworking protocol can't prescribe that kind of > thing to lower level protocols. An incoming and outgoing transfer could be > sent using completely different protocols and the financial agreement with > the peers on those two routes could be vastly different too. > > The only service ILP requires of lower level protocols is that they can > map a response to an original request. This requirement is okay because it > is isolated to a single route/link at a time not a requirement that crosses > the inter-network boundary that ILP crosses. > > >> But because ILP allows for many different types of ledgers, it doesn't >> make sense to assert how these are encoded. >> > > By putting them in the ILP packet you do the opposite. You make no > assertions about how they are encoded if they are used at lower layers, or > how they may be combined with other conditions or even used to derive new > conditions. > >> >> IP doesn't tell you how to encode an ethernet packet. It doesn't even >> know whether it's going over a computer or a hand-written letter carried by >> a pigeon. IP takes for granted that you can send data over one connection >> by putting it in a lower level. >> > > Correct, but if a link layer protocol wanted to look into the IP packet > headers of a packet it wants to transfer and use some data from there in > its internal logic (or even reuse data in it's own frame) that would be > totally fine. > > >> Even though IP tells you how to chain these connections together, it >> doesn't have to put the things it's chaining on the internetworking level. >> > > IP doesn't tell you how to chain things together. IP simply defines the > end-to end data envelope and address space. Because of this nodes that > implement the multiple lower layer protocols are able to push IP packets > down a link and expect the node on the other side to understand the headers > and route it onward on another link. > > Everything needed by the IP module to decide what to do with the packet is > in the IP packet headers. i.e. Has it exceeded a TTL? Is there a route for > this destination? Is it corrupted (checksum fails)? But also, everything > that is needed by the endpoint (like the source address) is also in there. > > There is no dependency on nodes to be good citizens and always pass > certain other data from the lower layers into the next link. That would be > breaking the layering. > > >> IP also assumes that if you get some incoming data on a connection you >> can copy it and send it out on the next connection. Because you can already >> send data over a connection, all IP adds is the missing piece: a packet >> that tells you where to go. >> >> With ILP, we assume that there is a way to prepare a conditional >> transfer, expire a conditional transfer, and fulfill a conditional >> transfer. >> > > No we don't! We assume that if we deliver the packet as intended we'll get > back a response packet with a signature that matches the condition in the > packet. So, if we have an agreement with someone that they will pay us when > we present that signature then we are prepared to enter a similar agreement > with the next peer because we expect that signature to come all the way > back along the interledger layer route.. > > >> We also assume that if you get an incoming transfer you can create an >> outgoing transfer with the same condition. The abstraction we made means >> that conditions and fulfillments are already carried in the lower levels. >> > > That is a bad assumption that comes from the broken layering. What if my > outgoing link doesn't support conditional transfers? So now where do I put > the condition? > >> >> >> We could have assumed that no ledgers ever support conditional transfers, >> and said the only thing ILP gets from lower levels is the ability to send a >> transfer. But if we want to support the case where any of them do, we have >> to keep the conditions and fulfillments in the layer where they're actually >> used. >> > > I don't follow that logic at all. If we want to support the case where any > of them do then we must ensure the condition and expiry are always carried > in a consistent place at the internetworking layer so that if they do want > to use them they know where to find them. > > >> >> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >> adrian@hopebailie.com> wrote: >> >>> >>> >>> On 14 August 2017 at 22:03, Evan Schwartz wrote: >>> >>>> I think this thread is going to get extremely unwieldy but here goes: >>>> >>>> > - All interledger layer messages should be ILP packets (including >>>> fulfillments) and be capable of carrying higher layer protocol payloads. >>>> >>>> Interledger has higher requirements than ILP for the lowest layer, >>>> specifically because we are carrying money and not just data. One of the >>>> requirements is being able to transmit a 32-byte fulfillment back along the >>>> same path that carried the payment originally. If we expect this of the >>>> lower layer, I don't see a point in putting the fulfillment into an ILP >>>> packet and transmitting it as Interledger data along the same path. All >>>> ledger-layer protocols will need to interpret the fulfillment passed in >>>> their protocol, not the one passed through the Interledger layer. >>>> >>> >>> This is not correct. There is no requirement on ledger layer protocols >>> to transmit or understand the fulfillment. You are looking at this through >>> the lens of existing implementations from the bottom up instead of starting >>> at the interledger layer. >>> >>> The primary function of the condition and fulfillment is as a signed >>> end-to-end receipt. If the sender agrees a condition with a receiver and >>> then gets back the valid fulfillment they don't care what happened in the >>> middle. The receiver has signed a receipt saying they have their money. >>> >>> The value of using a standard for the receipt and signature is that each >>> transfer along the way CAN re-use it. One the one hand you can have a >>> transfer between two peers that have zero trust and the ledger they use >>> supports conditional payments completely. On the other extreme you can have >>> two peers that have a full trust and ignore the condition and fulfillment >>> completely. >>> >>> The ledger layer protocols carry ILP packets. Payment requests and >>> either fulfillment or error responses. If a ledger layer protocol wants to >>> use the condition and fulfillment for their own operations they can extract >>> these from the ILP packets and use them. >>> >>> >>>> > - While it may make sense to split the interledger payment and >>>> interledger quoting protocols into new higher level protocols that seems >>>> like an unnecessary abstraction. Instead the packet definitions should just >>>> have some consistency and probably a common base/header. >>>> >>>> The current protocols effectively have this header but it isn't >>>> separated out. There are two fields in the request header: type and >>>> destination address. There is one field in the response header: type. I >>>> don't think it makes that much of a big difference to separate these fields >>>> if all of the fields in that packet need to be interpreted together (for >>>> example, you can't understand a quote request if you strip off the >>>> destination address). >>>> >>> >>> I agree that we don't HAVE to explicitly separate them out but I think >>> ti would make it clearer how the stack is architected if there was a header >>> that was consistent across all packets. Currently the only thing that is >>> consitent across all ILP packets is that they are defined int he same file. >>> >>> >>>> >>>> > - We should define two base ILP packet types: request and response. >>>> >>>> Unless this adds some substantive benefit or new fields I don't think >>>> it's worth breaking all of the formats we have just to rearrange things. >>>> >>> >>> The goal of this exercise is to tease out the best design and ignore the >>> cost of change until we can compare the results with the current design. >>> >>> >>>> >>>> > - ILP is not about ledgers, it is about trustlines between >>>> nodes/hosts. >>>> >>>> A ledger is any system that tracks accounts and balances. When you use >>>> a trustline all of your messages still need to go through an accounting >>>> system (such as the plugin in the JS implementation) and then on to the >>>> other program logic. >>>> >>> >>> As above, this is incorrect. There is no requirement for "all messages >>> to go through an accounting system". >>> >>> Since designing the first implementation of 5-bells ledger we have >>> assumed that passing the ILP packet MUST be done by the ledger because that >>> is how we implemented it. But that is not true. It is perfectly valid for >>> the passing of an ILP packet from one peer to another to be simply an >>> exchange of data. >>> >>> The receiving peer makes a decision about whether or not to forward the >>> packet based on the current financial position they have with the sending >>> peer. >>> >>> It is convenient if the ledger that records the net positions of the >>> peers also forwards the messaging and even better if it natively supports >>> conditional payments and can use the condition and the fulfillment from the >>> ILP packet for those but that's all it is, convenient. >>> >>> >>> >>>> In that case, the plugin or whatever is doing the accounting is the >>>> ledger. Digital value is always tracked in ledgers, so I think it does make >>>> sense to think of this as the base layer. The reason to abstract the >>>> functionality you expect from the ledger layer is precisely so you can >>>> handle it in different ways, depending on what the underlying systems >>>> provide. >>>> >>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>> >>>> 1. The "Ledger Layer" provides both messaging capabilities and some >>>> type of HTLA >>>> >>>> 2. There are separate plugins for messaging and for transfers and >>>> when you peer with someone you have to agree on a plugin for each >>>> 3. We standardize the messaging part and say that all goes over IP >>>> and then just have more minimal plugins for the on-ledger settlements >>>> >>>> Number 1 is what we have and I think that still makes the most sense. >>>> >>> >>> I think you're confusing implementation details and defining of >>> interfaces with definition of a protocol stack. The only differences >>> between the tree examples you have above is in implementation. >>> >>> From the perspective of the Interledger Protocol the implementation of >>> the lower layers is not important, that's the whole point of layering. By >>> forcing important aspects of ILP like the condition, fulfillment and expiry >>> down into those layers you muddy the waters and we now have to standardize >>> those protocols too. Instead we should just be defining the functions they >>> must provide and then leave it up to implementations to provide those >>> functions. >>> >>> I know we want to define a standard to bootstrap the system (CLP) but >>> that's misleading us into thinking it's an essential part of the stack. >>> It's perfectly valid for two peers to not use CLP and still be part of the >>> Interledger. >>> >>> That said, you raise an interesting consideration about the layers below >>> ILP and actually I think it makes sense to split these. >>> >>> We keep trying to force messaging through the ledger layer and actually >>> that's the wrong place to put it if we can split the ledger layer into a >>> messaging layer and a ledger layer. That way we can stop trying to think of >>> all HLTAs as ledgers. >>> >>> A thought, why not use sub-layers as is common in other stacks: >>> >>> 1. Link layer: Layer upon which two peers that have a direct link, or >>> participate in the same payment network, communicate >>> 2. Transfer/ ledger: Layer on which financial positions between two >>> peers are recorded >>> >>> This reflects the already emerging HTLA model and many of our existing >>> plugins and ledger integrations. >>> Link Layer: XRP Paychan, Lightning >>> Ledger Layer: XRP Ledger, Bitcoin >>> >>> This doesn't prevent us from defining a standard binary protocol that >>> defines all of the operations for both layers (like CLP) but I see value in >>> distinguishing between these two. >>> >>> >>>> >>>> > - The protocol should differentiate between the operation of >>>> preparing a transfer on a ledger and the operation of passing an ILP packet >>>> from one peer to another. >>>> >>>> The protocol assumes your conditional transfer is underpinned by some >>>> HTLA >>>> . >>>> It doesn't care whether that's on-ledger or not. >>>> >>> >>> What do you mean when you say "the protocol"? In my statement I am >>> referring to ILP. >>> My point above being that ILP expects ILP packets to be passed from peer >>> to peer but has no expectations about transfers. >>> >>> It's perfectly legal (from an ILP perspective) for two peers to exchange >>> ILP packets with no transfers. Clearly if a node routes a packet on and has >>> no incoming transfer it's going to lose money but that's a consideration >>> for that node. It doesn't affect anyone else in the chain. >>> >>> ILP doesn't assume anything about transfers at all, let alone >>> conditional transfers. It provides useful semantics for conditional >>> transfers to be used by two peers to transact as part of a larger ILP >>> payment. >>> >>> >>>> >>>> > - The condition and timeout should be included in the ILP payment >>>> packet. >>>> >>>> I strongly disagree with this. We had this debate a year ago and I was >>>> on your side but was convinced that this is not a good idea. >>>> >>> >>> Yes, I recall this and I'm sorry I didn't push harder on this point. >>> Unfortunately I think the decision to pull it out of the packet is mostly >>> driven by how our prototypes were implemented rather than good architecture. >>> >>>> >>>> The layer below ILP must be capable of doing conditional transfers >>>> based on sha256 hashlocks with 32-byte preimages. >>>> >>> >>> This is not true and I think it would be useful for us to agree on this >>> as this seems to be the argument I am coming up against most often. The >>> peers participating in a transfer that is part of an ILP payment may wish >>> to use conditional transfers as a way to enforce their agreement but this >>> is not a requirement of the protocol. >>> >>> The agreement between any two peers is: "I will pay you X if you can >>> provide a receipt that Y was paid Z before T". >>> ILP provides a standard for expressing this agreement so that these can >>> be chained together BUT it is not a requirement that every agreement in the >>> chain uses the condition, and fulfillment provided at the ILP layer. >>> >>> >>>> >>>> As a result, the original condition and the corresponding preimage MUST >>>> be expressed in that layer. >>>> >>> >>> As I have shown above, this is not true. >>> >>> >>>> Then the question is whether we should also include it in the packet >>>> that is forwarded. What ultimately convinced me is the following: All >>>> connectors MUST ignore the condition if it is in the packet, because they >>>> are only guaranteed their money back if they use the same condition from >>>> the incoming transfer they got. >>>> >>> >>> Here is where the layering is being corrupted. >>> >>> All connectors MUST inspect the condition in the ILP packet as part of >>> their decision to route the packet or not. >>> When the local transfer module of the connectors stack passes the ILP >>> packet up to the ILP module it should indicate the properties of the >>> incoming transfer that carried the packet. >>> This is essential firstly so that the routing logic in the ILP module >>> can record the incoming transfer identifier so it is able to use the >>> correct response id when it passes back the fulfillment or error. >>> The other properties that the ILP module should look at are the >>> condition and expiry on the incoming transfer. >>> >>> If the incoming route uses conditional transfers and these are supposed >>> to match the condition and expiry in the ILP packet then the ILP module >>> should compare them and reject the packet if: >>> a) the conditions don't match OR >>> b) the expiry is too short >>> >>> We should still discuss if the expiry should be set by the sender and >>> left unchanged or used like a TTL and decremented by each node. >>> >>> >>>> Also, the receiver will need to take out the condition in order to hash >>>> the packet for PSK or IPR. >>>> >>> >>> This is completely normal. Zeroing a checksum field in a header before >>> calculating the checksum is VERY common precisely because it's long been >>> accepted that the right place to put that data is in the headers and the >>> work of zero'ing it out to calculate the checksum (or signature in our >>> case) is not material. >>> >>> >>>> So basically, no one wants the condition in there. It feels like it >>>> ought to be in there, but literally none of the parties want the extra 32 >>>> bytes in there. >>>> >>> >>> "Nobody wants it there" is a terrible reason to abandon the correct >>> design. The whole purpose of a good architecture is you accept that there >>> may be cases in future that haven't been considered now so designing just >>> for the known cases is a bad idea. >>> >>> Good architecture is not the same as optimization. Taking stuff out >>> (even when it feels wrong) to save a few bytes is a good sign that it's a >>> bad idea. >>> >>> >>>> >>>> The reason the timeout should not be in there is that there isn't a >>>> single timeout for the payment. There are multiple separate timeouts for >>>> each of the bilateral transfers. Those must go in the individual transfers >>>> and there is no sensible value to put in the Interledger packet. >>>> >>> >>> As above, this is somewhat equivalent to the TTL in an IP packet. I'm >>> open to discussing if it should be a fixed value set by the sender where >>> each node uses their own value but has the sender-defined value as a >>> reference or it is actually decremented at each hop. >>> >>> Either way, this is part of ILP not the ledger layer just like the >>> condition and fulfillment. It may be used by the ledger layer but that's >>> implementation specific. It belongs in the ILP packet. >>> >>>> >>>> >>>> >>> >> > --001a11464f008a97440556cd9bf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Ok, I think I have a better idea of what you're saying= .

    It sounds like you're saying the ILP layer contain= s all information that is common between every hop (destination, destinatio= n amount, opaque data, condition, fulfillment, expiry). The lower level wou= ld then be used for all the transfer-local details (source amount, next con= nector account, custom/local data).

    If the lower l= evel wanted to do anything related to the every-hop payment, i.e. escrow fu= nds until the receipt has been produced, it would look into the ILP layer f= or that information. If the lower level didn't do any escrow or expirie= s that require every-hop details, it would simply function as a communicati= on method.

    Is that right?

    On Tue, Aug 15, 2017 at 6:35 P= M, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
    =


    On 15 August 2017 at 16= :00, Ben Sharafian <sharafian@ripple.com> wrote:
    In that case, the plugin or whatever is doing the accounting is the ledger= . Digital value is always tracked in ledgers, so I think it does make sense= to think of this as the base layer. The reason to abstract the functionali= ty you expect from the ledger layer is precisely so you can handle it in di= fferent ways, depending on what the underlying systems provide.I see 3 ways to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both= messaging capabilities and some type of=C2=A0HTLA
    1. There are separate plugins for messaging and for = transfers and when you peer with someone you have to agree on a plugin for = each
    1. We standardize the messagi= ng part and say that all goes over IP and then just have more minimal plugi= ns for the on-ledger settlements
    Number 1 is what we have and I th= ink that still makes the most sense.

    I think you're confusing implementation details and definin= g of interfaces with definition of a protocol stack. The only differences b= etween the tree examples you have above is in implementation.

    I had to scroll up after reading this to m= ake sure it was @adrian talking, because that seems like the opposite of wh= at you were arguing for.

    I don't think so. But I think that is part of the problem. We are not= all focused on the same thing. I am actually not very interested in CLP at= all. It is one of potentially many protocols that may exist below the ILP = layer. All we're doing by defining CLP is bootstrapping the network by = defining a protocol for everyone to use to get started.

    I= n designing the ILP layer properly we should try and forget everything we k= now about the lower layers other than what features we require of them.
    =
    There is a misconception that ILP requires the lower layers = to support conditional transfers, that is not true.

    All w= e actually need from a lower layer protocol is to transfer data back and fo= rth and provide a way to reliably map requests to responses.

    <= div>What ILP provides lower layers is a way to reward your peer for passing= on the packet. The Internetworking layer defines a condition, a reward tha= t must be paid to the receiver for the fulfillment and the time allowed to = claim this reward.

    Because of this, within low= er-layer protocols that offer the basic request/response features we need, = we could add conditional payment semantics that use the condition, expiry a= nd fulfillment provided by ILP. This would allow a node to offer a reward t= o=C2=A0 their next peer to for delivering the packet they send them and to = make the local financial transaction contingent on the end-to-end transacti= on.

    But crucially, adding that semantic to the lower laye= r protocol provides nothing extra to the ILP layer. The value is purely der= ived from the two peers who use that protocol and can now use conditional p= ayments to protect themselves from their peers.
    <= div>=C2=A0
    The proposal that you're arguing for is basically asserti= ng that we're going to be using CLP, because it makes the assumption th= at the connectors (who understand ILP) are managing the HTLA logic.

    Not at all. I am asserting that= it doesn't matter what protocol you use below the ILP layer because it= shouldn't matter. All of this talk about ILP being different because m= oney is more important than data is nonsense.

    The difference b= etween ILP and IP that makes ILP suitable for value transfer and IP not is = at the internetworking layer. ILP requires that all packets are either a re= quest or response and that the responses follow the same path as the reques= ts. Further ILP defines a signature scheme that gives the sender a way to b= e certain the request was received by the receiver.

    This could be done entirely without money but then = there would be little incentive to sign the receipt or deliver the signatur= e back to the original sender.

    So, = if you add money then you add economic incentives to the mix. At each hop t= he sender promises the next upstream peer a payment if they can return the = receipt. The net effect is that this can be used to transfer money from the= sender to the receiver by simply defining up front the amount that the rec= eiver must get to produce the signature.
    =C2=A0

    I= n the current model, the CLP/trustline model and the direct ledger model bo= th work without having to treat anything on the ILP layer differently. We&#= 39;re favoring on-ledger messaging because of our implementation, yes, but = we've been able to switch most all of our plugins from on-ledger messag= ing to RPC-based messaging without changing the ILP layer at all.

    With the ledger-level abstraction, we were able to switch f= rom our ledger-based mode of thinking to the CLP/trustline based way withou= t changing anything other than the plugin. Your argument comes from an assu= mption of a CLP-style ledger protocol with some underlying ledger, which we= can't assume is always the case.

    I'm not sure what any of that proves tbh. These are all implem= entation concerns. They don't change the fact that the condition, expir= y and fulfillment are part of ILP not the lower layer protocols.
    =
    =C2=A0

    From the perspective of the Interledger P= rotocol the implementation of the lower layers is not important, that's= the whole point of layering. By forcing important aspects of ILP like the = condition, fulfillment and expiry down into those layers you muddy the wate= rs and we now have to standardize those protocols too. Instead we should ju= st be defining the functions they must provide and then leave it up to impl= ementations to provide those functions.

    <= /span>
    I don't agree with this point; the condition and fulfillment= have actual meaning to the ledger layer.
    NO THEY DON'T! They have meaning to SOME ledgers tha= t implement SOME lower layer protocols, IF they choose to use them.

    =
    Excuse the shouting but this is the crux of the issue. We need t= o all agree that it is entirely possible for a transfer to be done that doe= sn't use the condition and fulfillment and that if this was in the midd= le of a 10-hop ILP payment it would have no effect on the sender and receiv= er.
    =C2=A0
    You've said that the ledger often does= n't care about fulfillment and condition, but the ledger _layer_'s = (where transfers are done) role is to take in condition and fulfillment and= make a transfer which satisfies its HTLA.
    No, the ledger's role is to keep a tab of net financial = positions between two peers. It MAY use conditions and fulfillments that it= pulls from the ILP layer to help it do that in a way both peers agree on.<= br>
    Note that a "layer" doesn= 't have a role. I think there is some confusion about the difference be= tween layering the protocol and abstracting functionality into different co= mponents.
    =C2=A0
    If the ledger layer has to look into the ILP pa= cket to do so, that is a blatant breaking of layering.

    Not at all! The module acting at the layers= below the internetworking layer shouldn't modify anything insid= e the packets of the higher layers but they can definitely inspect them and= adjust their behavior based on what they to find.

    In fact the= prevalence of this is the subject of a lot of debate at the IETF currently= because endpoints are often encrypting their payloads and in some cases th= is makes it difficult for middle-boxes to be effective at their jobs.

    By putting the condition, = fulfillment, and expiry on the ledger layer, we leave it open for any ledge= r type to work, rather than forcing all ledger-layer software to understand= ILP.

    Actually you do th= e opposite. You make it a requirement of every protocol below the ILP layer= to define a way to carry these data elements and encode and decode them, e= ven if they don't use them

    Ledger layer components do= n't have to understand ILP unless they choose to re-use the condition f= or their own local transfer. Ledgers themselves never have to unders= tand ILP.

    Remember a ledger layer protocol could use a completely d= ifferent conditional payments scheme, like atomic mode ILP, where it takes = the end-to-end condition and creates a new compound condition that depends = on the fulfillment and some notary signature.

    There will = be a component in a connector's stack that must pass the ILP packet to = the next peer. If it does this using a transfer protocol that uses conditio= nal transfers and wants to use the same condition as the ILP packet then it= must decode the packet.

    But, it will likely do something= with that condition before sending the transfer to the ledger like encodin= g it differently or rehashing it (lightning?) so that it's in the form = expected by the ledger.

    That's an implemen= tation decision of the lower layer protocol used between those two peers.
    =C2=A0

    I agree that Interled= ger defines how conditions, fulfillments, and expiries should be chained to= gether, but it makes no assertions about their data format.

    ILP doesn't define how anything is= chained together. From the perspective of ILP the condition and fulfillmen= t are end-to-end data. They are agreed by the two endpoints who don't c= are how they get from Alice to Bob and back.

    The design o= f ILP is such that it facilitates the design of lower level protocols that = can be used to carry the ILP packets across multiple hops (networks) using = economic incentives such that the sender pays enough for the first hop to e= nsure that all nodes in between can extract the fee they want and the recei= ver will still get the amount they expected..

    =C2=A0
    ILP says you should send your outgoing transfer with the sam= e condition as the incoming one, and a lower expiry.

    No it doesn't. An internetworking protoco= l can't prescribe that kind of thing to lower level protocols. An incom= ing and outgoing transfer could be sent using completely different protocol= s and the financial agreement with the peers on those two routes could be v= astly different too.

    The only service ILP requires of lower level pr= otocols is that they can map a response to an original request. This requir= ement is okay because it is isolated to a single route/link at a time not a= requirement that crosses the inter-network boundary that ILP crosses.
    <= /div>
    =C2=A0
    But because ILP allows for many differe= nt types of ledgers, it doesn't make sense to assert how these are enco= ded.

    By putting them in = the ILP packet you do the opposite. You make no assertions about how they a= re encoded if they are used at lower layers, or how they may be combined wi= th other conditions or even used to derive new conditions.

    IP doesn't tell you how to encode an ethernet pac= ket. It doesn't even know whether it's going over a computer or a h= and-written letter carried by a pigeon. IP takes for granted that you can s= end data over one connection by putting it in a lower level.

    Correct, but if a link layer protocol= wanted to look into the IP packet headers of a packet it wants to transfer= and use some data from there in its internal logic (or even reuse data in = it's own frame) that would be totally fine.
    <= div>=C2=A0
    Even though IP tells you how to chain these connections toget= her, it doesn't have to put the things it's chaining on the interne= tworking level.

    IP does= n't tell you how to chain things together. IP simply defines the end-to= end data envelope and address space. Because of this nodes that implement = the multiple lower layer protocols are able to push IP packets down a link = and expect the node on the other side to understand the headers and route i= t onward on another link.

    Everything needed by the IP mod= ule to decide what to do with the packet is in the IP packet headers. i.e. = Has it exceeded a TTL? Is there a route for this destination? Is it corrupt= ed (checksum fails)? But also, everything that is needed by the endpoint (l= ike the source address) is also in there.

    There is no dep= endency on nodes to be good citizens and always pass certain other data fro= m the lower layers into the next link. That would be breaking the layering.=
    =C2=A0
    IP also assumes that if you get so= me incoming data on a connection you can copy it and send it out on the nex= t connection. Because you can already send data over a connection, all IP a= dds is the missing piece: a packet that tells you where to go.
    With ILP, we assume that there is a way to prepare a condition= al transfer, expire a conditional transfer, and fulfill a conditional trans= fer.

    No we don't! W= e assume that if we deliver the packet as intended we'll get back a res= ponse packet with a signature that matches the condition in the packet. So,= if we have an agreement with someone that they will pay us when we present= that signature then we are prepared to enter a similar agreement with the = next peer because we expect that signature to come all the way back along t= he interledger layer route..
    =C2=A0
    We als= o assume that if you get an incoming transfer you can create an outgoing tr= ansfer with the same condition. The abstraction we made means that conditio= ns and fulfillments are already carried in the lower levels.

    That is a bad assumption that comes fr= om the broken layering. What if my outgoing link doesn't support condit= ional transfers? So now where do I put the condition?
    =C2=A0

    We could have assumed that no ledgers ever support = conditional transfers, and said the only thing ILP gets from lower levels i= s the ability to send a transfer. But if we want to support the case where = any of them do, we have to keep the conditions and fulfillments in the laye= r where they're actually used.

    <= /span>
    I don't follow that logic at all. If we want to support the = case where any of them do then we must ensure the condition and expiry are = always carried in a consistent place at the internetworking layer so that i= f they do want to use them they know where to find them.
    =C2=A0

    On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie <adrian@h= opebailie.com> wrote:


    On 14 August 2017 at 22:03, Evan Schwartz <evan@ripp= le.com> wrote:
    I think this thread is going to get extremely unwie= ldy but here goes:

    >=C2=A0- All interledger layer messages should be ILP packets (incl= uding fulfillments) and be capable of carrying higher layer protocol payloa= ds.

    Interledger has higher requireme= nts than ILP for the lowest layer, specifically because we are carrying mon= ey and not just data. One of the requirements is being able to transmit a 3= 2-byte fulfillment back along the same path that carried the payment origin= ally. If we expect this of the lower layer, I don't see a point in putt= ing the fulfillment into an ILP packet and transmitting it as Interledger d= ata along the same path. All ledger-layer protocols will need to interpret = the fulfillment passed in their protocol, not the one passed through the In= terledger layer.

    This is not = correct. There is no requirement on ledger layer protocols to transmit or u= nderstand the fulfillment. You are looking at this through the lens of exis= ting implementations from the bottom up instead of starting at the interled= ger layer.

    The primary function of= the condition and fulfillment is as a signed end-to-end receipt. If the se= nder agrees a condition with a receiver and then gets back the valid fulfil= lment they don't care what happened in the middle. The receiver has sig= ned a receipt saying they have their money.

    The value of using a standard for the receipt and signature is tha= t each transfer along the way CAN re-use it. One the one hand you can have = a transfer between two peers that have zero trust and the ledger they use s= upports conditional payments completely. On the other extreme you can have = two peers that have a full trust and ignore the condition and fulfillment c= ompletely.
    =C2=A0
    The ledger l= ayer protocols carry ILP packets. Payment requests and either fulfillment o= r error responses. If a ledger layer protocol wants to use the condition an= d fulfillment for their own operations they can extract these from the ILP = packets and use them.


    >=C2=A0- While it may make sense to split the interledger payment and int= erledger quoting protocols into new higher level protocols that seems like = an unnecessary abstraction. Instead the packet definitions should just have= some consistency and probably a common base/header.

    The current protocols effectively have this header but= it isn't separated out. There are two fields in the request header: ty= pe and destination address. There is one field in the response header: type= . I don't think it makes that much of a big difference to separate thes= e fields if all of the fields in that packet need to be interpreted togethe= r (for example, you can't understand a quote request if you strip off t= he destination address).

    I agree that we don't HAVE to explicitly separate them out but = I think ti would make it clearer how the stack is architected if there was = a header that was consistent across all packets. Currently the only thing t= hat is consitent across all ILP packets is that they are defined int he sam= e file.
    =C2=A0

    >=C2=A0- We should define two base ILP pac= ket types: request and response.

    Unless this adds some sub= stantive benefit or new fields I don't think it's worth breaking al= l of the formats we have just to rearrange things.
    =

    The goal of this exercise is to tease out the be= st design and ignore the cost of change until we can compare the results wi= th the current design.
    =C2=A0

    &g= t;=C2=A0- ILP is not about ledgers, it = is about trustlines between nodes/hosts.

    A ledger is any system that tracks accounts and bal= ances. When you use a trustline all of your messages still need to go throu= gh an accounting system (such as the plugin in the JS implementation) and t= hen on to the other program logic.

    =
    As above, this is incorrect. There is no requirement for "= all messages to go through an accounting system".

    Si= nce designing the first implementation of 5-bells ledger we have assumed th= at passing the ILP packet MUST be done by the ledger because that is how we= implemented it. But that is not true. It is perfectly valid for the passin= g of an ILP packet from one peer to another to be simply an exchange of dat= a.

    The receiving peer makes a decision about whether or n= ot to forward the packet based on the current financial position they have = with the sending peer.

    It is convenient if the= ledger that records the net positions of the peers also forwards the messa= ging and even better if it natively supports conditional payments and can u= se the condition and the fulfillment from the ILP packet for those but that= 's all it is, convenient.

    =C2=A0
    In that case= , the plugin or whatever is doing the accounting is the ledger. Digital val= ue is always tracked in ledgers, so I think it does make sense to think of = this as the base layer. The reason to abstract the functionality you expect= from the ledger layer is precisely so you can handle it in different ways,= depending on what the underlying systems provide.

    I see 3 ways to think of the layer(s) underpinning ILP:
    1. = The "Ledger Layer" provides both messaging capab= ilities and some type of HTLA
    2. There are separate plugins for = messaging and for transfers and when you peer with someone you have to agre= e on a plugin for each
    3. We standardize the messaging part and say th= at all goes over IP and then just have more minimal plugins for the on-ledg= er settlements
    Number 1 is what we have and I think that stil= l makes the most sense.

    I think yo= u're confusing implementation details and defining of interfaces with d= efinition of a protocol stack. The only differences between the tree exampl= es you have above is in implementation.

    From the perspective of the = Interledger Protocol the implementation of the lower layers is not importan= t, that's the whole point of layering. By forcing important aspects of = ILP like the condition, fulfillment and expiry down into those layers you m= uddy the waters and we now have to standardize those protocols too. Instead= we should just be defining the functions they must provide and then leave = it up to implementations to provide those functions.

    I know we want to define a standard to bootstrap the syst= em (CLP) but that's misleading us into thinking it's an essential p= art of the stack. It's perfectly valid for two peers to not use CLP and= still be part of the Interledger.

    =
    That said, you raise an interesting c= onsideration about the layers below ILP and actually I think it makes sense= to split these.

    We keep trying to force messaging throug= h the ledger layer and actually that's the wrong place to put it if we = can split the ledger layer into a messaging layer and a ledger layer. That = way we can stop trying to think of all HLTAs as ledgers.

    = A thought, why not use sub-layers as is common in other stacks:

    1. Link layer: Layer upon which two peers that have a direct link, o= r participate in the same payment network, communicate
    2. Tra= nsfer/ ledger: Layer on which financial positions between two peers are rec= orded

    This reflects the already emerging HTLA model and many of our = existing plugins and ledger integrations.
    Link Layer: XRP Pay= chan, Lightning
    Ledger Layer: XRP Ledger, Bitcoin

    This doesn't prevent us from defining a standard bina= ry protocol that defines all of the operations for both layers (like CLP) b= ut I see value in distinguishing between these two.
    =C2= =A0

    >=C2=A0- = The protocol should differentiate between the operation of preparing a tran= sfer on a ledger and the operation of passing an ILP packet from one peer t= o another.

    The pr= otocol assumes your conditional transfer is underpinned by some HTLA. It doe= sn't care whether that's on-ledger or not.
    =

    What do you mean when you say "the protocol"= ;? In my statement I am referring to ILP.
    My point above being that ILP= expects ILP packets to be passed from peer to peer but has no expectations= about transfers.

    It's perfectl= y legal (from an ILP perspective) for two peers to exchange ILP packets wit= h no transfers. Clearly if a node routes a packet on and has no incoming tr= ansfer it's going to lose money but that's a consideration for that= node. It doesn't affect anyone else in the chain.

    ILP doesn't assume anything about transfers at all= , let alone conditional transfers. It provides useful semantics for conditi= onal transfers to be used by two peers to transact as part of a larger ILP = payment.
    =C2=A0

    <= div>>=C2=A0- The condition and timeo= ut should be included in the ILP payment packet.

    I strongly disagree with this. We had this debate a year ago a= nd I was on your side but was convinced that this is not a good idea.
    =

    Yes, I recall this and I'= m sorry I didn't push harder on this point. Unfortunately I think the d= ecision to pull it out of the packet is mostly driven by how our prototypes= were implemented rather than good architecture.

    The layer below ILP must be capable of doing conditional transfers based o= n sha256 hashlocks with 32-byte preimages.
    This is not true and I think it would be useful for us = to agree on this as this seems to be the argument I am coming up against mo= st often. The peers participating in a transfer that is part of an ILP paym= ent may wish to use conditional transfers as a way to enforce their agreeme= nt but this is not a requirement of the protocol.

    The agr= eement between any two peers is: "I will pay you X if you can provide = a receipt that Y was paid Z before T".
    ILP provides a st= andard for expressing this agreement so that these can be chained together = BUT it is not a requirement that every agreement in the chain uses the cond= ition, and fulfillment provided at the ILP layer.

    =C2=A0=
    As = a result, the original condition and the corresponding preimage MUST be exp= ressed in that layer.

    A= s I have shown above, this is not true.
    =C2=A0
    Then t= he question is whether we should also include it in the packet that is forw= arded. What ultimately convinced me is the following: All connectors MUST i= gnore the condition if it is in the packet, because they are only guarantee= d their money back if they use the same condition from the incoming transfe= r they got.

    Here is where the layering is being corrupted.

    All connec= tors MUST inspect the condition in the ILP packet as part of their decision= to route the packet or not.
    When the l= ocal transfer module of the connectors stack passes the ILP packet up to th= e ILP module it should indicate the properties of the incoming transfer tha= t carried the packet.
    This is essential= firstly so that the routing logic in the ILP module can record the incomin= g transfer identifier so it is able to use the correct response id when it = passes back the fulfillment or error.
    The other properties that the ILP = module should look at are the condition and expiry on the incoming transfer= .

    If the incoming r= oute uses conditional transfers and these are supposed to match the conditi= on and expiry in the ILP packet then the ILP module should compare them and= reject the packet if:
    a) the conditions don't match OR
    b) the expiry is too short

    We should still d= iscuss if the expiry should be set by the sender and left unchanged or used= like a TTL and decremented by each node.
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
    Also= , the receiver will need to take out the condition in order to hash the pac= ket for PSK or IPR.

    Thi= s is completely normal. Zeroing a checksum field in a header before calcula= ting the checksum is VERY common precisely because it's long been accep= ted that the right place to put that data is in the headers and the work of= zero'ing it out to calculate the checksum (or signature in our case) i= s not material.
    =C2=A0
    So basically, no one wants the= condition in there. It feels like it ought to be in there, but literally n= one of the parties want the extra 32 bytes in there.

    "Nobody wants it there" is a terribl= e reason to abandon the correct design. The whole purpose of a good archite= cture is you accept that there may be cases in future that haven't been= considered now so designing just for the known cases is a bad idea.
    Good architecture is not the same as optimization. Taking stuff= out (even when it feels wrong) to save a few bytes is a good sign that it&= #39;s a bad idea.
    =C2=A0

    The reason th= e timeout should not be in there is that there isn't a single timeout f= or the payment. There are multiple separate timeouts for each of the bilate= ral transfers. Those must go in the individual transfers and there is no se= nsible value to put in the Interledger packet.
    =C2=A0
    As above, this is somewhat equivalent to the TTL i= n an IP packet. I'm open to discussing if it should be a fixed value se= t by the sender where each node uses their own value but has the sender-def= ined value as a reference or it is actually decremented at each hop.
    Either way, this is part of ILP not the ledger layer just like = the condition and fulfillment. It may be used by the ledger layer but that&= #39;s implementation specific. It belongs in the ILP packet.
    =C2= =A0

    =




    --001a11464f008a97440556cd9bf3-- From nobody Tue Aug 15 10:24:45 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BB213219E for ; Tue, 15 Aug 2017 10:24:43 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 R0sGfohtS-Zp for ; Tue, 15 Aug 2017 10:24:38 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 7B1FB132143 for ; Tue, 15 Aug 2017 10:24:38 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id y36so5362227uac.5 for ; Tue, 15 Aug 2017 10:24:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j8mffAXhB6Jmw1ILL1ggy8ZlVeAjP38hA5DvvYXG7oQ=; b=RtoDtqLbdOQdEaIUAzYn99Ad3BhMlbxT0F1521TFgZ5m0qsplN9OJ7Mc16ET4FhPFJ 8449J0vLtNdcZhDjNqqrMqeLeeJZxw/50P+9OaeoTB5M4H0gJ92pRrwsw0Hdqm2qP/iV x3QS84MbMZVJdUbb8r0IUp4fXw7ojMXKSlSoI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j8mffAXhB6Jmw1ILL1ggy8ZlVeAjP38hA5DvvYXG7oQ=; b=UQI+DWYlqubjdDK8ngmPIn1imkvNC16/JvXLrR47Jj0uxlE+bHc3KHZIUgjh8c66e2 l97q19Rs1IOa3Ope0gr0R2ljoNL3gbC2DBCDG7JJJp42KMQ2wmzMN6Gff36o9kk5wKmJ GCR1es0X0LaC2l+CmjXLWQ5atrmPSFy2wwag/gza+VtJUNSFt4gg4yFEWHikkDaYY5S7 c6vR/DofDPFC9mm3vKWFjhm6FXUzwMoxmAc1Ag3qD/Ukoch1C5YDyFRvGcMCKe9d+3KG wsdcIlYl2SOjSEnO5rH0xZkOeoYYDrOm90Koeb3R3N5Reb4+3ESFYry7HjXP6I1q+wub aRHA== X-Gm-Message-State: AHYfb5gJOzfj5gXnA0YGZlcLkBjXatI7j8AJQtgKIj+mHgdFH3W1KupM J8bYZiXF7e/qFBeZ7j/lGGQsYgDPkCXJ X-Received: by 10.176.23.77 with SMTP id k13mr21995918uaf.128.1502817877353; Tue, 15 Aug 2017 10:24:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adrian Hope-Bailie Date: Tue, 15 Aug 2017 17:24:23 +0000 Message-ID: To: Ben Sharafian Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="f4030436207ebe5d2d0556ce0dce" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 17:24:44 -0000 --f4030436207ebe5d2d0556ce0dce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Exactly =F0=9F=91=8D On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian wrote: > Ok, I think I have a better idea of what you're saying. > > It sounds like you're saying the ILP layer contains all information that > is common between every hop (destination, destination amount, opaque data= , > condition, fulfillment, expiry). The lower level would then be used for a= ll > the transfer-local details (source amount, next connector account, > custom/local data). > > If the lower level wanted to do anything related to the every-hop payment= , > i.e. escrow funds until the receipt has been produced, it would look into > the ILP layer for that information. If the lower level didn't do any escr= ow > or expiries that require every-hop details, it would simply function as a > communication method. > > Is that right? > > On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie > wrote: > >> >> >> On 15 August 2017 at 16:00, Ben Sharafian wrote: >> >>> In that case, the plugin or whatever is doing the accounting is the >>>>>> ledger. Digital value is always tracked in ledgers, so I think it do= es make >>>>>> sense to think of this as the base layer. The reason to abstract the >>>>>> functionality you expect from the ledger layer is precisely so you c= an >>>>>> handle it in different ways, depending on what the underlying system= s >>>>>> provide. >>>>> >>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>> >>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>> some type of HTLA >>>>> >>>>> >>>>> >>>>> 1. There are separate plugins for messaging and for transfers and >>>>> when you peer with someone you have to agree on a plugin for each >>>>> >>>>> >>>>> 1. We standardize the messaging part and say that all goes over IP >>>>> and then just have more minimal plugins for the on-ledger settleme= nts >>>>> >>>>> Number 1 is what we have and I think that still makes the most sense. >>>> >>>> >>> I think you're confusing implementation details and defining of >>>> interfaces with definition of a protocol stack. The only differences >>>> between the tree examples you have above is in implementation. >>> >>> >>> I had to scroll up after reading this to make sure it was @adrian >>> talking, because that seems like the opposite of what you were arguing = for. >>> >> >> I don't think so. But I think that is part of the problem. We are not al= l >> focused on the same thing. I am actually not very interested in CLP at a= ll. >> It is one of potentially many protocols that may exist below the ILP lay= er. >> All we're doing by defining CLP is bootstrapping the network by defining= a >> protocol for everyone to use to get started. >> >> In designing the ILP layer properly we should try and forget everything >> we know about the lower layers other than what features we require of th= em. >> >> There is a misconception that ILP requires the lower layers to support >> conditional transfers, that is not true. >> >> All we actually need from a lower layer protocol is to transfer data bac= k >> and forth and provide a way to reliably map requests to responses. >> >> What ILP provides lower layers is a way to reward your peer for passing >> on the packet. The Internetworking layer defines a condition, a reward t= hat >> must be paid to the receiver for the fulfillment and the time allowed to >> claim this reward. >> >> Because of this, within lower-layer protocols that offer the basic >> request/response features we need, we could add conditional payment >> semantics that use the condition, expiry and fulfillment provided by ILP= . >> This would allow a node to offer a reward to their next peer to for >> delivering the packet they send them and to make the local financial >> transaction contingent on the end-to-end transaction. >> >> But crucially, adding that semantic to the lower layer protocol provides >> nothing extra to the ILP layer. The value is purely derived from the two >> peers who use that protocol and can now use conditional payments to prot= ect >> themselves from their peers. >> >> >>> The proposal that you're arguing for is basically asserting that we're >>> going to be using CLP, because it makes the assumption that the connect= ors >>> (who understand ILP) are managing the HTLA logic. >>> >> >> Not at all. I am asserting that it doesn't matter what protocol you use >> below the ILP layer because it shouldn't matter. All of this talk about = ILP >> being different because money is more important than data is nonsense. >> >> The difference between ILP and IP that makes ILP suitable for value >> transfer and IP not is at the internetworking layer. ILP requires that a= ll >> packets are either a request or response and that the responses follow t= he >> same path as the requests. Further ILP defines a signature scheme that >> gives the sender a way to be certain the request was received by the >> receiver. >> >> *This could be done entirely without money* but then there would be >> little incentive to sign the receipt or deliver the signature back to th= e >> original sender. >> >> So, if you add money then you add economic incentives to the mix. At eac= h >> hop the sender promises the next upstream peer a payment if they can ret= urn >> the receipt. The net effect is that this can be used to transfer money f= rom >> the sender to the receiver by simply defining up front the amount that t= he >> receiver must get to produce the signature. >> >> >>> >>> In the current model, the CLP/trustline model and the direct ledger >>> model both work without having to treat anything on the ILP layer >>> differently. We're favoring on-ledger messaging because of our >>> implementation, yes, but we've been able to switch most all of our plug= ins >>> from on-ledger messaging to RPC-based messaging without changing the IL= P >>> layer at all. >>> >>> With the ledger-level abstraction, we were able to switch from our >>> ledger-based mode of thinking to the CLP/trustline based way without >>> changing anything other than the plugin. Your argument comes from an >>> assumption of a CLP-style ledger protocol with some underlying ledger, >>> which we can't assume is always the case. >>> >> >> I'm not sure what any of that proves tbh. These are all implementation >> concerns. They don't change the fact that the condition, expiry and >> fulfillment are part of ILP not the lower layer protocols. >> >>> >>> >>> From the perspective of the Interledger Protocol the implementation of >>>> the lower layers is not important, that's the whole point of layering.= By >>>> forcing important aspects of ILP like the condition, fulfillment and e= xpiry >>>> down into those layers you muddy the waters and we now have to standar= dize >>>> those protocols too. Instead we should just be defining the functions = they >>>> must provide and then leave it up to implementations to provide those >>>> functions. >>> >>> >>> I don't agree with this point; the condition and fulfillment have actua= l >>> meaning to the ledger layer. >>> >> >> NO THEY DON'T! They have meaning to SOME ledgers that implement SOME >> lower layer protocols, IF they choose to use them. >> >> Excuse the shouting but this is the crux of the issue. We need to all >> agree that it is entirely possible for a transfer to be done that doesn'= t >> use the condition and fulfillment and that if this was in the middle of = a >> 10-hop ILP payment it would have no effect on the sender and receiver. >> >>> >>> You've said that the ledger often doesn't care about fulfillment and >>> condition, but the ledger _layer_'s (where transfers are done) role is = to >>> take in condition and fulfillment and make a transfer which satisfies i= ts >>> HTLA. >>> >> >> No, the ledger's role is to keep a tab of net financial positions betwee= n >> two peers. It MAY use conditions and fulfillments that it pulls from the >> ILP layer to help it do that in a way both peers agree on. >> >> Note that a "layer" doesn't have a role. I think there is some confusion >> about the difference between layering the protocol and abstracting >> functionality into different components. >> >> >>> If the ledger layer has to look into the ILP packet to do so, that is a >>> blatant breaking of layering. >>> >> >> Not at all! The module acting at the layers *below* the internetworking >> layer shouldn't modify anything inside the packets of the higher layers = but >> they can definitely inspect them and adjust their behavior based on what >> they to find. >> >> In fact the prevalence of this is the subject of a lot of debate at the >> IETF currently because endpoints are often encrypting their payloads and= in >> some cases this makes it difficult for middle-boxes to be effective at >> their jobs. >> >> By putting the condition, fulfillment, and expiry on the ledger layer, w= e >>> leave it open for any ledger type to work, rather than forcing all >>> ledger-layer software to understand ILP. >>> >> >> Actually you do the opposite. You make it a requirement of every protoco= l >> below the ILP layer to define a way to carry these data elements and enc= ode >> and decode them, even if they don't use them >> >> Ledger layer components don't have to understand ILP unless they choose >> to re-use the condition for their own local transfer. Ledgers themselves >> *never* have to understand ILP. >> >> Remember a ledger layer protocol could use a completely different >> conditional payments scheme, like atomic mode ILP, where it takes the >> end-to-end condition and creates a new compound condition that depends o= n >> the fulfillment and some notary signature. >> >> There will be a component in a connector's stack that must pass the ILP >> packet to the next peer. If it does this using a transfer protocol that >> uses conditional transfers and wants to use the same condition as the IL= P >> packet then it must decode the packet. >> >> But, it will likely do something with that condition before sending the >> transfer to the ledger like encoding it differently or rehashing it >> (lightning?) so that it's in the form expected by the ledger. >> >> That's an implementation decision of the lower layer protocol used >> between those two peers. >> >> >>> >>> I agree that Interledger defines how conditions, fulfillments, and >>> expiries should be chained together, but it makes no assertions about t= heir >>> data format. >>> >> >> ILP doesn't define how anything is chained together. From the perspectiv= e >> of ILP the condition and fulfillment are end-to-end data. They are agree= d >> by the two endpoints who don't care how they get from Alice to Bob and b= ack. >> >> The design of ILP is such that it facilitates the design of lower level >> protocols that can be used to carry the ILP packets across multiple hops >> (networks) using economic incentives such that the sender pays enough fo= r >> the first hop to ensure that all nodes in between can extract the fee th= ey >> want and the receiver will still get the amount they expected.. >> >> >> >>> ILP says you should send your outgoing transfer with the same condition >>> as the incoming one, and a lower expiry. >>> >> >> No it doesn't. An internetworking protocol can't prescribe that kind of >> thing to lower level protocols. An incoming and outgoing transfer could = be >> sent using completely different protocols and the financial agreement wi= th >> the peers on those two routes could be vastly different too. >> >> The only service ILP requires of lower level protocols is that they can >> map a response to an original request. This requirement is okay because = it >> is isolated to a single route/link at a time not a requirement that cros= ses >> the inter-network boundary that ILP crosses. >> >> >>> But because ILP allows for many different types of ledgers, it doesn't >>> make sense to assert how these are encoded. >>> >> >> By putting them in the ILP packet you do the opposite. You make no >> assertions about how they are encoded if they are used at lower layers, = or >> how they may be combined with other conditions or even used to derive ne= w >> conditions. >> >>> >>> IP doesn't tell you how to encode an ethernet packet. It doesn't even >>> know whether it's going over a computer or a hand-written letter carrie= d by >>> a pigeon. IP takes for granted that you can send data over one connecti= on >>> by putting it in a lower level. >>> >> >> Correct, but if a link layer protocol wanted to look into the IP packet >> headers of a packet it wants to transfer and use some data from there in >> its internal logic (or even reuse data in it's own frame) that would be >> totally fine. >> >> >>> Even though IP tells you how to chain these connections together, it >>> doesn't have to put the things it's chaining on the internetworking lev= el. >>> >> >> IP doesn't tell you how to chain things together. IP simply defines the >> end-to end data envelope and address space. Because of this nodes that >> implement the multiple lower layer protocols are able to push IP packets >> down a link and expect the node on the other side to understand the head= ers >> and route it onward on another link. >> >> Everything needed by the IP module to decide what to do with the packet >> is in the IP packet headers. i.e. Has it exceeded a TTL? Is there a rout= e >> for this destination? Is it corrupted (checksum fails)? But also, >> everything that is needed by the endpoint (like the source address) is a= lso >> in there. >> >> There is no dependency on nodes to be good citizens and always pass >> certain other data from the lower layers into the next link. That would = be >> breaking the layering. >> >> >>> IP also assumes that if you get some incoming data on a connection you >>> can copy it and send it out on the next connection. Because you can alr= eady >>> send data over a connection, all IP adds is the missing piece: a packet >>> that tells you where to go. >>> >>> With ILP, we assume that there is a way to prepare a conditional >>> transfer, expire a conditional transfer, and fulfill a conditional >>> transfer. >>> >> >> No we don't! We assume that if we deliver the packet as intended we'll >> get back a response packet with a signature that matches the condition i= n >> the packet. So, if we have an agreement with someone that they will pay = us >> when we present that signature then we are prepared to enter a similar >> agreement with the next peer because we expect that signature to come al= l >> the way back along the interledger layer route.. >> >> >>> We also assume that if you get an incoming transfer you can create an >>> outgoing transfer with the same condition. The abstraction we made mean= s >>> that conditions and fulfillments are already carried in the lower level= s. >>> >> >> That is a bad assumption that comes from the broken layering. What if my >> outgoing link doesn't support conditional transfers? So now where do I p= ut >> the condition? >> >>> >>> >>> We could have assumed that no ledgers ever support conditional >>> transfers, and said the only thing ILP gets from lower levels is the >>> ability to send a transfer. But if we want to support the case where an= y of >>> them do, we have to keep the conditions and fulfillments in the layer w= here >>> they're actually used. >>> >> >> I don't follow that logic at all. If we want to support the case where >> any of them do then we must ensure the condition and expiry are always >> carried in a consistent place at the internetworking layer so that if th= ey >> do want to use them they know where to find them. >> >> >>> >>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>> adrian@hopebailie.com> wrote: >>> >>>> >>>> >>>> On 14 August 2017 at 22:03, Evan Schwartz wrote: >>>> >>>>> I think this thread is going to get extremely unwieldy but here goes: >>>>> >>>>> > - All interledger layer messages should be ILP packets (including >>>>> fulfillments) and be capable of carrying higher layer protocol payloa= ds. >>>>> >>>>> Interledger has higher requirements than ILP for the lowest layer, >>>>> specifically because we are carrying money and not just data. One of = the >>>>> requirements is being able to transmit a 32-byte fulfillment back alo= ng the >>>>> same path that carried the payment originally. If we expect this of t= he >>>>> lower layer, I don't see a point in putting the fulfillment into an I= LP >>>>> packet and transmitting it as Interledger data along the same path. A= ll >>>>> ledger-layer protocols will need to interpret the fulfillment passed = in >>>>> their protocol, not the one passed through the Interledger layer. >>>>> >>>> >>>> This is not correct. There is no requirement on ledger layer protocols >>>> to transmit or understand the fulfillment. You are looking at this thr= ough >>>> the lens of existing implementations from the bottom up instead of sta= rting >>>> at the interledger layer. >>>> >>>> The primary function of the condition and fulfillment is as a signed >>>> end-to-end receipt. If the sender agrees a condition with a receiver a= nd >>>> then gets back the valid fulfillment they don't care what happened in = the >>>> middle. The receiver has signed a receipt saying they have their money= . >>>> >>>> The value of using a standard for the receipt and signature is that >>>> each transfer along the way CAN re-use it. One the one hand you can ha= ve a >>>> transfer between two peers that have zero trust and the ledger they us= e >>>> supports conditional payments completely. On the other extreme you can= have >>>> two peers that have a full trust and ignore the condition and fulfillm= ent >>>> completely. >>>> >>>> The ledger layer protocols carry ILP packets. Payment requests and >>>> either fulfillment or error responses. If a ledger layer protocol want= s to >>>> use the condition and fulfillment for their own operations they can ex= tract >>>> these from the ILP packets and use them. >>>> >>>> >>>>> > - While it may make sense to split the interledger payment and >>>>> interledger quoting protocols into new higher level protocols that se= ems >>>>> like an unnecessary abstraction. Instead the packet definitions shoul= d just >>>>> have some consistency and probably a common base/header. >>>>> >>>>> The current protocols effectively have this header but it isn't >>>>> separated out. There are two fields in the request header: type and >>>>> destination address. There is one field in the response header: type.= I >>>>> don't think it makes that much of a big difference to separate these = fields >>>>> if all of the fields in that packet need to be interpreted together (= for >>>>> example, you can't understand a quote request if you strip off the >>>>> destination address). >>>>> >>>> >>>> I agree that we don't HAVE to explicitly separate them out but I think >>>> ti would make it clearer how the stack is architected if there was a h= eader >>>> that was consistent across all packets. Currently the only thing that = is >>>> consitent across all ILP packets is that they are defined int he same = file. >>>> >>>> >>>>> >>>>> > - We should define two base ILP packet types: request and response. >>>>> >>>>> Unless this adds some substantive benefit or new fields I don't think >>>>> it's worth breaking all of the formats we have just to rearrange thin= gs. >>>>> >>>> >>>> The goal of this exercise is to tease out the best design and ignore >>>> the cost of change until we can compare the results with the current d= esign. >>>> >>>> >>>>> >>>>> > - ILP is not about ledgers, it is about trustlines between >>>>> nodes/hosts. >>>>> >>>>> A ledger is any system that tracks accounts and balances. When you us= e >>>>> a trustline all of your messages still need to go through an accounti= ng >>>>> system (such as the plugin in the JS implementation) and then on to t= he >>>>> other program logic. >>>>> >>>> >>>> As above, this is incorrect. There is no requirement for "all messages >>>> to go through an accounting system". >>>> >>>> Since designing the first implementation of 5-bells ledger we have >>>> assumed that passing the ILP packet MUST be done by the ledger because= that >>>> is how we implemented it. But that is not true. It is perfectly valid = for >>>> the passing of an ILP packet from one peer to another to be simply an >>>> exchange of data. >>>> >>>> The receiving peer makes a decision about whether or not to forward th= e >>>> packet based on the current financial position they have with the send= ing >>>> peer. >>>> >>>> It is convenient if the ledger that records the net positions of the >>>> peers also forwards the messaging and even better if it natively suppo= rts >>>> conditional payments and can use the condition and the fulfillment fro= m the >>>> ILP packet for those but that's all it is, convenient. >>>> >>>> >>>> >>>>> In that case, the plugin or whatever is doing the accounting is the >>>>> ledger. Digital value is always tracked in ledgers, so I think it doe= s make >>>>> sense to think of this as the base layer. The reason to abstract the >>>>> functionality you expect from the ledger layer is precisely so you ca= n >>>>> handle it in different ways, depending on what the underlying systems >>>>> provide. >>>>> >>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>> >>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>> some type of HTLA >>>>> >>>>> 2. There are separate plugins for messaging and for transfers and >>>>> when you peer with someone you have to agree on a plugin for each >>>>> 3. We standardize the messaging part and say that all goes over IP >>>>> and then just have more minimal plugins for the on-ledger settleme= nts >>>>> >>>>> Number 1 is what we have and I think that still makes the most sense. >>>>> >>>> >>>> I think you're confusing implementation details and defining of >>>> interfaces with definition of a protocol stack. The only differences >>>> between the tree examples you have above is in implementation. >>>> >>>> From the perspective of the Interledger Protocol the implementation of >>>> the lower layers is not important, that's the whole point of layering.= By >>>> forcing important aspects of ILP like the condition, fulfillment and e= xpiry >>>> down into those layers you muddy the waters and we now have to standar= dize >>>> those protocols too. Instead we should just be defining the functions = they >>>> must provide and then leave it up to implementations to provide those >>>> functions. >>>> >>>> I know we want to define a standard to bootstrap the system (CLP) but >>>> that's misleading us into thinking it's an essential part of the stack= . >>>> It's perfectly valid for two peers to not use CLP and still be part of= the >>>> Interledger. >>>> >>>> That said, you raise an interesting consideration about the layers >>>> below ILP and actually I think it makes sense to split these. >>>> >>>> We keep trying to force messaging through the ledger layer and actuall= y >>>> that's the wrong place to put it if we can split the ledger layer into= a >>>> messaging layer and a ledger layer. That way we can stop trying to thi= nk of >>>> all HLTAs as ledgers. >>>> >>>> A thought, why not use sub-layers as is common in other stacks: >>>> >>>> 1. Link layer: Layer upon which two peers that have a direct link, or >>>> participate in the same payment network, communicate >>>> 2. Transfer/ ledger: Layer on which financial positions between two >>>> peers are recorded >>>> >>>> This reflects the already emerging HTLA model and many of our existing >>>> plugins and ledger integrations. >>>> Link Layer: XRP Paychan, Lightning >>>> Ledger Layer: XRP Ledger, Bitcoin >>>> >>>> This doesn't prevent us from defining a standard binary protocol that >>>> defines all of the operations for both layers (like CLP) but I see val= ue in >>>> distinguishing between these two. >>>> >>>> >>>>> >>>>> > - The protocol should differentiate between the operation of >>>>> preparing a transfer on a ledger and the operation of passing an ILP = packet >>>>> from one peer to another. >>>>> >>>>> The protocol assumes your conditional transfer is underpinned by some >>>>> HTLA >>>>> . >>>>> It doesn't care whether that's on-ledger or not. >>>>> >>>> >>>> What do you mean when you say "the protocol"? In my statement I am >>>> referring to ILP. >>>> My point above being that ILP expects ILP packets to be passed from >>>> peer to peer but has no expectations about transfers. >>>> >>>> It's perfectly legal (from an ILP perspective) for two peers to >>>> exchange ILP packets with no transfers. Clearly if a node routes a pac= ket >>>> on and has no incoming transfer it's going to lose money but that's a >>>> consideration for that node. It doesn't affect anyone else in the chai= n. >>>> >>>> ILP doesn't assume anything about transfers at all, let alone >>>> conditional transfers. It provides useful semantics for conditional >>>> transfers to be used by two peers to transact as part of a larger ILP >>>> payment. >>>> >>>> >>>>> >>>>> > - The condition and timeout should be included in the ILP payment >>>>> packet. >>>>> >>>>> I strongly disagree with this. We had this debate a year ago and I wa= s >>>>> on your side but was convinced that this is not a good idea. >>>>> >>>> >>>> Yes, I recall this and I'm sorry I didn't push harder on this point. >>>> Unfortunately I think the decision to pull it out of the packet is mos= tly >>>> driven by how our prototypes were implemented rather than good archite= cture. >>>> >>>>> >>>>> The layer below ILP must be capable of doing conditional transfers >>>>> based on sha256 hashlocks with 32-byte preimages. >>>>> >>>> >>>> This is not true and I think it would be useful for us to agree on thi= s >>>> as this seems to be the argument I am coming up against most often. Th= e >>>> peers participating in a transfer that is part of an ILP payment may w= ish >>>> to use conditional transfers as a way to enforce their agreement but t= his >>>> is not a requirement of the protocol. >>>> >>>> The agreement between any two peers is: "I will pay you X if you can >>>> provide a receipt that Y was paid Z before T". >>>> ILP provides a standard for expressing this agreement so that these ca= n >>>> be chained together BUT it is not a requirement that every agreement i= n the >>>> chain uses the condition, and fulfillment provided at the ILP layer. >>>> >>>> >>>>> >>>>> As a result, the original condition and the corresponding preimage >>>>> MUST be expressed in that layer. >>>>> >>>> >>>> As I have shown above, this is not true. >>>> >>>> >>>>> Then the question is whether we should also include it in the packet >>>>> that is forwarded. What ultimately convinced me is the following: All >>>>> connectors MUST ignore the condition if it is in the packet, because = they >>>>> are only guaranteed their money back if they use the same condition f= rom >>>>> the incoming transfer they got. >>>>> >>>> >>>> Here is where the layering is being corrupted. >>>> >>>> All connectors MUST inspect the condition in the ILP packet as part of >>>> their decision to route the packet or not. >>>> When the local transfer module of the connectors stack passes the ILP >>>> packet up to the ILP module it should indicate the properties of the >>>> incoming transfer that carried the packet. >>>> This is essential firstly so that the routing logic in the ILP module >>>> can record the incoming transfer identifier so it is able to use the >>>> correct response id when it passes back the fulfillment or error. >>>> The other properties that the ILP module should look at are the >>>> condition and expiry on the incoming transfer. >>>> >>>> If the incoming route uses conditional transfers and these are suppose= d >>>> to match the condition and expiry in the ILP packet then the ILP modul= e >>>> should compare them and reject the packet if: >>>> a) the conditions don't match OR >>>> b) the expiry is too short >>>> >>>> We should still discuss if the expiry should be set by the sender and >>>> left unchanged or used like a TTL and decremented by each node. >>>> >>>> >>>>> Also, the receiver will need to take out the condition in order to >>>>> hash the packet for PSK or IPR. >>>>> >>>> >>>> This is completely normal. Zeroing a checksum field in a header before >>>> calculating the checksum is VERY common precisely because it's long be= en >>>> accepted that the right place to put that data is in the headers and t= he >>>> work of zero'ing it out to calculate the checksum (or signature in our >>>> case) is not material. >>>> >>>> >>>>> So basically, no one wants the condition in there. It feels like it >>>>> ought to be in there, but literally none of the parties want the extr= a 32 >>>>> bytes in there. >>>>> >>>> >>>> "Nobody wants it there" is a terrible reason to abandon the correct >>>> design. The whole purpose of a good architecture is you accept that th= ere >>>> may be cases in future that haven't been considered now so designing j= ust >>>> for the known cases is a bad idea. >>>> >>>> Good architecture is not the same as optimization. Taking stuff out >>>> (even when it feels wrong) to save a few bytes is a good sign that it'= s a >>>> bad idea. >>>> >>>> >>>>> >>>>> The reason the timeout should not be in there is that there isn't a >>>>> single timeout for the payment. There are multiple separate timeouts = for >>>>> each of the bilateral transfers. Those must go in the individual tran= sfers >>>>> and there is no sensible value to put in the Interledger packet. >>>>> >>>> >>>> As above, this is somewhat equivalent to the TTL in an IP packet. I'm >>>> open to discussing if it should be a fixed value set by the sender whe= re >>>> each node uses their own value but has the sender-defined value as a >>>> reference or it is actually decremented at each hop. >>>> >>>> Either way, this is part of ILP not the ledger layer just like the >>>> condition and fulfillment. It may be used by the ledger layer but that= 's >>>> implementation specific. It belongs in the ILP packet. >>>> >>>>> >>>>> >>>>> >>>> >>> >> > -- Sent from a mobile device, please excuse any typos --f4030436207ebe5d2d0556ce0dce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Exactly =F0=9F=91=8D

    On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian <sharafian@ripple.com> wrote:
    Ok, I think I have a better idea of what you= 're saying.

    It sounds like you're saying the ILP= layer contains all information that is common between every hop (destinati= on, destination amount, opaque data, condition, fulfillment, expiry). The l= ower level would then be used for all the transfer-local details (source am= ount, next connector account, custom/local data).

    = If the lower level wanted to do anything related to the every-hop payment, = i.e. escrow funds until the receipt has been produced, it would look into t= he ILP layer for that information. If the lower level didn't do any esc= row or expiries that require every-hop details, it would simply function as= a communication method.

    Is that right?

    On Tue, Aug 15, = 2017 at 6:35 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    On 15 August 2017 at 16:00, Ben Sharafian <sharafian= @ripple.com> wrote:
    In that case, = the plugin or whatever is doing the accounting is the ledger. Digital value= is always tracked in ledgers, so I think it does make sense to think of th= is as the base layer. The reason to abstract the functionality you expect f= rom the ledger layer is precisely so you can handle it in different ways, d= epending on what the underlying systems provide.
    I see 3 ways t= o think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messaging capa= bilities and some type of=C2=A0HTLA
    1. There are separate plugins for messaging and for transfers and w= hen you peer with someone you have to agree on a plugin for each
    <= ol>
  • We standardize the messaging part and say= that all goes over IP and then just have more minimal plugins for the on-l= edger settlements
    • Number 1 is what we have and I think that still = makes the most sense.

    I t= hink you're confusing implementation details and defining of interfaces= with definition of a protocol stack. The only differences between the tree= examples you have above is in implementation.

    =
    I had to scroll up after reading this to make sure it was= @adrian talking, because that seems like the opposite of what you were arg= uing for.

    I don't t= hink so. But I think that is part of the problem. We are not all focused on= the same thing. I am actually not very interested in CLP at all. It is one= of potentially many protocols that may exist below the ILP layer. All we&#= 39;re doing by defining CLP is bootstrapping the network by defining a prot= ocol for everyone to use to get started.

    In designing the= ILP layer properly we should try and forget everything we know about the l= ower layers other than what features we require of them.

    = There is a misconception that ILP requires the lower layers to support cond= itional transfers, that is not true.

    All we actually need= from a lower layer protocol is to transfer data back and forth and provide= a way to reliably map requests to responses.

    What ILP pr= ovides lower layers is a way to reward your peer for passing on the packet.= The Internetworking layer defines a condition, a reward that must be paid = to the receiver for the fulfillment and the time allowed to claim this rewa= rd.

    Because of this, within lower-layer protoc= ols that offer the basic request/response features we need, we could add co= nditional payment semantics that use the condition, expiry and fulfillment = provided by ILP. This would allow a node to offer a reward to=C2=A0 their n= ext peer to for delivering the packet they send them and to make the local = financial transaction contingent on the end-to-end transaction.

    But crucially, adding that semantic to the lower layer protocol prov= ides nothing extra to the ILP layer. The value is purely derived from the t= wo peers who use that protocol and can now use conditional payments to prot= ect themselves from their peers.
    =C2=A0
    The proposal that you'= ;re arguing for is basically asserting that we're going to be using CLP= , because it makes the assumption that the connectors (who understand ILP) = are managing the HTLA logic.

    =
    Not at all. I am asserting that it doesn't matter what protocol yo= u use below the ILP layer because it shouldn't matter. All of this talk= about ILP being different because money is more important than data is non= sense.

    The difference between ILP and IP that makes ILP suitab= le for value transfer and IP not is at the internetworking layer. ILP requi= res that all packets are either a request or response and that the response= s follow the same path as the requests. Further ILP defines a signature sch= eme that gives the sender a way to be certain the request was received by t= he receiver.

    This could be done = entirely without money but then there would be little incentive to sign= the receipt or deliver the signature back to the original sender.

    <= /div>
    So, if you add money then you add economic = incentives to the mix. At each hop the sender promises the next upstream pe= er a payment if they can return the receipt. The net effect is that this ca= n be used to transfer money from the sender to the receiver by simply defin= ing up front the amount that the receiver must get to produce the signature= .
    =C2=A0
    In the current model, the CLP/trustline model and the direct le= dger model both work without having to treat anything on the ILP layer diff= erently. We're favoring on-ledger messaging because of our implementati= on, yes, but we've been able to switch most all of our plugins from on-= ledger messaging to RPC-based messaging without changing the ILP layer at a= ll.

    With the ledger-level abstraction, we were abl= e to switch from our ledger-based mode of thinking to the CLP/trustline bas= ed way without changing anything other than the plugin. Your argument comes= from an assumption of a CLP-style ledger protocol with some underlying led= ger, which we can't assume is always the case.
    =

    I'm not sure what any of that proves tbh. These a= re all implementation concerns. They don't change the fact that the con= dition, expiry and fulfillment are part of ILP not the lower layer protocol= s.
    =C2=A0

    From the perspective of the In= terledger Protocol the implementation of the lower layers is not important,= that's the whole point of layering. By forcing important aspects of IL= P like the condition, fulfillment and expiry down into those layers you mud= dy the waters and we now have to standardize those protocols too. Instead w= e should just be defining the functions they must provide and then leave it= up to implementations to provide those functions.
    =
    I don't agree with this point; the condition and = fulfillment have actual meaning to the ledger layer.

    NO THEY DON'T! They have meaning to SOME = ledgers that implement SOME lower layer protocols, IF they choose to use th= em.

    Excuse the shouting but this is the crux of the issue= . We need to all agree that it is entirely possible for a transfer to be do= ne that doesn't use the condition and fulfillment and that if this was = in the middle of a 10-hop ILP payment it would have no effect on the sender= and receiver.
    =C2=A0
    You've said that the ledger often doesn't care= about fulfillment and condition, but the ledger _layer_'s (where trans= fers are done) role is to take in condition and fulfillment and make a tran= sfer which satisfies its HTLA.

    No, the ledger's role is to keep a tab of net financial positions be= tween two peers. It MAY use conditions and fulfillments that it pulls from = the ILP layer to help it do that in a way both peers agree on.

    Note that a "layer" doesn't have = a role. I think there is some confusion about the difference between layeri= ng the protocol and abstracting functionality into different components.
    =C2=A0
    If the = ledger layer has to look into the ILP packet to do so, that is a blatant br= eaking of layering.

    Not= at all! The module acting at the layers below the internetworking l= ayer shouldn't modify anything inside the packets of the higher layers = but they can definitely inspect them and adjust their behavior based on wha= t they to find.

    In fact the prevalence of this is the subject = of a lot of debate at the IETF currently because endpoints are often encryp= ting their payloads and in some cases this makes it difficult for middle-bo= xes to be effective at their jobs.

    =
    By puttin= g the condition, fulfillment, and expiry on the ledger layer, we leave it o= pen for any ledger type to work, rather than forcing all ledger-layer softw= are to understand ILP.

    A= ctually you do the opposite. You make it a requirement of every protocol be= low the ILP layer to define a way to carry these data elements and encode a= nd decode them, even if they don't use them

    Ledger la= yer components don't have to understand ILP unless they choose to re-us= e the condition for their own local transfer. Ledgers themselves never have to understand ILP.

    Remember a ledger layer protocol could u= se a completely different conditional payments scheme, like atomic mode ILP= , where it takes the end-to-end condition and creates a new compound condit= ion that depends on the fulfillment and some notary signature.

    There will be a component in a connector's stack that must pass t= he ILP packet to the next peer. If it does this using a transfer protocol t= hat uses conditional transfers and wants to use the same condition as the I= LP packet then it must decode the packet.

    But, it will li= kely do something with that condition before sending the transfer to the le= dger like encoding it differently or rehashing it (lightning?) so that it&#= 39;s in the form expected by the ledger.

    That&= #39;s an implementation decision of the lower layer protocol used between t= hose two peers.
    =C2=A0

    I agree that Interledger de= fines how conditions, fulfillments, and expiries should be chained together= , but it makes no assertions about their data format.

    ILP doesn't define how anything is chain= ed together. From the perspective of ILP the condition and fulfillment are = end-to-end data. They are agreed by the two endpoints who don't care ho= w they get from Alice to Bob and back.

    The design of ILP = is such that it facilitates the design of lower level protocols that can be= used to carry the ILP packets across multiple hops (networks) using econom= ic incentives such that the sender pays enough for the first hop to ensure = that all nodes in between can extract the fee they want and the receiver wi= ll still get the amount they expected..

    =C2=A0
    ILP says you s= hould send your outgoing transfer with the same condition as the incoming o= ne, and a lower expiry.

    No it doesn't. An internetworking protocol can't prescribe that ki= nd of thing to lower level protocols. An incoming and outgoing transfer cou= ld be sent using completely different protocols and the financial agreement= with the peers on those two routes could be vastly different too.

    T= he only service ILP requires of lower level protocols is that they can map = a response to an original request. This requirement is okay because it is i= solated to a single route/link at a time not a requirement that crosses the= inter-network boundary that ILP crosses.
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
    But because ILP = allows for many different types of ledgers, it doesn't make sense to as= sert how these are encoded.

    <= div>By putting them in the ILP packet you do the opposite. You make no asse= rtions about how they are encoded if they are used at lower layers, or how = they may be combined with other conditions or even used to derive new condi= tions.

    IP doesn't tell you how to encode an ethernet pac= ket. It doesn't even know whether it's going over a computer or a h= and-written letter carried by a pigeon. IP takes for granted that you can s= end data over one connection by putting it in a lower level.

    Correct, but if a link layer protocol= wanted to look into the IP packet headers of a packet it wants to transfer= and use some data from there in its internal logic (or even reuse data in = it's own frame) that would be totally fine.
    =C2=A0<= /div>
    Even thoug= h IP tells you how to chain these connections together, it doesn't have= to put the things it's chaining on the internetworking level.

    IP doesn't tell you how to = chain things together. IP simply defines the end-to end data envelope and a= ddress space. Because of this nodes that implement the multiple lower layer= protocols are able to push IP packets down a link and expect the node on t= he other side to understand the headers and route it onward on another link= .

    Everything needed by the IP module to decide what to do= with the packet is in the IP packet headers. i.e. Has it exceeded a TTL? I= s there a route for this destination? Is it corrupted (checksum fails)? But= also, everything that is needed by the endpoint (like the source address) = is also in there.

    There is no dependency on nodes to be g= ood citizens and always pass certain other data from the lower layers into = the next link. That would be breaking the layering.
    =C2= =A0
    IP als= o assumes that if you get some incoming data on a connection you can copy i= t and send it out on the next connection. Because you can already send data= over a connection, all IP adds is the missing piece: a packet that tells y= ou where to go.

    With ILP, we assume that there is = a way to prepare a conditional transfer, expire a conditional transfer, and= fulfill a conditional transfer.

    No we don't! We assume that if we deliver the packet as inten= ded we'll get back a response packet with a signature that matches the = condition in the packet. So, if we have an agreement with someone that they= will pay us when we present that signature then we are prepared to enter a= similar agreement with the next peer because we expect that signature to c= ome all the way back along the interledger layer route..
    =C2=A0
    W= e also assume that if you get an incoming transfer you can create an outgoi= ng transfer with the same condition. The abstraction we made means that con= ditions and fulfillments are already carried in the lower levels.

    That is a bad assumption that com= es from the broken layering. What if my outgoing link doesn't support c= onditional transfers? So now where do I put the condition?
    = =C2=A0

    We could have assumed that no ledgers ever support conditional transf= ers, and said the only thing ILP gets from lower levels is the ability to s= end a transfer. But if we want to support the case where any of them do, we= have to keep the conditions and fulfillments in the layer where they'r= e actually used.

    I don&#= 39;t follow that logic at all. If we want to support the case where any of = them do then we must ensure the condition and expiry are always carried in = a consistent place at the internetworking layer so that if they do want to = use them they know where to find them.
    =C2=A0

    On Tue, Aug 15, 2017= at 12:04 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">


    On 14 August 2017 at 22:03, = Evan Schwartz <evan@ripple.com> wrote:
    I think this thread is going to get extremely unwiel= dy but here goes:

    >=C2=A0- All interledger layer messages should be ILP packets (inclu= ding fulfillments) and be capable of carrying higher layer protocol payload= s.

    Interledger has higher requiremen= ts than ILP for the lowest layer, specifically because we are carrying mone= y and not just data. One of the requirements is being able to transmit a 32= -byte fulfillment back along the same path that carried the payment origina= lly. If we expect this of the lower layer, I don't see a point in putti= ng the fulfillment into an ILP packet and transmitting it as Interledger da= ta along the same path. All ledger-layer protocols will need to interpret t= he fulfillment passed in their protocol, not the one passed through the Int= erledger layer.

    This is not c= orrect. There is no requirement on ledger layer protocols to transmit or un= derstand the fulfillment. You are looking at this through the lens of exist= ing implementations from the bottom up instead of starting at the interledg= er layer.

    The primary function of = the condition and fulfillment is as a signed end-to-end receipt. If the sen= der agrees a condition with a receiver and then gets back the valid fulfill= ment they don't care what happened in the middle. The receiver has sign= ed a receipt saying they have their money.

    The value of using a standard for the receipt and signature is that= each transfer along the way CAN re-use it. One the one hand you can have a= transfer between two peers that have zero trust and the ledger they use su= pports conditional payments completely. On the other extreme you can have t= wo peers that have a full trust and ignore the condition and fulfillment co= mpletely.
    =C2=A0
    The ledger la= yer protocols carry ILP packets. Payment requests and either fulfillment or= error responses. If a ledger layer protocol wants to use the condition and= fulfillment for their own operations they can extract these from the ILP p= ackets and use them.

    <= span>

    >=C2=A0- Wh= ile it may make sense to split the interledger payment and interledger quot= ing protocols into new higher level protocols that seems like an unnecessar= y abstraction. Instead the packet definitions should just have some consist= ency and probably a common base/header.

    The current protocols effectively have this header but it isn't= separated out. There are two fields in the request header: type and destin= ation address. There is one field in the response header: type. I don't= think it makes that much of a big difference to separate these fields if a= ll of the fields in that packet need to be interpreted together (for exampl= e, you can't understand a quote request if you strip off the destinatio= n address).

    I agr= ee that we don't HAVE to explicitly separate them out but I think ti wo= uld make it clearer how the stack is architected if there was a header that= was consistent across all packets. Currently the only thing that is consit= ent across all ILP packets is that they are defined int he same file.
    =C2=A0

    >=C2=A0- We should define two base ILP packet types: request and re= sponse.

    Unless this adds some substan= tive benefit or new fields I don't think it's worth breaking all of= the formats we have just to rearrange things.

    The goal of this exercise is to tease out the best d= esign and ignore the cost of change until we can compare the results with t= he current design.
    =C2=A0

    >=C2=A0- ILP is not about ledgers, it is about trustli= nes between nodes/hosts.

    A ledger is any system that tracks accounts and balances. When you = use a trustline all of your messages still need to go through an accounting= system (such as the plugin in the JS implementation) and then on to the ot= her program logic.

    As a= bove, this is incorrect. There is no requirement for "all messages to = go through an accounting system".

    Since designing th= e first implementation of 5-bells ledger we have assumed that passing the I= LP packet MUST be done by the ledger because that is how we implemented it.= But that is not true. It is perfectly valid for the passing of an ILP pack= et from one peer to another to be simply an exchange of data.

    =
    The receiving peer makes a decision about whether or not to forward th= e packet based on the current financial position they have with the sending= peer.

    It is convenient if the ledger that rec= ords the net positions of the peers also forwards the messaging and even be= tter if it natively supports conditional payments and can use the condition= and the fulfillment from the ILP packet for those but that's all it is= , convenient.

    =C2=A0
    In that case, the plugin or whatever is = doing the accounting is the ledger. Digital value is always tracked in ledg= ers, so I think it does make sense to think of this as the base layer. The = reason to abstract the functionality you expect from the ledger layer is pr= ecisely so you can handle it in different ways, depending on what the under= lying systems provide.

    I see 3 ways to think of th= e layer(s) underpinning ILP:
    1. The "L= edger Layer" provides both messaging capabilities and some type of HTLA=
    2. There are separate plugins for messaging and for transfers = and when you peer with someone you have to agree on a plugin for each
      3. <= li>We standardize the messaging part and say that all goes over IP and then= just have more minimal plugins for the on-ledger settlements
    Number 1 is what we have and I think that still makes the most sense.

    I think you're confusing implement= ation details and defining of interfaces with definition of a protocol stac= k. The only differences between the tree examples you have above is in impl= ementation.

    From the perspective of the Interledger Protocol the imp= lementation of the lower layers is not important, that's the whole poin= t of layering. By forcing important aspects of ILP like the condition, fulf= illment and expiry down into those layers you muddy the waters and we now h= ave to standardize those protocols too. Instead we should just be defining = the functions they must provide and then leave it up to implementations to = provide those functions.

    I know we = want to define a standard to bootstrap the system (CLP) but that's misl= eading us into thinking it's an essential part of the stack. It's p= erfectly valid for two peers to not use CLP and still be part of the Interl= edger.

    That said, you raise an interesting consideration about the layer= s below ILP and actually I think it makes sense to split these.

    We keep trying to force messaging through the ledger layer and actua= lly that's the wrong place to put it if we can split the ledger layer i= nto a messaging layer and a ledger layer. That way we can stop trying to th= ink of all HLTAs as ledgers.

    A thought, why not use sub-l= ayers as is common in other stacks:

    1. Link layer: Layer = upon which two peers that have a direct link, or participate in the same pa= yment network, communicate
    2. Transfer/ ledger: Layer on whic= h financial positions between two peers are recorded

    This reflects t= he already emerging HTLA model and many of our existing plugins and ledger = integrations.
    Link Layer: XRP Paychan, Lightning
    Ledger Layer: XRP Ledger, Bitcoin

    This doesn= 't prevent us from defining a standard binary protocol that defines all= of the operations for both layers (like CLP) but I see value in distinguis= hing between these two.
    =C2=A0

    >=C2=A0<= span style=3D"color:rgb(33,33,33)">- The protocol should differentiate betw= een the operation of preparing a transfer on a ledger and the operation of = passing an ILP packet from one peer to another.

    The protocol assumes your conditional transf= er is underpinned by some HTLA. It doesn't care whether that's on-le= dger or not.

    What do you mean= when you say "the protocol"? In my statement I am referring to I= LP.
    My point above being that ILP expects ILP packets to be passed from= peer to peer but has no expectations about transfers.

    It's perfectly legal (from an ILP perspective) for = two peers to exchange ILP packets with no transfers. Clearly if a node rout= es a packet on and has no incoming transfer it's going to lose money bu= t that's a consideration for that node. It doesn't affect anyone el= se in the chain.

    ILP doesn't as= sume anything about transfers at all, let alone conditional transfers. It p= rovides useful semantics for conditional transfers to be used by two peers = to transact as part of a larger ILP payment.
    =C2=A0

    >=C2=A0= - The condition and timeout should be included in the ILP payment packet.

    I strongly disagree with this. We had= this debate a year ago and I was on your side but was convinced that this = is not a good idea.

    Yes,= I recall this and I'm sorry I didn't push harder on this point. Un= fortunately I think the decision to pull it out of the packet is mostly dri= ven by how our prototypes were implemented rather than good architecture.
    <= br>
    The layer below ILP must be capable of doing conditional tran= sfers based on sha256 hashlocks with 32-byte preimages.

    This is not true and I think it would be u= seful for us to agree on this as this seems to be the argument I am coming = up against most often. The peers participating in a transfer that is part o= f an ILP payment may wish to use conditional transfers as a way to enforce = their agreement but this is not a requirement of the protocol.

    The agreement between any two peers is: "I will pay you X if you= can provide a receipt that Y was paid Z before T".
    ILP = provides a standard for expressing this agreement so that these can be chai= ned together BUT it is not a requirement that every agreement in the chain = uses the condition, and fulfillment provided at the ILP layer.

    =C2=A0
    As= a result, the original condition and the corresponding preimage MUST be ex= pressed in that layer.

    = As I have shown above, this is not true.
    =C2=A0
    Then the question= is whether we should also include it in the packet that is forwarded. What= ultimately convinced me is the following: All connectors MUST ignore the c= ondition if it is in the packet, because they are only guaranteed their mon= ey back if they use the same condition from the incoming transfer they got.=

    = Here is where the layering is being corrupted.

    All connectors MUST i= nspect the condition in the ILP packet as part of their decision to route t= he packet or not.
    When the local transf= er module of the connectors stack passes the ILP packet up to the ILP modul= e it should indicate the properties of the incoming transfer that carried t= he packet.
    This is essential firstly so= that the routing logic in the ILP module can record the incoming transfer = identifier so it is able to use the correct response id when it passes back= the fulfillment or error.
    The other properties that the ILP module shou= ld look at are the condition and expiry on the incoming transfer.
    =

    If the incoming route uses c= onditional transfers and these are supposed to match the condition and expi= ry in the ILP packet then the ILP module should compare them and reject the= packet if:
    a) the conditions don't match OR
    b) the expiry is too short

    We should still discuss if t= he expiry should be set by the sender and left unchanged or used like a TTL= and decremented by each node.
    =C2=A0
    Also, the receiver will nee= d to take out the condition in order to hash the packet for PSK or IPR.

    This is completely normal.= Zeroing a checksum field in a header before calculating the checksum is VE= RY common precisely because it's long been accepted that the right plac= e to put that data is in the headers and the work of zero'ing it out to= calculate the checksum (or signature in our case) is not material.
    =C2=A0
    =
    So basically, no one wants the condition in there. It feels like = it ought to be in there, but literally none of the parties want the extra 3= 2 bytes in there.

    "= Nobody wants it there" is a terrible reason to abandon the correct des= ign. The whole purpose of a good architecture is you accept that there may = be cases in future that haven't been considered now so designing just f= or the known cases is a bad idea.

    Good architecture is no= t the same as optimization. Taking stuff out (even when it feels wrong) to = save a few bytes is a good sign that it's a bad idea.
    =C2=A0
    =
    The reason the timeout should not be in there is that there = isn't a single timeout for the payment. There are multiple separate tim= eouts for each of the bilateral transfers. Those must go in the individual = transfers and there is no sensible value to put in the Interledger packet.<= /div>
    =C2=A0
    As above, this is some= what equivalent to the TTL in an IP packet. I'm open to discussing if i= t should be a fixed value set by the sender where each node uses their own = value but has the sender-defined value as a reference or it is actually dec= remented at each hop.

    Either way, this is part of ILP not= the ledger layer just like the condition and fulfillment. It may be used b= y the ledger layer but that's implementation specific. It belongs in th= e ILP packet.
    =C2=A0





    --
    Sent from a mobile device, pl= ease excuse any typos
    --f4030436207ebe5d2d0556ce0dce-- From nobody Tue Aug 15 13:31:47 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7679B13226B for ; Tue, 15 Aug 2017 11:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=unhosted-org.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 QzfMiUi8Xgnr for ; Tue, 15 Aug 2017 11:21:10 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 4EC31132380 for ; Tue, 15 Aug 2017 11:21:10 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id d29so5863653uai.2 for ; Tue, 15 Aug 2017 11:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unhosted-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lt10MCIEqoVDR5pUmnkxgPxkeHBD2gxPd9383mwFeFk=; b=evrrLoAQFin2Ma0FxcqVMJ77EDm3W6RgJg5EHDE0S5rxhaHTVnXIykHQPvMaThDSNb tthqoK/+K2XLUIk9wgUokD5FPzMaYYj5UV1f6B2hmNAj2FNeahMNLAxyYqUAY/UtRk5H gaxa1R5Wn4GpNNnwnuVM+vT5QNXN7/6WTm2Xcn3Cz8fdQ0l6gSkGQMePVPwxp+B24k3N 3J50zdqjm0RjLgGAnMiiQm51KY9/FAQat7RhQG7wbEfXfCnZ00nVb8dLK9+hVH4CO6yX pC3Rz0lznri127ui2g9w8nIaz+XqA1liPshNRa+lgT70ClkJa5PAFStm8OIYsOUOkE5M iWOQ== 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=lt10MCIEqoVDR5pUmnkxgPxkeHBD2gxPd9383mwFeFk=; b=SgnzfDK+3G8uHG+YOkgI9Iz82sOUXaI3/h3oZOPDv2OrFD6u8UwNivoxyhtNB2kjJQ fjpO6sksbN2vLlebioVz6NuQRwwyFGMZhhBkB1S7NGGtarRYEtvJjLOvE6VJ+TEIVTMs R84FPf4f953t6jnm8jAnKlsUMKFPQ4OgLASMriVtIT8Af8C65nQbOLk7f+1WZ9e68351 lMNCsjbI1UH5LJAVVX39MW6Z/ZflKBSb6LyeSIJNlHTGFh71QDpySI6ZzjvUdJNtMsrZ ul15+vCm8G64uHJE9TpjV7lSnJ3vIEGkvl2I/CI44PNNzahDemh4caiYZ/KMC+jM5HuW lXyg== X-Gm-Message-State: AHYfb5gLkM6DuOjv6779j6i1n1kfT4/mxgKYyK/h5bhe12sdlqKo9KgT WoN3kELRYFeHKN7SpKG1WSXWCCWWPbKy X-Received: by 10.159.37.178 with SMTP id 47mr21099962uaf.48.1502821268912; Tue, 15 Aug 2017 11:21:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.141.86 with HTTP; Tue, 15 Aug 2017 11:21:07 -0700 (PDT) X-Originating-IP: [85.148.213.85] In-Reply-To: References: From: Michiel de Jong Date: Tue, 15 Aug 2017 20:21:07 +0200 Message-ID: To: Adrian Hope-Bailie Cc: Ben Sharafian , Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1137bf6ce568200556ced74d" Archived-At: X-Mailman-Approved-At: Tue, 15 Aug 2017 13:31:45 -0700 Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 18:21:16 -0000 --001a1137bf6ce568200556ced74d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for writing this up Adrian, I finally get it now. :) Yes, seen that way, it makes sense to say we want to have pure Interledger requests and pure Interledger responses. Even if it's just so that we can log them at that level. I agree with you that the view of "the condition and timeout belong to the ledger" is ledger centric or maybe even 5-bells-ledger centric, and it does not make sense if you design the Interledger layer first, and then afterwards look at what lower level systems you would need to implement it. I think the fields I would log about an Interledger payment request (and it's up to the lower layers to support these in whichever way), would be: * source amount * source timeout * condition * destination amount (aka higher-level value payload) * destination address * data (aka higher-level data payload) When you forward such a request, you decrease the source amount (also converting the source amount to the next currency, if necessary) and you make the source timeout a bit earlier, but the other 4 fields stay the same= . The response probably needs, in case of success: * fulfillment * time at which the response was sent (< source timeout) And in case of rejection: * rejectionReason QuoteRequests and QuoteResponses are probably already quite complete? Then on the host-to-host level, two hosts would do accounting of which payments were fulfilled correctly. It's now interesting to look at the "condition lives on two layers" issue from the opposite perspective: The ledger (accounting system) should be very careful not to have a separate way to represent the condition, because if that "ledger condition" would be different from the condition in the Interledger packet, then the ledger would be wrong. :) I don't really want to change CLP now, but at the same time, Adrian does have a point that the way CLP is proposed in https://github.com/interledger/rfcs/pull/271 is a host-to-host API design, and it would be better to design proper protocol layers into it. So I would vote for, let's just get to work with CLP as we have it now, but consider developing a v2 in which this layering is cleaned up? Apart from the reshuffle of the nesting of fields, it would mean the accounting/reconciliation system needs to reach into the Interledger request and response, to see the amount, timeout, condition, and fulfillment, compare them, and decide if the balance should change, so that's a bit of a change form CLP's current design. My 2ct, Michiel. On Tue, Aug 15, 2017 at 7:24 PM, Adrian Hope-Bailie wrote: > Exactly =F0=9F=91=8D > > On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian > wrote: > >> Ok, I think I have a better idea of what you're saying. >> >> It sounds like you're saying the ILP layer contains all information that >> is common between every hop (destination, destination amount, opaque dat= a, >> condition, fulfillment, expiry). The lower level would then be used for = all >> the transfer-local details (source amount, next connector account, >> custom/local data). >> >> If the lower level wanted to do anything related to the every-hop >> payment, i.e. escrow funds until the receipt has been produced, it would >> look into the ILP layer for that information. If the lower level didn't = do >> any escrow or expiries that require every-hop details, it would simply >> function as a communication method. >> >> Is that right? >> >> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >> adrian@hopebailie.com> wrote: >> >>> >>> >>> On 15 August 2017 at 16:00, Ben Sharafian wrote: >>> >>>> In that case, the plugin or whatever is doing the accounting is the >>>>>>> ledger. Digital value is always tracked in ledgers, so I think it d= oes make >>>>>>> sense to think of this as the base layer. The reason to abstract th= e >>>>>>> functionality you expect from the ledger layer is precisely so you = can >>>>>>> handle it in different ways, depending on what the underlying syste= ms >>>>>>> provide. >>>>>> >>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>> >>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>> some type of HTLA >>>>>> >>>>>> >>>>>> >>>>>> 1. There are separate plugins for messaging and for transfers and >>>>>> when you peer with someone you have to agree on a plugin for each >>>>>> >>>>>> >>>>>> 1. We standardize the messaging part and say that all goes over >>>>>> IP and then just have more minimal plugins for the on-ledger sett= lements >>>>>> >>>>>> Number 1 is what we have and I think that still makes the most sense= . >>>>> >>>>> >>>> I think you're confusing implementation details and defining of >>>>> interfaces with definition of a protocol stack. The only differences >>>>> between the tree examples you have above is in implementation. >>>> >>>> >>>> I had to scroll up after reading this to make sure it was @adrian >>>> talking, because that seems like the opposite of what you were arguing= for. >>>> >>> >>> I don't think so. But I think that is part of the problem. We are not >>> all focused on the same thing. I am actually not very interested in CLP= at >>> all. It is one of potentially many protocols that may exist below the I= LP >>> layer. All we're doing by defining CLP is bootstrapping the network by >>> defining a protocol for everyone to use to get started. >>> >>> In designing the ILP layer properly we should try and forget everything >>> we know about the lower layers other than what features we require of t= hem. >>> >>> There is a misconception that ILP requires the lower layers to support >>> conditional transfers, that is not true. >>> >>> All we actually need from a lower layer protocol is to transfer data >>> back and forth and provide a way to reliably map requests to responses. >>> >>> What ILP provides lower layers is a way to reward your peer for passing >>> on the packet. The Internetworking layer defines a condition, a reward = that >>> must be paid to the receiver for the fulfillment and the time allowed t= o >>> claim this reward. >>> >>> Because of this, within lower-layer protocols that offer the basic >>> request/response features we need, we could add conditional payment >>> semantics that use the condition, expiry and fulfillment provided by IL= P. >>> This would allow a node to offer a reward to their next peer to for >>> delivering the packet they send them and to make the local financial >>> transaction contingent on the end-to-end transaction. >>> >>> But crucially, adding that semantic to the lower layer protocol provide= s >>> nothing extra to the ILP layer. The value is purely derived from the tw= o >>> peers who use that protocol and can now use conditional payments to pro= tect >>> themselves from their peers. >>> >>> >>>> The proposal that you're arguing for is basically asserting that we're >>>> going to be using CLP, because it makes the assumption that the connec= tors >>>> (who understand ILP) are managing the HTLA logic. >>>> >>> >>> Not at all. I am asserting that it doesn't matter what protocol you use >>> below the ILP layer because it shouldn't matter. All of this talk about= ILP >>> being different because money is more important than data is nonsense. >>> >>> The difference between ILP and IP that makes ILP suitable for value >>> transfer and IP not is at the internetworking layer. ILP requires that = all >>> packets are either a request or response and that the responses follow = the >>> same path as the requests. Further ILP defines a signature scheme that >>> gives the sender a way to be certain the request was received by the >>> receiver. >>> >>> *This could be done entirely without money* but then there would be >>> little incentive to sign the receipt or deliver the signature back to t= he >>> original sender. >>> >>> So, if you add money then you add economic incentives to the mix. At >>> each hop the sender promises the next upstream peer a payment if they c= an >>> return the receipt. The net effect is that this can be used to transfer >>> money from the sender to the receiver by simply defining up front the >>> amount that the receiver must get to produce the signature. >>> >>> >>>> >>>> In the current model, the CLP/trustline model and the direct ledger >>>> model both work without having to treat anything on the ILP layer >>>> differently. We're favoring on-ledger messaging because of our >>>> implementation, yes, but we've been able to switch most all of our plu= gins >>>> from on-ledger messaging to RPC-based messaging without changing the I= LP >>>> layer at all. >>>> >>>> With the ledger-level abstraction, we were able to switch from our >>>> ledger-based mode of thinking to the CLP/trustline based way without >>>> changing anything other than the plugin. Your argument comes from an >>>> assumption of a CLP-style ledger protocol with some underlying ledger, >>>> which we can't assume is always the case. >>>> >>> >>> I'm not sure what any of that proves tbh. These are all implementation >>> concerns. They don't change the fact that the condition, expiry and >>> fulfillment are part of ILP not the lower layer protocols. >>> >>>> >>>> >>>> From the perspective of the Interledger Protocol the implementation of >>>>> the lower layers is not important, that's the whole point of layering= . By >>>>> forcing important aspects of ILP like the condition, fulfillment and = expiry >>>>> down into those layers you muddy the waters and we now have to standa= rdize >>>>> those protocols too. Instead we should just be defining the functions= they >>>>> must provide and then leave it up to implementations to provide those >>>>> functions. >>>> >>>> >>>> I don't agree with this point; the condition and fulfillment have >>>> actual meaning to the ledger layer. >>>> >>> >>> NO THEY DON'T! They have meaning to SOME ledgers that implement SOME >>> lower layer protocols, IF they choose to use them. >>> >>> Excuse the shouting but this is the crux of the issue. We need to all >>> agree that it is entirely possible for a transfer to be done that doesn= 't >>> use the condition and fulfillment and that if this was in the middle of= a >>> 10-hop ILP payment it would have no effect on the sender and receiver. >>> >>>> >>>> You've said that the ledger often doesn't care about fulfillment and >>>> condition, but the ledger _layer_'s (where transfers are done) role is= to >>>> take in condition and fulfillment and make a transfer which satisfies = its >>>> HTLA. >>>> >>> >>> No, the ledger's role is to keep a tab of net financial positions >>> between two peers. It MAY use conditions and fulfillments that it pulls >>> from the ILP layer to help it do that in a way both peers agree on. >>> >>> Note that a "layer" doesn't have a role. I think there is some confusio= n >>> about the difference between layering the protocol and abstracting >>> functionality into different components. >>> >>> >>>> If the ledger layer has to look into the ILP packet to do so, that is = a >>>> blatant breaking of layering. >>>> >>> >>> Not at all! The module acting at the layers *below* the internetworking >>> layer shouldn't modify anything inside the packets of the higher layers= but >>> they can definitely inspect them and adjust their behavior based on wha= t >>> they to find. >>> >>> In fact the prevalence of this is the subject of a lot of debate at the >>> IETF currently because endpoints are often encrypting their payloads an= d in >>> some cases this makes it difficult for middle-boxes to be effective at >>> their jobs. >>> >>> By putting the condition, fulfillment, and expiry on the ledger layer, >>>> we leave it open for any ledger type to work, rather than forcing all >>>> ledger-layer software to understand ILP. >>>> >>> >>> Actually you do the opposite. You make it a requirement of every >>> protocol below the ILP layer to define a way to carry these data elemen= ts >>> and encode and decode them, even if they don't use them >>> >>> Ledger layer components don't have to understand ILP unless they choose >>> to re-use the condition for their own local transfer. Ledgers themselve= s >>> *never* have to understand ILP. >>> >>> Remember a ledger layer protocol could use a completely different >>> conditional payments scheme, like atomic mode ILP, where it takes the >>> end-to-end condition and creates a new compound condition that depends = on >>> the fulfillment and some notary signature. >>> >>> There will be a component in a connector's stack that must pass the ILP >>> packet to the next peer. If it does this using a transfer protocol that >>> uses conditional transfers and wants to use the same condition as the I= LP >>> packet then it must decode the packet. >>> >>> But, it will likely do something with that condition before sending the >>> transfer to the ledger like encoding it differently or rehashing it >>> (lightning?) so that it's in the form expected by the ledger. >>> >>> That's an implementation decision of the lower layer protocol used >>> between those two peers. >>> >>> >>>> >>>> I agree that Interledger defines how conditions, fulfillments, and >>>> expiries should be chained together, but it makes no assertions about = their >>>> data format. >>>> >>> >>> ILP doesn't define how anything is chained together. From the >>> perspective of ILP the condition and fulfillment are end-to-end data. T= hey >>> are agreed by the two endpoints who don't care how they get from Alice = to >>> Bob and back. >>> >>> The design of ILP is such that it facilitates the design of lower level >>> protocols that can be used to carry the ILP packets across multiple hop= s >>> (networks) using economic incentives such that the sender pays enough f= or >>> the first hop to ensure that all nodes in between can extract the fee t= hey >>> want and the receiver will still get the amount they expected.. >>> >>> >>> >>>> ILP says you should send your outgoing transfer with the same conditio= n >>>> as the incoming one, and a lower expiry. >>>> >>> >>> No it doesn't. An internetworking protocol can't prescribe that kind of >>> thing to lower level protocols. An incoming and outgoing transfer could= be >>> sent using completely different protocols and the financial agreement w= ith >>> the peers on those two routes could be vastly different too. >>> >>> The only service ILP requires of lower level protocols is that they can >>> map a response to an original request. This requirement is okay because= it >>> is isolated to a single route/link at a time not a requirement that cro= sses >>> the inter-network boundary that ILP crosses. >>> >>> >>>> But because ILP allows for many different types of ledgers, it doesn't >>>> make sense to assert how these are encoded. >>>> >>> >>> By putting them in the ILP packet you do the opposite. You make no >>> assertions about how they are encoded if they are used at lower layers,= or >>> how they may be combined with other conditions or even used to derive n= ew >>> conditions. >>> >>>> >>>> IP doesn't tell you how to encode an ethernet packet. It doesn't even >>>> know whether it's going over a computer or a hand-written letter carri= ed by >>>> a pigeon. IP takes for granted that you can send data over one connect= ion >>>> by putting it in a lower level. >>>> >>> >>> Correct, but if a link layer protocol wanted to look into the IP packet >>> headers of a packet it wants to transfer and use some data from there i= n >>> its internal logic (or even reuse data in it's own frame) that would be >>> totally fine. >>> >>> >>>> Even though IP tells you how to chain these connections together, it >>>> doesn't have to put the things it's chaining on the internetworking le= vel. >>>> >>> >>> IP doesn't tell you how to chain things together. IP simply defines the >>> end-to end data envelope and address space. Because of this nodes that >>> implement the multiple lower layer protocols are able to push IP packet= s >>> down a link and expect the node on the other side to understand the hea= ders >>> and route it onward on another link. >>> >>> Everything needed by the IP module to decide what to do with the packet >>> is in the IP packet headers. i.e. Has it exceeded a TTL? Is there a rou= te >>> for this destination? Is it corrupted (checksum fails)? But also, >>> everything that is needed by the endpoint (like the source address) is = also >>> in there. >>> >>> There is no dependency on nodes to be good citizens and always pass >>> certain other data from the lower layers into the next link. That would= be >>> breaking the layering. >>> >>> >>>> IP also assumes that if you get some incoming data on a connection you >>>> can copy it and send it out on the next connection. Because you can al= ready >>>> send data over a connection, all IP adds is the missing piece: a packe= t >>>> that tells you where to go. >>>> >>>> With ILP, we assume that there is a way to prepare a conditional >>>> transfer, expire a conditional transfer, and fulfill a conditional >>>> transfer. >>>> >>> >>> No we don't! We assume that if we deliver the packet as intended we'll >>> get back a response packet with a signature that matches the condition = in >>> the packet. So, if we have an agreement with someone that they will pay= us >>> when we present that signature then we are prepared to enter a similar >>> agreement with the next peer because we expect that signature to come a= ll >>> the way back along the interledger layer route.. >>> >>> >>>> We also assume that if you get an incoming transfer you can create an >>>> outgoing transfer with the same condition. The abstraction we made mea= ns >>>> that conditions and fulfillments are already carried in the lower leve= ls. >>>> >>> >>> That is a bad assumption that comes from the broken layering. What if m= y >>> outgoing link doesn't support conditional transfers? So now where do I = put >>> the condition? >>> >>>> >>>> >>>> We could have assumed that no ledgers ever support conditional >>>> transfers, and said the only thing ILP gets from lower levels is the >>>> ability to send a transfer. But if we want to support the case where a= ny of >>>> them do, we have to keep the conditions and fulfillments in the layer = where >>>> they're actually used. >>>> >>> >>> I don't follow that logic at all. If we want to support the case where >>> any of them do then we must ensure the condition and expiry are always >>> carried in a consistent place at the internetworking layer so that if t= hey >>> do want to use them they know where to find them. >>> >>> >>>> >>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>> adrian@hopebailie.com> wrote: >>>> >>>>> >>>>> >>>>> On 14 August 2017 at 22:03, Evan Schwartz wrote: >>>>> >>>>>> I think this thread is going to get extremely unwieldy but here goes= : >>>>>> >>>>>> > - All interledger layer messages should be ILP packets (including >>>>>> fulfillments) and be capable of carrying higher layer protocol paylo= ads. >>>>>> >>>>>> Interledger has higher requirements than ILP for the lowest layer, >>>>>> specifically because we are carrying money and not just data. One of= the >>>>>> requirements is being able to transmit a 32-byte fulfillment back al= ong the >>>>>> same path that carried the payment originally. If we expect this of = the >>>>>> lower layer, I don't see a point in putting the fulfillment into an = ILP >>>>>> packet and transmitting it as Interledger data along the same path. = All >>>>>> ledger-layer protocols will need to interpret the fulfillment passed= in >>>>>> their protocol, not the one passed through the Interledger layer. >>>>>> >>>>> >>>>> This is not correct. There is no requirement on ledger layer protocol= s >>>>> to transmit or understand the fulfillment. You are looking at this th= rough >>>>> the lens of existing implementations from the bottom up instead of st= arting >>>>> at the interledger layer. >>>>> >>>>> The primary function of the condition and fulfillment is as a signed >>>>> end-to-end receipt. If the sender agrees a condition with a receiver = and >>>>> then gets back the valid fulfillment they don't care what happened in= the >>>>> middle. The receiver has signed a receipt saying they have their mone= y. >>>>> >>>>> The value of using a standard for the receipt and signature is that >>>>> each transfer along the way CAN re-use it. One the one hand you can h= ave a >>>>> transfer between two peers that have zero trust and the ledger they u= se >>>>> supports conditional payments completely. On the other extreme you ca= n have >>>>> two peers that have a full trust and ignore the condition and fulfill= ment >>>>> completely. >>>>> >>>>> The ledger layer protocols carry ILP packets. Payment requests and >>>>> either fulfillment or error responses. If a ledger layer protocol wan= ts to >>>>> use the condition and fulfillment for their own operations they can e= xtract >>>>> these from the ILP packets and use them. >>>>> >>>>> >>>>>> > - While it may make sense to split the interledger payment and >>>>>> interledger quoting protocols into new higher level protocols that s= eems >>>>>> like an unnecessary abstraction. Instead the packet definitions shou= ld just >>>>>> have some consistency and probably a common base/header. >>>>>> >>>>>> The current protocols effectively have this header but it isn't >>>>>> separated out. There are two fields in the request header: type and >>>>>> destination address. There is one field in the response header: type= . I >>>>>> don't think it makes that much of a big difference to separate these= fields >>>>>> if all of the fields in that packet need to be interpreted together = (for >>>>>> example, you can't understand a quote request if you strip off the >>>>>> destination address). >>>>>> >>>>> >>>>> I agree that we don't HAVE to explicitly separate them out but I thin= k >>>>> ti would make it clearer how the stack is architected if there was a = header >>>>> that was consistent across all packets. Currently the only thing that= is >>>>> consitent across all ILP packets is that they are defined int he same= file. >>>>> >>>>> >>>>>> >>>>>> > - We should define two base ILP packet types: request and response= . >>>>>> >>>>>> Unless this adds some substantive benefit or new fields I don't thin= k >>>>>> it's worth breaking all of the formats we have just to rearrange thi= ngs. >>>>>> >>>>> >>>>> The goal of this exercise is to tease out the best design and ignore >>>>> the cost of change until we can compare the results with the current = design. >>>>> >>>>> >>>>>> >>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>> nodes/hosts. >>>>>> >>>>>> A ledger is any system that tracks accounts and balances. When you >>>>>> use a trustline all of your messages still need to go through an acc= ounting >>>>>> system (such as the plugin in the JS implementation) and then on to = the >>>>>> other program logic. >>>>>> >>>>> >>>>> As above, this is incorrect. There is no requirement for "all message= s >>>>> to go through an accounting system". >>>>> >>>>> Since designing the first implementation of 5-bells ledger we have >>>>> assumed that passing the ILP packet MUST be done by the ledger becaus= e that >>>>> is how we implemented it. But that is not true. It is perfectly valid= for >>>>> the passing of an ILP packet from one peer to another to be simply an >>>>> exchange of data. >>>>> >>>>> The receiving peer makes a decision about whether or not to forward >>>>> the packet based on the current financial position they have with the >>>>> sending peer. >>>>> >>>>> It is convenient if the ledger that records the net positions of the >>>>> peers also forwards the messaging and even better if it natively supp= orts >>>>> conditional payments and can use the condition and the fulfillment fr= om the >>>>> ILP packet for those but that's all it is, convenient. >>>>> >>>>> >>>>> >>>>>> In that case, the plugin or whatever is doing the accounting is the >>>>>> ledger. Digital value is always tracked in ledgers, so I think it do= es make >>>>>> sense to think of this as the base layer. The reason to abstract the >>>>>> functionality you expect from the ledger layer is precisely so you c= an >>>>>> handle it in different ways, depending on what the underlying system= s >>>>>> provide. >>>>>> >>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>> >>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>> some type of HTLA >>>>>> >>>>>> 2. There are separate plugins for messaging and for transfers and >>>>>> when you peer with someone you have to agree on a plugin for each >>>>>> 3. We standardize the messaging part and say that all goes over >>>>>> IP and then just have more minimal plugins for the on-ledger sett= lements >>>>>> >>>>>> Number 1 is what we have and I think that still makes the most sense= . >>>>>> >>>>> >>>>> I think you're confusing implementation details and defining of >>>>> interfaces with definition of a protocol stack. The only differences >>>>> between the tree examples you have above is in implementation. >>>>> >>>>> From the perspective of the Interledger Protocol the implementation o= f >>>>> the lower layers is not important, that's the whole point of layering= . By >>>>> forcing important aspects of ILP like the condition, fulfillment and = expiry >>>>> down into those layers you muddy the waters and we now have to standa= rdize >>>>> those protocols too. Instead we should just be defining the functions= they >>>>> must provide and then leave it up to implementations to provide those >>>>> functions. >>>>> >>>>> I know we want to define a standard to bootstrap the system (CLP) but >>>>> that's misleading us into thinking it's an essential part of the stac= k. >>>>> It's perfectly valid for two peers to not use CLP and still be part o= f the >>>>> Interledger. >>>>> >>>>> That said, you raise an interesting consideration about the layers >>>>> below ILP and actually I think it makes sense to split these. >>>>> >>>>> We keep trying to force messaging through the ledger layer and >>>>> actually that's the wrong place to put it if we can split the ledger = layer >>>>> into a messaging layer and a ledger layer. That way we can stop tryin= g to >>>>> think of all HLTAs as ledgers. >>>>> >>>>> A thought, why not use sub-layers as is common in other stacks: >>>>> >>>>> 1. Link layer: Layer upon which two peers that have a direct link, or >>>>> participate in the same payment network, communicate >>>>> 2. Transfer/ ledger: Layer on which financial positions between two >>>>> peers are recorded >>>>> >>>>> This reflects the already emerging HTLA model and many of our existin= g >>>>> plugins and ledger integrations. >>>>> Link Layer: XRP Paychan, Lightning >>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>> >>>>> This doesn't prevent us from defining a standard binary protocol that >>>>> defines all of the operations for both layers (like CLP) but I see va= lue in >>>>> distinguishing between these two. >>>>> >>>>> >>>>>> >>>>>> > - The protocol should differentiate between the operation of >>>>>> preparing a transfer on a ledger and the operation of passing an ILP= packet >>>>>> from one peer to another. >>>>>> >>>>>> The protocol assumes your conditional transfer is underpinned by som= e >>>>>> HTLA >>>>>> . >>>>>> It doesn't care whether that's on-ledger or not. >>>>>> >>>>> >>>>> What do you mean when you say "the protocol"? In my statement I am >>>>> referring to ILP. >>>>> My point above being that ILP expects ILP packets to be passed from >>>>> peer to peer but has no expectations about transfers. >>>>> >>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>> exchange ILP packets with no transfers. Clearly if a node routes a pa= cket >>>>> on and has no incoming transfer it's going to lose money but that's a >>>>> consideration for that node. It doesn't affect anyone else in the cha= in. >>>>> >>>>> ILP doesn't assume anything about transfers at all, let alone >>>>> conditional transfers. It provides useful semantics for conditional >>>>> transfers to be used by two peers to transact as part of a larger ILP >>>>> payment. >>>>> >>>>> >>>>>> >>>>>> > - The condition and timeout should be included in the ILP payment >>>>>> packet. >>>>>> >>>>>> I strongly disagree with this. We had this debate a year ago and I >>>>>> was on your side but was convinced that this is not a good idea. >>>>>> >>>>> >>>>> Yes, I recall this and I'm sorry I didn't push harder on this point. >>>>> Unfortunately I think the decision to pull it out of the packet is mo= stly >>>>> driven by how our prototypes were implemented rather than good archit= ecture. >>>>> >>>>>> >>>>>> The layer below ILP must be capable of doing conditional transfers >>>>>> based on sha256 hashlocks with 32-byte preimages. >>>>>> >>>>> >>>>> This is not true and I think it would be useful for us to agree on >>>>> this as this seems to be the argument I am coming up against most oft= en. >>>>> The peers participating in a transfer that is part of an ILP payment = may >>>>> wish to use conditional transfers as a way to enforce their agreement= but >>>>> this is not a requirement of the protocol. >>>>> >>>>> The agreement between any two peers is: "I will pay you X if you can >>>>> provide a receipt that Y was paid Z before T". >>>>> ILP provides a standard for expressing this agreement so that these >>>>> can be chained together BUT it is not a requirement that every agreem= ent in >>>>> the chain uses the condition, and fulfillment provided at the ILP lay= er. >>>>> >>>>> >>>>>> >>>>>> As a result, the original condition and the corresponding preimage >>>>>> MUST be expressed in that layer. >>>>>> >>>>> >>>>> As I have shown above, this is not true. >>>>> >>>>> >>>>>> Then the question is whether we should also include it in the packet >>>>>> that is forwarded. What ultimately convinced me is the following: Al= l >>>>>> connectors MUST ignore the condition if it is in the packet, because= they >>>>>> are only guaranteed their money back if they use the same condition = from >>>>>> the incoming transfer they got. >>>>>> >>>>> >>>>> Here is where the layering is being corrupted. >>>>> >>>>> All connectors MUST inspect the condition in the ILP packet as part o= f >>>>> their decision to route the packet or not. >>>>> When the local transfer module of the connectors stack passes the ILP >>>>> packet up to the ILP module it should indicate the properties of the >>>>> incoming transfer that carried the packet. >>>>> This is essential firstly so that the routing logic in the ILP module >>>>> can record the incoming transfer identifier so it is able to use the >>>>> correct response id when it passes back the fulfillment or error. >>>>> The other properties that the ILP module should look at are the >>>>> condition and expiry on the incoming transfer. >>>>> >>>>> If the incoming route uses conditional transfers and these are >>>>> supposed to match the condition and expiry in the ILP packet then the= ILP >>>>> module should compare them and reject the packet if: >>>>> a) the conditions don't match OR >>>>> b) the expiry is too short >>>>> >>>>> We should still discuss if the expiry should be set by the sender and >>>>> left unchanged or used like a TTL and decremented by each node. >>>>> >>>>> >>>>>> Also, the receiver will need to take out the condition in order to >>>>>> hash the packet for PSK or IPR. >>>>>> >>>>> >>>>> This is completely normal. Zeroing a checksum field in a header befor= e >>>>> calculating the checksum is VERY common precisely because it's long b= een >>>>> accepted that the right place to put that data is in the headers and = the >>>>> work of zero'ing it out to calculate the checksum (or signature in ou= r >>>>> case) is not material. >>>>> >>>>> >>>>>> So basically, no one wants the condition in there. It feels like it >>>>>> ought to be in there, but literally none of the parties want the ext= ra 32 >>>>>> bytes in there. >>>>>> >>>>> >>>>> "Nobody wants it there" is a terrible reason to abandon the correct >>>>> design. The whole purpose of a good architecture is you accept that t= here >>>>> may be cases in future that haven't been considered now so designing = just >>>>> for the known cases is a bad idea. >>>>> >>>>> Good architecture is not the same as optimization. Taking stuff out >>>>> (even when it feels wrong) to save a few bytes is a good sign that it= 's a >>>>> bad idea. >>>>> >>>>> >>>>>> >>>>>> The reason the timeout should not be in there is that there isn't a >>>>>> single timeout for the payment. There are multiple separate timeouts= for >>>>>> each of the bilateral transfers. Those must go in the individual tra= nsfers >>>>>> and there is no sensible value to put in the Interledger packet. >>>>>> >>>>> >>>>> As above, this is somewhat equivalent to the TTL in an IP packet. I'm >>>>> open to discussing if it should be a fixed value set by the sender wh= ere >>>>> each node uses their own value but has the sender-defined value as a >>>>> reference or it is actually decremented at each hop. >>>>> >>>>> Either way, this is part of ILP not the ledger layer just like the >>>>> condition and fulfillment. It may be used by the ledger layer but tha= t's >>>>> implementation specific. It belongs in the ILP packet. >>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> -- > Sent from a mobile device, please excuse any typos > --001a1137bf6ce568200556ced74d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for writing this up Adrian, I finally get it now. := )

    Yes, seen that way, it makes sense to say we want to h= ave pure Interledger requests and pure Interledger responses. Even if it= 9;s just so that we can log them at that level.

    I = agree with you that the view of "the condition and timeout belong to t= he ledger" is ledger centric or maybe even 5-bells-ledger centric, and= it does not make sense if you design the Interledger layer first, and then= afterwards look at what lower level systems you would need to implement it= .

    I think the fields I would log about an Interled= ger payment request (and it's up to the lower layers to support these i= n whichever way), would be:

    * source amount
    <= div>* source timeout
    * condition
    * destination amount (= aka higher-level value payload)
    * destination address
    *= data (aka higher-level data payload)

    When you for= ward such a request, you decrease the source amount (also converting the so= urce amount to the next currency, if necessary) and you make the source tim= eout a bit earlier, but the other 4 fields stay the same.

    The response probably needs, in case of success:
    * fulfil= lment
    * time at which the response was sent (< source timeout)=

    And in case of rejection:
    * rejectionRe= ason

    QuoteRequests and QuoteResponses are probably= already quite complete?

    Then on the host-to-host = level, two hosts would do accounting of which payments were fulfilled corre= ctly.

    It's now interesting to look at the &quo= t;condition lives on two layers" issue from the opposite perspective:<= /div>

    The ledger (accounting system) should be very care= ful not to have a separate way to represent the condition, because if that = "ledger condition" would be different from the condition in the I= nterledger packet, then the ledger would be wrong. :)

    <= div>I don't really want to change CLP now, but at the same time, Adrian= does have a point that the way CLP is proposed in https://github.com/interledger/rfcs/pull/2= 71 is a host-to-host API design, and it would be better to design prope= r protocol layers into it.

    So I would vote for, le= t's just get to work with CLP as we have it now, but consider developin= g a v2 in which this layering is cleaned up?

    Apart= from the reshuffle of the nesting of fields, it would mean the accounting/= reconciliation system needs to reach into the Interledger request and respo= nse, to see the amount, timeout, condition, and fulfillment, compare them, = and decide if the balance should change, so that's a bit of a change fo= rm CLP's current design.


    My 2ct= ,
    Michiel.
    --
    Sent from a mobile devic= e, please excuse any typos

    --001a1137bf6ce568200556ced74d-- From nobody Tue Aug 15 17:12:44 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CB613241C for ; Tue, 15 Aug 2017 16:24:34 -0700 (PDT) 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 je2_k-nLCb9c for ; Tue, 15 Aug 2017 16:24:32 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 97C27132444 for ; Tue, 15 Aug 2017 16:24:32 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id t37so12466483qtg.5 for ; Tue, 15 Aug 2017 16:24:32 -0700 (PDT) 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=MBjSDF+EmVVFPr+WTQ/doO6sXbINVvIV+WrGFFlLOCw=; b=IWieQfmLJ/Io5gsZmubrGKgHbA3FcmuXRhPdycCwg/y6SCHzt0cRd8+NGYyv278/lT i1eXaUKjKmGgDcoBrRp70/nFNv2VWvvlLZ6nBYLePALngXjtvk/Mt17TKaEKcZIJE8Va Gd8gLKjZV11EPdZdLyUvT+OZg/Q15B/Hdu3grWftabTILnQo7aUL6YbhD9C5F7sRSD0d 16BlIdwj3y02zX//N1TKFWIj02IuKjHQuz5tNSG8q7uve8rSIQyCuEpgG3j/nkhSFJwy EIu/Z/UBJHSRw96FysmucQHhqGxjSI7jXlQl/XrPX4GQqbpdmA7HSM1/c3NJ8UhbRH4K P6PQ== 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=MBjSDF+EmVVFPr+WTQ/doO6sXbINVvIV+WrGFFlLOCw=; b=domuMOVZfTiVXskN+l1DD+Ne3Q2PcyG98BhCl/b5+xRrEiJ0qT1UtqUalM3Yx16eZK sVI5vRt/+KGUAiVh7EBHZXLiEpt1W224pdVrv8V+Q+Owb5z9VsJIbA0WycNzeW/35n59 /V3Hb9+qc8RurnFVm1ZC166QFFJj5rIOYGNoJBOvFHNvDDItlVi9aOO9ClEmF8vcVpqV hsdh+wOmaLK33kTEBjyyKEmkDDHvzkiWkXpY2KbYGR1wGJ9Ys1DEpO7npXGbjAeOsAAm 6iYu7p4A3hUDBGUVyNQ+bhiBxK9WcPXg1p+crpGhXFCrVc0IR7KZ6ePmRybdMo/zeB+j oWJg== X-Gm-Message-State: AHYfb5hkHEwRIwjmfEjgkXqwttI8ZyHAO8X6geLNHIseQ4d6eXrKzmxt qOfOno/Y2GThnksI3tIgqh2djzLFog== X-Received: by 10.200.39.212 with SMTP id x20mr41615617qtx.157.1502839471853; Tue, 15 Aug 2017 16:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.63.168 with HTTP; Tue, 15 Aug 2017 16:24:31 -0700 (PDT) In-Reply-To: References: From: David Nicol Date: Tue, 15 Aug 2017 18:24:31 -0500 Message-ID: To: Adrian Hope-Bailie Cc: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1135b542dfd6cf0556d31494" Archived-At: X-Mailman-Approved-At: Tue, 15 Aug 2017 17:12:43 -0700 Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 23:24:35 -0000 --001a1135b542dfd6cf0556d31494 Content-Type: text/plain; charset="UTF-8" here's a fine referenice for the OSI reference model: http://www.webopedia.com/quick_ref/OSI_Layers.asp The ILP project lives entirely in layer 7. Specific implementations would be constrained to specific choices in the lower levels, but I don't think ILP should care if the data is in ASCII or EBCDIC -- which is contrived, as all right-thinking protocols have demanded Unicode UTF8 for some years now. But still it shouldn't matter. And likewise for if messages are JSON-LD or Bencoded. Shouldn't matter. All the communications are over reliable bi-directional streams. That might fail at any time for any reason, but when they aren't failing they're reliable bi-directional streams. if the failure is "NETWORK TIMEOUT" or some other kind of failure, that doesn't matter, it's a failure of a stream. Which is too detailed, a failure of a stream implies a failure of a message, which as a semantic thing is composed of key/value or index/value associations, regardless of encoding or wire-protocols. In the language of that reference, ILP's internal layers (atop semantic messages between peers) would be "tiers" in a "tiered application architecture." okay that's my two cents. > Look forward to your thoughts! > --001a1135b542dfd6cf0556d31494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    here's a fine referenice for t= he OSI reference model:=C2=A0http://www.webopedia.com/quick_ref/OSI_Layers.asp
    =

    The ILP project lives entirely in layer 7. Specific imp= lementations would be constrained to specific choices in the lower levels, = but I don't think ILP should care if the data is in ASCII or EBCDIC -- = which is contrived, as all right-thinking protocols have demanded Unicode U= TF8 for some years now. But still it shouldn't matter. And likewise for= if messages are JSON-LD or Bencoded. Shouldn't matter.

    <= /div>
    All the communications are over reliable bi-directional streams. = That might fail at any time for any reason, but when they aren't failin= g they're reliable bi-directional streams. if the failure is "NETW= ORK TIMEOUT" or some other kind of failure, that doesn't matter, i= t's a failure of a stream. Which is too detailed, a failure of a stream= implies a failure of a message, which as a semantic thing is composed of k= ey/value or index/value associations, regardless of encoding or wire-protoc= ols.

    In the language of that reference, ILP's = internal layers (atop semantic messages between peers) would be "tiers= " in a "tiered application architecture."
    =C2=A0
    okay that's my two cents.

    =

    =C2=A0
    Look forward to your thoughts!

    --001a1135b542dfd6cf0556d31494-- From nobody Wed Aug 16 02:23:04 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165D7132025 for ; Wed, 16 Aug 2017 02:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ripple.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 vM4Mc0g2f6ps for ; Wed, 16 Aug 2017 02:22:56 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 07A9313201E for ; Wed, 16 Aug 2017 02:22:55 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id i66so28752636wmg.0 for ; Wed, 16 Aug 2017 02:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XDq6JY5vnaUo9lU6P08VdvWr2odRKc7DQAlI7X2a9zE=; b=RROvjkglQOAvlIguOTXZRTh4Xqs0DK3NWuBdEonft9OWNIL/WCDvsCjc8Lgpnx73hQ N5qJ3GklMOZ3t9PXGS9UmQoKVQ/eY9R5nhSg4eR/ijbAxi/3Ld8vdX7n7qoocbDMbzAu bN8mjXwpQcrHQEJ/QnMEmQsBIfzb/go38uo9U= 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=XDq6JY5vnaUo9lU6P08VdvWr2odRKc7DQAlI7X2a9zE=; b=MzOKI+gOHiIjDb0QP6Adk2o6FjIx6noFqJavMKyJs6jKzX3KtBZ8b4TMelZGtMX+qN feAIRXeFNOZx0LKhep5Uce+jkhWZNu1I0XCwCZjGtm2TKIBJKfhD9yTuZF7zREF1ODmY 63v25n4vi6DTzds0+13NqljfVb+J8UGwXRI2T3qoh3SvH2VZ3J28enZwam21xTiLE7kM AYtCs6rCvfwJ+k7jVsM3winLSCG+hQQzDnGqqB71Y8i4ElXBBT/qrqUKy8GCUe583og3 y4uTZQ1KAk0pqKppmaE1yccx6b7BRSNkhZNIBaZfkLKkW/ZgK/2VtquMDLWCCYZmYLjz UxfQ== X-Gm-Message-State: AHYfb5iZzTBj2GQUR3NIGCSoPOLMqUIBC3CIXS38IpGqtyFX4U0blVl5 WhHpdOaudApLUYjiGqGCyg1nRiYaRNiV X-Received: by 10.28.10.131 with SMTP id 125mr1001287wmk.132.1502875374234; Wed, 16 Aug 2017 02:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.60.135 with HTTP; Wed, 16 Aug 2017 02:22:53 -0700 (PDT) In-Reply-To: References: From: Ben Sharafian Date: Wed, 16 Aug 2017 02:22:53 -0700 Message-ID: To: Adrian Hope-Bailie Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a11442d84d2cd5f0556db707e" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 09:23:03 -0000 --001a11442d84d2cd5f0556db707e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, I think in that case we're mostly disagreeing over where the condition/fulfillment/expiry actually go in the data. The reason I don't agree with your position is based on which parties I think should be aware of ILP. I'll hold off on arguments about which current implementations this would break. There are a lot of cases where the ledger isn't going to care about the condition and fulfillment of an individual interledger payment. In this situation, transfers would be sent directly between two connectors. The connectors would still keep track of the balance between them (you could contrive a situation where this doesn't happen, but I think we can say tracking the balance is going to be the norm). In order to track the balance between each other accurately, the two connectors have to keep track of conditions, fulfillments, and expiries on each of the transfers. That means the connectors' accounting logic that handles the conditions, fulfillments, and expiries is going to be using some information inside the ILP packet and some information outside of it in order to perform these transfers. I think it's cleaner to say everything required to make these local transfers should go in one protocol, so the accounting logic of these connectors doesn't have to deal with ILP directly. Then the connectors' ILP-packet-related behavior can all be routing related. This would add a few benefits; two connectors could perform non-ILP conditional transfers between one another (which would be useful for reconciliation and settlement), and could also allow two connectors to use more complex condition types (i.e. signatures for atomic mode) without forcing us to support that in the ILP packet. It also keeps the integrity of the ILP packet as something lower levels don't modify; the connector has to modify the expiry in order to pass along an ILP payment (they may not modify the expiry if they're using something like atomic mode, but then we have the issue with advanced condition types not being supported in the ILP packet). In the case where the ledger _does_ care about the condition and fulfillment, the argument in favor of separating condition/fulfillment/expiry from the rest of the packet is similar. Because we don't control the features of all ledgers, we'll need our plugins or ledger adapters to be aware of ILP. This makes it hard to interact with any events that don't involve ILP packets, and impossible to handle features that extend beyond what we support in the ILP packet. We could pass details about non-ILP ledger features (like a crypto condition) in the side data, but in the event of any redundancy we have to check the ledger-supplied info, not the info in the ILP packet. Basically, condition/fulfillment/expiry are used for accounting local transfers (even if they aren't being "ledger" enforced) in addition to their role as every-hop information. By putting them in the ILP packet, we limit the special features that ledgers can support and make our software abstractions harder to separate cleanly. By putting them in the local transfer alongside the ILP packet but not inside it, we do separate the data a little more, but we have more freedom in what the underlying accounting and ledger logic can do, and our software modules will have more clearly separated domains. On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie wrote: > Exactly =F0=9F=91=8D > > On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian > wrote: > >> Ok, I think I have a better idea of what you're saying. >> >> It sounds like you're saying the ILP layer contains all information that >> is common between every hop (destination, destination amount, opaque dat= a, >> condition, fulfillment, expiry). The lower level would then be used for = all >> the transfer-local details (source amount, next connector account, >> custom/local data). >> >> If the lower level wanted to do anything related to the every-hop >> payment, i.e. escrow funds until the receipt has been produced, it would >> look into the ILP layer for that information. If the lower level didn't = do >> any escrow or expiries that require every-hop details, it would simply >> function as a communication method. >> >> Is that right? >> >> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >> adrian@hopebailie.com> wrote: >> >>> >>> >>> On 15 August 2017 at 16:00, Ben Sharafian wrote: >>> >>>> In that case, the plugin or whatever is doing the accounting is the >>>>>>> ledger. Digital value is always tracked in ledgers, so I think it d= oes make >>>>>>> sense to think of this as the base layer. The reason to abstract th= e >>>>>>> functionality you expect from the ledger layer is precisely so you = can >>>>>>> handle it in different ways, depending on what the underlying syste= ms >>>>>>> provide. >>>>>> >>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>> >>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>> some type of HTLA >>>>>> >>>>>> >>>>>> >>>>>> 1. There are separate plugins for messaging and for transfers and >>>>>> when you peer with someone you have to agree on a plugin for each >>>>>> >>>>>> >>>>>> 1. We standardize the messaging part and say that all goes over >>>>>> IP and then just have more minimal plugins for the on-ledger sett= lements >>>>>> >>>>>> Number 1 is what we have and I think that still makes the most sense= . >>>>> >>>>> >>>> I think you're confusing implementation details and defining of >>>>> interfaces with definition of a protocol stack. The only differences >>>>> between the tree examples you have above is in implementation. >>>> >>>> >>>> I had to scroll up after reading this to make sure it was @adrian >>>> talking, because that seems like the opposite of what you were arguing= for. >>>> >>> >>> I don't think so. But I think that is part of the problem. We are not >>> all focused on the same thing. I am actually not very interested in CLP= at >>> all. It is one of potentially many protocols that may exist below the I= LP >>> layer. All we're doing by defining CLP is bootstrapping the network by >>> defining a protocol for everyone to use to get started. >>> >>> In designing the ILP layer properly we should try and forget everything >>> we know about the lower layers other than what features we require of t= hem. >>> >>> There is a misconception that ILP requires the lower layers to support >>> conditional transfers, that is not true. >>> >>> All we actually need from a lower layer protocol is to transfer data >>> back and forth and provide a way to reliably map requests to responses. >>> >>> What ILP provides lower layers is a way to reward your peer for passing >>> on the packet. The Internetworking layer defines a condition, a reward = that >>> must be paid to the receiver for the fulfillment and the time allowed t= o >>> claim this reward. >>> >>> Because of this, within lower-layer protocols that offer the basic >>> request/response features we need, we could add conditional payment >>> semantics that use the condition, expiry and fulfillment provided by IL= P. >>> This would allow a node to offer a reward to their next peer to for >>> delivering the packet they send them and to make the local financial >>> transaction contingent on the end-to-end transaction. >>> >>> But crucially, adding that semantic to the lower layer protocol provide= s >>> nothing extra to the ILP layer. The value is purely derived from the tw= o >>> peers who use that protocol and can now use conditional payments to pro= tect >>> themselves from their peers. >>> >>> >>>> The proposal that you're arguing for is basically asserting that we're >>>> going to be using CLP, because it makes the assumption that the connec= tors >>>> (who understand ILP) are managing the HTLA logic. >>>> >>> >>> Not at all. I am asserting that it doesn't matter what protocol you use >>> below the ILP layer because it shouldn't matter. All of this talk about= ILP >>> being different because money is more important than data is nonsense. >>> >>> The difference between ILP and IP that makes ILP suitable for value >>> transfer and IP not is at the internetworking layer. ILP requires that = all >>> packets are either a request or response and that the responses follow = the >>> same path as the requests. Further ILP defines a signature scheme that >>> gives the sender a way to be certain the request was received by the >>> receiver. >>> >>> *This could be done entirely without money* but then there would be >>> little incentive to sign the receipt or deliver the signature back to t= he >>> original sender. >>> >>> So, if you add money then you add economic incentives to the mix. At >>> each hop the sender promises the next upstream peer a payment if they c= an >>> return the receipt. The net effect is that this can be used to transfer >>> money from the sender to the receiver by simply defining up front the >>> amount that the receiver must get to produce the signature. >>> >>> >>>> >>>> In the current model, the CLP/trustline model and the direct ledger >>>> model both work without having to treat anything on the ILP layer >>>> differently. We're favoring on-ledger messaging because of our >>>> implementation, yes, but we've been able to switch most all of our plu= gins >>>> from on-ledger messaging to RPC-based messaging without changing the I= LP >>>> layer at all. >>>> >>>> With the ledger-level abstraction, we were able to switch from our >>>> ledger-based mode of thinking to the CLP/trustline based way without >>>> changing anything other than the plugin. Your argument comes from an >>>> assumption of a CLP-style ledger protocol with some underlying ledger, >>>> which we can't assume is always the case. >>>> >>> >>> I'm not sure what any of that proves tbh. These are all implementation >>> concerns. They don't change the fact that the condition, expiry and >>> fulfillment are part of ILP not the lower layer protocols. >>> >>>> >>>> >>>> From the perspective of the Interledger Protocol the implementation of >>>>> the lower layers is not important, that's the whole point of layering= . By >>>>> forcing important aspects of ILP like the condition, fulfillment and = expiry >>>>> down into those layers you muddy the waters and we now have to standa= rdize >>>>> those protocols too. Instead we should just be defining the functions= they >>>>> must provide and then leave it up to implementations to provide those >>>>> functions. >>>> >>>> >>>> I don't agree with this point; the condition and fulfillment have >>>> actual meaning to the ledger layer. >>>> >>> >>> NO THEY DON'T! They have meaning to SOME ledgers that implement SOME >>> lower layer protocols, IF they choose to use them. >>> >>> Excuse the shouting but this is the crux of the issue. We need to all >>> agree that it is entirely possible for a transfer to be done that doesn= 't >>> use the condition and fulfillment and that if this was in the middle of= a >>> 10-hop ILP payment it would have no effect on the sender and receiver. >>> >>>> >>>> You've said that the ledger often doesn't care about fulfillment and >>>> condition, but the ledger _layer_'s (where transfers are done) role is= to >>>> take in condition and fulfillment and make a transfer which satisfies = its >>>> HTLA. >>>> >>> >>> No, the ledger's role is to keep a tab of net financial positions >>> between two peers. It MAY use conditions and fulfillments that it pulls >>> from the ILP layer to help it do that in a way both peers agree on. >>> >>> Note that a "layer" doesn't have a role. I think there is some confusio= n >>> about the difference between layering the protocol and abstracting >>> functionality into different components. >>> >>> >>>> If the ledger layer has to look into the ILP packet to do so, that is = a >>>> blatant breaking of layering. >>>> >>> >>> Not at all! The module acting at the layers *below* the internetworking >>> layer shouldn't modify anything inside the packets of the higher layers= but >>> they can definitely inspect them and adjust their behavior based on wha= t >>> they to find. >>> >>> In fact the prevalence of this is the subject of a lot of debate at the >>> IETF currently because endpoints are often encrypting their payloads an= d in >>> some cases this makes it difficult for middle-boxes to be effective at >>> their jobs. >>> >>> By putting the condition, fulfillment, and expiry on the ledger layer, >>>> we leave it open for any ledger type to work, rather than forcing all >>>> ledger-layer software to understand ILP. >>>> >>> >>> Actually you do the opposite. You make it a requirement of every >>> protocol below the ILP layer to define a way to carry these data elemen= ts >>> and encode and decode them, even if they don't use them >>> >>> Ledger layer components don't have to understand ILP unless they choose >>> to re-use the condition for their own local transfer. Ledgers themselve= s >>> *never* have to understand ILP. >>> >>> Remember a ledger layer protocol could use a completely different >>> conditional payments scheme, like atomic mode ILP, where it takes the >>> end-to-end condition and creates a new compound condition that depends = on >>> the fulfillment and some notary signature. >>> >>> There will be a component in a connector's stack that must pass the ILP >>> packet to the next peer. If it does this using a transfer protocol that >>> uses conditional transfers and wants to use the same condition as the I= LP >>> packet then it must decode the packet. >>> >>> But, it will likely do something with that condition before sending the >>> transfer to the ledger like encoding it differently or rehashing it >>> (lightning?) so that it's in the form expected by the ledger. >>> >>> That's an implementation decision of the lower layer protocol used >>> between those two peers. >>> >>> >>>> >>>> I agree that Interledger defines how conditions, fulfillments, and >>>> expiries should be chained together, but it makes no assertions about = their >>>> data format. >>>> >>> >>> ILP doesn't define how anything is chained together. From the >>> perspective of ILP the condition and fulfillment are end-to-end data. T= hey >>> are agreed by the two endpoints who don't care how they get from Alice = to >>> Bob and back. >>> >>> The design of ILP is such that it facilitates the design of lower level >>> protocols that can be used to carry the ILP packets across multiple hop= s >>> (networks) using economic incentives such that the sender pays enough f= or >>> the first hop to ensure that all nodes in between can extract the fee t= hey >>> want and the receiver will still get the amount they expected.. >>> >>> >>> >>>> ILP says you should send your outgoing transfer with the same conditio= n >>>> as the incoming one, and a lower expiry. >>>> >>> >>> No it doesn't. An internetworking protocol can't prescribe that kind of >>> thing to lower level protocols. An incoming and outgoing transfer could= be >>> sent using completely different protocols and the financial agreement w= ith >>> the peers on those two routes could be vastly different too. >>> >>> The only service ILP requires of lower level protocols is that they can >>> map a response to an original request. This requirement is okay because= it >>> is isolated to a single route/link at a time not a requirement that cro= sses >>> the inter-network boundary that ILP crosses. >>> >>> >>>> But because ILP allows for many different types of ledgers, it doesn't >>>> make sense to assert how these are encoded. >>>> >>> >>> By putting them in the ILP packet you do the opposite. You make no >>> assertions about how they are encoded if they are used at lower layers,= or >>> how they may be combined with other conditions or even used to derive n= ew >>> conditions. >>> >>>> >>>> IP doesn't tell you how to encode an ethernet packet. It doesn't even >>>> know whether it's going over a computer or a hand-written letter carri= ed by >>>> a pigeon. IP takes for granted that you can send data over one connect= ion >>>> by putting it in a lower level. >>>> >>> >>> Correct, but if a link layer protocol wanted to look into the IP packet >>> headers of a packet it wants to transfer and use some data from there i= n >>> its internal logic (or even reuse data in it's own frame) that would be >>> totally fine. >>> >>> >>>> Even though IP tells you how to chain these connections together, it >>>> doesn't have to put the things it's chaining on the internetworking le= vel. >>>> >>> >>> IP doesn't tell you how to chain things together. IP simply defines the >>> end-to end data envelope and address space. Because of this nodes that >>> implement the multiple lower layer protocols are able to push IP packet= s >>> down a link and expect the node on the other side to understand the hea= ders >>> and route it onward on another link. >>> >>> Everything needed by the IP module to decide what to do with the packet >>> is in the IP packet headers. i.e. Has it exceeded a TTL? Is there a rou= te >>> for this destination? Is it corrupted (checksum fails)? But also, >>> everything that is needed by the endpoint (like the source address) is = also >>> in there. >>> >>> There is no dependency on nodes to be good citizens and always pass >>> certain other data from the lower layers into the next link. That would= be >>> breaking the layering. >>> >>> >>>> IP also assumes that if you get some incoming data on a connection you >>>> can copy it and send it out on the next connection. Because you can al= ready >>>> send data over a connection, all IP adds is the missing piece: a packe= t >>>> that tells you where to go. >>>> >>>> With ILP, we assume that there is a way to prepare a conditional >>>> transfer, expire a conditional transfer, and fulfill a conditional >>>> transfer. >>>> >>> >>> No we don't! We assume that if we deliver the packet as intended we'll >>> get back a response packet with a signature that matches the condition = in >>> the packet. So, if we have an agreement with someone that they will pay= us >>> when we present that signature then we are prepared to enter a similar >>> agreement with the next peer because we expect that signature to come a= ll >>> the way back along the interledger layer route.. >>> >>> >>>> We also assume that if you get an incoming transfer you can create an >>>> outgoing transfer with the same condition. The abstraction we made mea= ns >>>> that conditions and fulfillments are already carried in the lower leve= ls. >>>> >>> >>> That is a bad assumption that comes from the broken layering. What if m= y >>> outgoing link doesn't support conditional transfers? So now where do I = put >>> the condition? >>> >>>> >>>> >>>> We could have assumed that no ledgers ever support conditional >>>> transfers, and said the only thing ILP gets from lower levels is the >>>> ability to send a transfer. But if we want to support the case where a= ny of >>>> them do, we have to keep the conditions and fulfillments in the layer = where >>>> they're actually used. >>>> >>> >>> I don't follow that logic at all. If we want to support the case where >>> any of them do then we must ensure the condition and expiry are always >>> carried in a consistent place at the internetworking layer so that if t= hey >>> do want to use them they know where to find them. >>> >>> >>>> >>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>> adrian@hopebailie.com> wrote: >>>> >>>>> >>>>> >>>>> On 14 August 2017 at 22:03, Evan Schwartz wrote: >>>>> >>>>>> I think this thread is going to get extremely unwieldy but here goes= : >>>>>> >>>>>> > - All interledger layer messages should be ILP packets (including >>>>>> fulfillments) and be capable of carrying higher layer protocol paylo= ads. >>>>>> >>>>>> Interledger has higher requirements than ILP for the lowest layer, >>>>>> specifically because we are carrying money and not just data. One of= the >>>>>> requirements is being able to transmit a 32-byte fulfillment back al= ong the >>>>>> same path that carried the payment originally. If we expect this of = the >>>>>> lower layer, I don't see a point in putting the fulfillment into an = ILP >>>>>> packet and transmitting it as Interledger data along the same path. = All >>>>>> ledger-layer protocols will need to interpret the fulfillment passed= in >>>>>> their protocol, not the one passed through the Interledger layer. >>>>>> >>>>> >>>>> This is not correct. There is no requirement on ledger layer protocol= s >>>>> to transmit or understand the fulfillment. You are looking at this th= rough >>>>> the lens of existing implementations from the bottom up instead of st= arting >>>>> at the interledger layer. >>>>> >>>>> The primary function of the condition and fulfillment is as a signed >>>>> end-to-end receipt. If the sender agrees a condition with a receiver = and >>>>> then gets back the valid fulfillment they don't care what happened in= the >>>>> middle. The receiver has signed a receipt saying they have their mone= y. >>>>> >>>>> The value of using a standard for the receipt and signature is that >>>>> each transfer along the way CAN re-use it. One the one hand you can h= ave a >>>>> transfer between two peers that have zero trust and the ledger they u= se >>>>> supports conditional payments completely. On the other extreme you ca= n have >>>>> two peers that have a full trust and ignore the condition and fulfill= ment >>>>> completely. >>>>> >>>>> The ledger layer protocols carry ILP packets. Payment requests and >>>>> either fulfillment or error responses. If a ledger layer protocol wan= ts to >>>>> use the condition and fulfillment for their own operations they can e= xtract >>>>> these from the ILP packets and use them. >>>>> >>>>> >>>>>> > - While it may make sense to split the interledger payment and >>>>>> interledger quoting protocols into new higher level protocols that s= eems >>>>>> like an unnecessary abstraction. Instead the packet definitions shou= ld just >>>>>> have some consistency and probably a common base/header. >>>>>> >>>>>> The current protocols effectively have this header but it isn't >>>>>> separated out. There are two fields in the request header: type and >>>>>> destination address. There is one field in the response header: type= . I >>>>>> don't think it makes that much of a big difference to separate these= fields >>>>>> if all of the fields in that packet need to be interpreted together = (for >>>>>> example, you can't understand a quote request if you strip off the >>>>>> destination address). >>>>>> >>>>> >>>>> I agree that we don't HAVE to explicitly separate them out but I thin= k >>>>> ti would make it clearer how the stack is architected if there was a = header >>>>> that was consistent across all packets. Currently the only thing that= is >>>>> consitent across all ILP packets is that they are defined int he same= file. >>>>> >>>>> >>>>>> >>>>>> > - We should define two base ILP packet types: request and response= . >>>>>> >>>>>> Unless this adds some substantive benefit or new fields I don't thin= k >>>>>> it's worth breaking all of the formats we have just to rearrange thi= ngs. >>>>>> >>>>> >>>>> The goal of this exercise is to tease out the best design and ignore >>>>> the cost of change until we can compare the results with the current = design. >>>>> >>>>> >>>>>> >>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>> nodes/hosts. >>>>>> >>>>>> A ledger is any system that tracks accounts and balances. When you >>>>>> use a trustline all of your messages still need to go through an acc= ounting >>>>>> system (such as the plugin in the JS implementation) and then on to = the >>>>>> other program logic. >>>>>> >>>>> >>>>> As above, this is incorrect. There is no requirement for "all message= s >>>>> to go through an accounting system". >>>>> >>>>> Since designing the first implementation of 5-bells ledger we have >>>>> assumed that passing the ILP packet MUST be done by the ledger becaus= e that >>>>> is how we implemented it. But that is not true. It is perfectly valid= for >>>>> the passing of an ILP packet from one peer to another to be simply an >>>>> exchange of data. >>>>> >>>>> The receiving peer makes a decision about whether or not to forward >>>>> the packet based on the current financial position they have with the >>>>> sending peer. >>>>> >>>>> It is convenient if the ledger that records the net positions of the >>>>> peers also forwards the messaging and even better if it natively supp= orts >>>>> conditional payments and can use the condition and the fulfillment fr= om the >>>>> ILP packet for those but that's all it is, convenient. >>>>> >>>>> >>>>> >>>>>> In that case, the plugin or whatever is doing the accounting is the >>>>>> ledger. Digital value is always tracked in ledgers, so I think it do= es make >>>>>> sense to think of this as the base layer. The reason to abstract the >>>>>> functionality you expect from the ledger layer is precisely so you c= an >>>>>> handle it in different ways, depending on what the underlying system= s >>>>>> provide. >>>>>> >>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>> >>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>> some type of HTLA >>>>>> >>>>>> 2. There are separate plugins for messaging and for transfers and >>>>>> when you peer with someone you have to agree on a plugin for each >>>>>> 3. We standardize the messaging part and say that all goes over >>>>>> IP and then just have more minimal plugins for the on-ledger sett= lements >>>>>> >>>>>> Number 1 is what we have and I think that still makes the most sense= . >>>>>> >>>>> >>>>> I think you're confusing implementation details and defining of >>>>> interfaces with definition of a protocol stack. The only differences >>>>> between the tree examples you have above is in implementation. >>>>> >>>>> From the perspective of the Interledger Protocol the implementation o= f >>>>> the lower layers is not important, that's the whole point of layering= . By >>>>> forcing important aspects of ILP like the condition, fulfillment and = expiry >>>>> down into those layers you muddy the waters and we now have to standa= rdize >>>>> those protocols too. Instead we should just be defining the functions= they >>>>> must provide and then leave it up to implementations to provide those >>>>> functions. >>>>> >>>>> I know we want to define a standard to bootstrap the system (CLP) but >>>>> that's misleading us into thinking it's an essential part of the stac= k. >>>>> It's perfectly valid for two peers to not use CLP and still be part o= f the >>>>> Interledger. >>>>> >>>>> That said, you raise an interesting consideration about the layers >>>>> below ILP and actually I think it makes sense to split these. >>>>> >>>>> We keep trying to force messaging through the ledger layer and >>>>> actually that's the wrong place to put it if we can split the ledger = layer >>>>> into a messaging layer and a ledger layer. That way we can stop tryin= g to >>>>> think of all HLTAs as ledgers. >>>>> >>>>> A thought, why not use sub-layers as is common in other stacks: >>>>> >>>>> 1. Link layer: Layer upon which two peers that have a direct link, or >>>>> participate in the same payment network, communicate >>>>> 2. Transfer/ ledger: Layer on which financial positions between two >>>>> peers are recorded >>>>> >>>>> This reflects the already emerging HTLA model and many of our existin= g >>>>> plugins and ledger integrations. >>>>> Link Layer: XRP Paychan, Lightning >>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>> >>>>> This doesn't prevent us from defining a standard binary protocol that >>>>> defines all of the operations for both layers (like CLP) but I see va= lue in >>>>> distinguishing between these two. >>>>> >>>>> >>>>>> >>>>>> > - The protocol should differentiate between the operation of >>>>>> preparing a transfer on a ledger and the operation of passing an ILP= packet >>>>>> from one peer to another. >>>>>> >>>>>> The protocol assumes your conditional transfer is underpinned by som= e >>>>>> HTLA >>>>>> . >>>>>> It doesn't care whether that's on-ledger or not. >>>>>> >>>>> >>>>> What do you mean when you say "the protocol"? In my statement I am >>>>> referring to ILP. >>>>> My point above being that ILP expects ILP packets to be passed from >>>>> peer to peer but has no expectations about transfers. >>>>> >>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>> exchange ILP packets with no transfers. Clearly if a node routes a pa= cket >>>>> on and has no incoming transfer it's going to lose money but that's a >>>>> consideration for that node. It doesn't affect anyone else in the cha= in. >>>>> >>>>> ILP doesn't assume anything about transfers at all, let alone >>>>> conditional transfers. It provides useful semantics for conditional >>>>> transfers to be used by two peers to transact as part of a larger ILP >>>>> payment. >>>>> >>>>> >>>>>> >>>>>> > - The condition and timeout should be included in the ILP payment >>>>>> packet. >>>>>> >>>>>> I strongly disagree with this. We had this debate a year ago and I >>>>>> was on your side but was convinced that this is not a good idea. >>>>>> >>>>> >>>>> Yes, I recall this and I'm sorry I didn't push harder on this point. >>>>> Unfortunately I think the decision to pull it out of the packet is mo= stly >>>>> driven by how our prototypes were implemented rather than good archit= ecture. >>>>> >>>>>> >>>>>> The layer below ILP must be capable of doing conditional transfers >>>>>> based on sha256 hashlocks with 32-byte preimages. >>>>>> >>>>> >>>>> This is not true and I think it would be useful for us to agree on >>>>> this as this seems to be the argument I am coming up against most oft= en. >>>>> The peers participating in a transfer that is part of an ILP payment = may >>>>> wish to use conditional transfers as a way to enforce their agreement= but >>>>> this is not a requirement of the protocol. >>>>> >>>>> The agreement between any two peers is: "I will pay you X if you can >>>>> provide a receipt that Y was paid Z before T". >>>>> ILP provides a standard for expressing this agreement so that these >>>>> can be chained together BUT it is not a requirement that every agreem= ent in >>>>> the chain uses the condition, and fulfillment provided at the ILP lay= er. >>>>> >>>>> >>>>>> >>>>>> As a result, the original condition and the corresponding preimage >>>>>> MUST be expressed in that layer. >>>>>> >>>>> >>>>> As I have shown above, this is not true. >>>>> >>>>> >>>>>> Then the question is whether we should also include it in the packet >>>>>> that is forwarded. What ultimately convinced me is the following: Al= l >>>>>> connectors MUST ignore the condition if it is in the packet, because= they >>>>>> are only guaranteed their money back if they use the same condition = from >>>>>> the incoming transfer they got. >>>>>> >>>>> >>>>> Here is where the layering is being corrupted. >>>>> >>>>> All connectors MUST inspect the condition in the ILP packet as part o= f >>>>> their decision to route the packet or not. >>>>> When the local transfer module of the connectors stack passes the ILP >>>>> packet up to the ILP module it should indicate the properties of the >>>>> incoming transfer that carried the packet. >>>>> This is essential firstly so that the routing logic in the ILP module >>>>> can record the incoming transfer identifier so it is able to use the >>>>> correct response id when it passes back the fulfillment or error. >>>>> The other properties that the ILP module should look at are the >>>>> condition and expiry on the incoming transfer. >>>>> >>>>> If the incoming route uses conditional transfers and these are >>>>> supposed to match the condition and expiry in the ILP packet then the= ILP >>>>> module should compare them and reject the packet if: >>>>> a) the conditions don't match OR >>>>> b) the expiry is too short >>>>> >>>>> We should still discuss if the expiry should be set by the sender and >>>>> left unchanged or used like a TTL and decremented by each node. >>>>> >>>>> >>>>>> Also, the receiver will need to take out the condition in order to >>>>>> hash the packet for PSK or IPR. >>>>>> >>>>> >>>>> This is completely normal. Zeroing a checksum field in a header befor= e >>>>> calculating the checksum is VERY common precisely because it's long b= een >>>>> accepted that the right place to put that data is in the headers and = the >>>>> work of zero'ing it out to calculate the checksum (or signature in ou= r >>>>> case) is not material. >>>>> >>>>> >>>>>> So basically, no one wants the condition in there. It feels like it >>>>>> ought to be in there, but literally none of the parties want the ext= ra 32 >>>>>> bytes in there. >>>>>> >>>>> >>>>> "Nobody wants it there" is a terrible reason to abandon the correct >>>>> design. The whole purpose of a good architecture is you accept that t= here >>>>> may be cases in future that haven't been considered now so designing = just >>>>> for the known cases is a bad idea. >>>>> >>>>> Good architecture is not the same as optimization. Taking stuff out >>>>> (even when it feels wrong) to save a few bytes is a good sign that it= 's a >>>>> bad idea. >>>>> >>>>> >>>>>> >>>>>> The reason the timeout should not be in there is that there isn't a >>>>>> single timeout for the payment. There are multiple separate timeouts= for >>>>>> each of the bilateral transfers. Those must go in the individual tra= nsfers >>>>>> and there is no sensible value to put in the Interledger packet. >>>>>> >>>>> >>>>> As above, this is somewhat equivalent to the TTL in an IP packet. I'm >>>>> open to discussing if it should be a fixed value set by the sender wh= ere >>>>> each node uses their own value but has the sender-defined value as a >>>>> reference or it is actually decremented at each hop. >>>>> >>>>> Either way, this is part of ILP not the ledger layer just like the >>>>> condition and fulfillment. It may be used by the ledger layer but tha= t's >>>>> implementation specific. It belongs in the ILP packet. >>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> -- > Sent from a mobile device, please excuse any typos > --001a11442d84d2cd5f0556db707e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    OK, I think in that case = we're mostly disagreeing over where the condition/fulfillment/expiry ac= tually go in the data. The reason I don't agree with your position is b= ased on which parties I think should be aware of ILP. I'll hold off on = arguments about which current implementations this would break.

    There = are a lot of cases where the ledger isn't going to care about the condi= tion and fulfillment of an individual interledger payment. In this situatio= n, transfers would be sent directly between two connectors. The connectors = would still keep track of the balance between them (you could contrive a si= tuation where this doesn't happen, but I think we can say tracking the = balance is going to be the norm). In order to track the balance between eac= h other accurately, the two connectors have to keep track of conditions, fu= lfillments, and expiries on each of the transfers. That means the connector= s' accounting logic that handles the conditions, fulfillments, and expi= ries is going to be using some information inside the ILP packet and some i= nformation outside of it in order to perform these transfers.

    I think i= t's cleaner to say everything required to make these local transfers sh= ould go in one protocol, so the accounting logic of these connectors doesn&= #39;t have to deal with ILP directly. Then the connectors' ILP-packet-r= elated behavior can all be routing related. This would add a few benefits; = two connectors could perform non-ILP conditional transfers between one anot= her (which would be useful for reconciliation and settlement), and could al= so allow two connectors to use more complex condition types (i.e. signature= s for atomic mode) without forcing us to support that in the ILP packet. It= also keeps the integrity of the ILP packet as something lower levels don&#= 39;t modify; the connector has to modify the expiry in order to pass along = an ILP payment (they may not modify the expiry if they're using somethi= ng like atomic mode, but then we have the issue with advanced condition typ= es not being supported in the ILP packet).

    In the case where the ledger= _does_ care about the condition and fulfillment, the argument in favor of = separating condition/fulfillment/expiry from the rest of the packet is simi= lar. Because we don't control the features of all ledgers, we'll ne= ed our plugins or ledger adapters to be aware of ILP. This makes it hard to= interact with any events that don't involve ILP packets, and impossibl= e to handle features that extend beyond what we support in the ILP packet. = We could pass details about non-ILP ledger features (like a crypto conditio= n) in the side data, but in the event of any redundancy we have to check th= e ledger-supplied info, not the info in the ILP packet.

    Basically, cond= ition/fulfillment/expiry are used for accounting local transfers (even if t= hey aren't being "ledger" enforced) in addition to their role= as every-hop information. By putting them in the ILP packet, we limit the = special features that ledgers can support and make our software abstraction= s harder to separate cleanly. By putting them in the local transfer alongsi= de the ILP packet but not inside it, we do separate the data a little more,= but we have more freedom in what the underlying accounting and ledger logi= c can do, and our software modules will have more clearly separated domains= .

    On T= ue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie <adrian@hopebailie.co= m> wrote:
    Exactly =F0=9F=91=8D

    On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian <sharafian@ripple.com= > wrote:
    Ok, I think I have= a better idea of what you're saying.

    It sounds like= you're saying the ILP layer contains all information that is common be= tween every hop (destination, destination amount, opaque data, condition, f= ulfillment, expiry). The lower level would then be used for all the transfe= r-local details (source amount, next connector account, custom/local data).=

    If the lower level wanted to do anything related = to the every-hop payment, i.e. escrow funds until the receipt has been prod= uced, it would look into the ILP layer for that information. If the lower l= evel didn't do any escrow or expiries that require every-hop details, i= t would simply function as a communication method.

    Is that right?

    On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie <adrian@hopebailie.c= om> wrote:


    On 15 August 2017 = at 16:00, Ben Sharafian <sharafian@ripple.com> wrote:
    In that case, the plu= gin or whatever is doing the accounting is the ledger. Digital value is alw= ays tracked in ledgers, so I think it does make sense to think of this as t= he base layer. The reason to abstract the functionality you expect from the= ledger layer is precisely so you can handle it in different ways, dependin= g on what the underlying systems provide.
    I see 3 ways to think= of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messaging capabilitie= s and some type of=C2=A0HTLA
    1. There are separate plugins for messaging and for transfers and when you= peer with someone you have to agree on a plugin for each
    1. We standardize the messaging part and say that a= ll goes over IP and then just have more minimal plugins for the on-ledger s= ettlements
    Number 1 is what we have and I think that still makes t= he most sense.

    I think y= ou're confusing implementation details and defining of interfaces with = definition of a protocol stack. The only differences between the tree examp= les you have above is in implementation.

    =
    I had to scroll up after reading this to make sure it was @adri= an talking, because that seems like the opposite of what you were arguing f= or.

    I don't think s= o. But I think that is part of the problem. We are not all focused on the s= ame thing. I am actually not very interested in CLP at all. It is one of po= tentially many protocols that may exist below the ILP layer. All we're = doing by defining CLP is bootstrapping the network by defining a protocol f= or everyone to use to get started.

    In designing the ILP l= ayer properly we should try and forget everything we know about the lower l= ayers other than what features we require of them.

    There = is a misconception that ILP requires the lower layers to support conditiona= l transfers, that is not true.

    All we actually need from = a lower layer protocol is to transfer data back and forth and provide a way= to reliably map requests to responses.

    What ILP provides= lower layers is a way to reward your peer for passing on the packet. The I= nternetworking layer defines a condition, a reward that must be paid to the= receiver for the fulfillment and the time allowed to claim this reward.

    Because of this, within lower-layer protocols th= at offer the basic request/response features we need, we could add conditio= nal payment semantics that use the condition, expiry and fulfillment provid= ed by ILP. This would allow a node to offer a reward to=C2=A0 their next pe= er to for delivering the packet they send them and to make the local financ= ial transaction contingent on the end-to-end transaction.

    But crucially, adding that semantic to the lower layer protocol provides n= othing extra to the ILP layer. The value is purely derived from the two pee= rs who use that protocol and can now use conditional payments to protect th= emselves from their peers.
    =C2=A0
    The proposal that you're ar= guing for is basically asserting that we're going to be using CLP, beca= use it makes the assumption that the connectors (who understand ILP) are ma= naging the HTLA logic.

    N= ot at all. I am asserting that it doesn't matter what protocol you use = below the ILP layer because it shouldn't matter. All of this talk about= ILP being different because money is more important than data is nonsense.=

    The difference between ILP and IP that makes ILP suitable for= value transfer and IP not is at the internetworking layer. ILP requires th= at all packets are either a request or response and that the responses foll= ow the same path as the requests. Further ILP defines a signature scheme th= at gives the sender a way to be certain the request was received by the rec= eiver.

    This could be done entire= ly without money but then there would be little incentive to sign the r= eceipt or deliver the signature back to the original sender.

    <= div class=3D"gmail_quote">So, if you add money then you add economic incent= ives to the mix. At each hop the sender promises the next upstream peer a p= ayment if they can return the receipt. The net effect is that this can be u= sed to transfer money from the sender to the receiver by simply defining up= front the amount that the receiver must get to produce the signature.
    <= /div>
    =C2=A0
    =

    In the current model, the CLP/trustline model and the direct ledger m= odel both work without having to treat anything on the ILP layer differentl= y. We're favoring on-ledger messaging because of our implementation, ye= s, but we've been able to switch most all of our plugins from on-ledger= messaging to RPC-based messaging without changing the ILP layer at all.

    With the ledger-level abstraction, we were able to s= witch from our ledger-based mode of thinking to the CLP/trustline based way= without changing anything other than the plugin. Your argument comes from = an assumption of a CLP-style ledger protocol with some underlying ledger, w= hich we can't assume is always the case.
    <= br>
    I'm not sure what any of that proves tbh. These are all= implementation concerns. They don't change the fact that the condition= , expiry and fulfillment are part of ILP not the lower layer protocols.
    =C2=A0

    From the persp= ective of the Interledger Protocol the implementation of the lower layers i= s not important, that's the whole point of layering. By forcing importa= nt aspects of ILP like the condition, fulfillment and expiry down into thos= e layers you muddy the waters and we now have to standardize those protocol= s too. Instead we should just be defining the functions they must provide a= nd then leave it up to implementations to provide those functions.

    I don't agree with this point; th= e condition and fulfillment have actual meaning to the ledger layer.
    =

    NO THEY DON'T! They have = meaning to SOME ledgers that implement SOME lower layer protocols, IF they = choose to use them.

    Excuse the shouting but this is the c= rux of the issue. We need to all agree that it is entirely possible for a t= ransfer to be done that doesn't use the condition and fulfillment and t= hat if this was in the middle of a 10-hop ILP payment it would have no effe= ct on the sender and receiver.
    =C2=A0
    You've said that the ledger often = doesn't care about fulfillment and condition, but the ledger _layer_= 9;s (where transfers are done) role is to take in condition and fulfillment= and make a transfer which satisfies its HTLA.

    No, the ledger's role is to keep a tab of net financ= ial positions between two peers. It MAY use conditions and fulfillments tha= t it pulls from the ILP layer to help it do that in a way both peers agree = on.

    Note that a "layer" d= oesn't have a role. I think there is some confusion about the differenc= e between layering the protocol and abstracting functionality into differen= t components.
    =C2=A0
    <= div>
    If the ledger layer has to look into the ILP packet to do so, that= is a blatant breaking of layering.

    Not at all! The module acting at the layers below the i= nternetworking layer shouldn't modify anything inside the packets of th= e higher layers but they can definitely inspect them and adjust their behav= ior based on what they to find.

    In fact the prevalence of this= is the subject of a lot of debate at the IETF currently because endpoints = are often encrypting their payloads and in some cases this makes it difficu= lt for middle-boxes to be effective at their jobs.

    By putting the condition, fulfillment, and expiry on the ledger lay= er, we leave it open for any ledger type to work, rather than forcing all l= edger-layer software to understand ILP.

    Actually you do the opposite. You make it a requirement of = every protocol below the ILP layer to define a way to carry these data elem= ents and encode and decode them, even if they don't use them

    Ledger layer components don't have to understand ILP unless the= y choose to re-use the condition for their own local transfer. Ledgers them= selves never have to understand ILP.

    Remember a ledger layer= protocol could use a completely different conditional payments scheme, lik= e atomic mode ILP, where it takes the end-to-end condition and creates a ne= w compound condition that depends on the fulfillment and some notary signat= ure.

    There will be a component in a connector's stack= that must pass the ILP packet to the next peer. If it does this using a tr= ansfer protocol that uses conditional transfers and wants to use the same c= ondition as the ILP packet then it must decode the packet.

    But, it will likely do something with that condition before sending the t= ransfer to the ledger like encoding it differently or rehashing it (lightni= ng?) so that it's in the form expected by the ledger.
    That's an implementation decision of the lower layer protoc= ol used between those two peers.
    =C2=A0

    I agree th= at Interledger defines how conditions, fulfillments, and expiries should be= chained together, but it makes no assertions about their data format.

    ILP doesn't define how = anything is chained together. From the perspective of ILP the condition and= fulfillment are end-to-end data. They are agreed by the two endpoints who = don't care how they get from Alice to Bob and back.

    T= he design of ILP is such that it facilitates the design of lower level prot= ocols that can be used to carry the ILP packets across multiple hops (netwo= rks) using economic incentives such that the sender pays enough for the fir= st hop to ensure that all nodes in between can extract the fee they want an= d the receiver will still get the amount they expected..

    =C2=A0
    ILP says you should send your outgoing transfer with the same condition = as the incoming one, and a lower expiry.

    =
    No it doesn't. An internetworking protocol can't = prescribe that kind of thing to lower level protocols. An incoming and outg= oing transfer could be sent using completely different protocols and the fi= nancial agreement with the peers on those two routes could be vastly differ= ent too.

    The only service ILP requires of lower level protocols is t= hat they can map a response to an original request. This requirement is oka= y because it is isolated to a single route/link at a time not a requirement= that crosses the inter-network boundary that ILP crosses.
    <= div>=C2=A0
    But because ILP allows for many different types of ledgers, it doesn't= make sense to assert how these are encoded.
    <= br>
    By putting them in the ILP packet you do the opposite.= You make no assertions about how they are encoded if they are used at lowe= r layers, or how they may be combined with other conditions or even used to= derive new conditions.

    IP doesn't tell you how to encod= e an ethernet packet. It doesn't even know whether it's going over = a computer or a hand-written letter carried by a pigeon. IP takes for grant= ed that you can send data over one connection by putting it in a lower leve= l.

    Correct, but if a li= nk layer protocol wanted to look into the IP packet headers of a packet it = wants to transfer and use some data from there in its internal logic (or ev= en reuse data in it's own frame) that would be totally fine.
    <= span>
    =C2=A0
    Even though IP tells you how to chain these connections together, it= doesn't have to put the things it's chaining on the internetworkin= g level.

    IP doesn't= tell you how to chain things together. IP simply defines the end-to end da= ta envelope and address space. Because of this nodes that implement the mul= tiple lower layer protocols are able to push IP packets down a link and exp= ect the node on the other side to understand the headers and route it onwar= d on another link.

    Everything needed by the IP module to = decide what to do with the packet is in the IP packet headers. i.e. Has it = exceeded a TTL? Is there a route for this destination? Is it corrupted (che= cksum fails)? But also, everything that is needed by the endpoint (like the= source address) is also in there.

    There is no dependency= on nodes to be good citizens and always pass certain other data from the l= ower layers into the next link. That would be breaking the layering.
    =C2=A0
    IP also assumes that if you get some incoming data on a connecti= on you can copy it and send it out on the next connection. Because you can = already send data over a connection, all IP adds is the missing piece: a pa= cket that tells you where to go.

    With ILP, we assu= me that there is a way to prepare a conditional transfer, expire a conditio= nal transfer, and fulfill a conditional transfer.
    =

    No we don't! We assume that if we deliver th= e packet as intended we'll get back a response packet with a signature = that matches the condition in the packet. So, if we have an agreement with = someone that they will pay us when we present that signature then we are pr= epared to enter a similar agreement with the next peer because we expect th= at signature to come all the way back along the interledger layer route..
    =C2=A0
    We also assume that if you get an incoming transfer you can= create an outgoing transfer with the same condition. The abstraction we ma= de means that conditions and fulfillments are already carried in the lower = levels.

    That is a bad as= sumption that comes from the broken layering. What if my outgoing link does= n't support conditional transfers? So now where do I put the condition?=
    =C2=A0

    We could have assumed that no ledgers ever support co= nditional transfers, and said the only thing ILP gets from lower levels is = the ability to send a transfer. But if we want to support the case where an= y of them do, we have to keep the conditions and fulfillments in the layer = where they're actually used.

    I don't follow that logic at all. If we want to support the ca= se where any of them do then we must ensure the condition and expiry are al= ways carried in a consistent place at the internetworking layer so that if = they do want to use them they know where to find them.
    =C2=A0

    On Tue, Aug 15= , 2017 at 12:04 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote= :


    On 14 August 2017 at = 22:03, Evan Schwartz <evan@ripple.com> wrote:
    I think this thread is going to get extremely= unwieldy but here goes:

    >=C2=A0- All interledger layer messages should be ILP packets= (including fulfillments) and be capable of carrying higher layer protocol = payloads.

    Interledger has higher req= uirements than ILP for the lowest layer, specifically because we are carryi= ng money and not just data. One of the requirements is being able to transm= it a 32-byte fulfillment back along the same path that carried the payment = originally. If we expect this of the lower layer, I don't see a point i= n putting the fulfillment into an ILP packet and transmitting it as Interle= dger data along the same path. All ledger-layer protocols will need to inte= rpret the fulfillment passed in their protocol, not the one passed through = the Interledger layer.

    This i= s not correct. There is no requirement on ledger layer protocols to transmi= t or understand the fulfillment. You are looking at this through the lens o= f existing implementations from the bottom up instead of starting at the in= terledger layer.

    The primary funct= ion of the condition and fulfillment is as a signed end-to-end receipt. If = the sender agrees a condition with a receiver and then gets back the valid = fulfillment they don't care what happened in the middle. The receiver h= as signed a receipt saying they have their money.

    The value of using a standard for the receipt and signatur= e is that each transfer along the way CAN re-use it. One the one hand you c= an have a transfer between two peers that have zero trust and the ledger th= ey use supports conditional payments completely. On the other extreme you c= an have two peers that have a full trust and ignore the condition and fulfi= llment completely.
    =C2=A0
    The = ledger layer protocols carry ILP packets. Payment requests and either fulfi= llment or error responses. If a ledger layer protocol wants to use the cond= ition and fulfillment for their own operations they can extract these from = the ILP packets and use them.


    >=C2=A0- While it may make sense to split the interledger payment and interle= dger quoting protocols into new higher level protocols that seems like an u= nnecessary abstraction. Instead the packet definitions should just have som= e consistency and probably a common base/header.

    The current protocols effectively have this header but it = isn't separated out. There are two fields in the request header: type a= nd destination address. There is one field in the response header: type. I = don't think it makes that much of a big difference to separate these fi= elds if all of the fields in that packet need to be interpreted together (f= or example, you can't understand a quote request if you strip off the d= estination address).

    <= div>I agree that we don't HAVE to explicitly separate them out but I th= ink ti would make it clearer how the stack is architected if there was a he= ader that was consistent across all packets. Currently the only thing that = is consitent across all ILP packets is that they are defined int he same fi= le.
    =C2=A0

    <= /div>
    >=C2=A0- We should define two base ILP packet types: requ= est and response.

    Unless this adds some substantive benefit or new fields I don't thin= k it's worth breaking all of the formats we have just to rearrange thin= gs.

    The goal of this exe= rcise is to tease out the best design and ignore the cost of change until w= e can compare the results with the current design.
    =C2= =A0
    =
    >=C2=A0- ILP is not a= bout ledgers, it is about trustlines between nodes/hosts.

    A ledger is any system that tracks= accounts and balances. When you use a trustline all of your messages still= need to go through an accounting system (such as the plugin in the JS impl= ementation) and then on to the other program logic.

    As above, this is incorrect. There is no requi= rement for "all messages to go through an accounting system".
    =
    Since designing the first implementation of 5-bells ledger w= e have assumed that passing the ILP packet MUST be done by the ledger becau= se that is how we implemented it. But that is not true. It is perfectly val= id for the passing of an ILP packet from one peer to another to be simply a= n exchange of data.

    The receiving peer makes a decision a= bout whether or not to forward the packet based on the current financial po= sition they have with the sending peer.

    It is = convenient if the ledger that records the net positions of the peers also f= orwards the messaging and even better if it natively supports conditional p= ayments and can use the condition and the fulfillment from the ILP packet f= or those but that's all it is, convenient.

    =C2= =A0
    In tha= t case, the plugin or whatever is doing the accounting is the ledger. Digit= al value is always tracked in ledgers, so I think it does make sense to thi= nk of this as the base layer. The reason to abstract the functionality you = expect from the ledger layer is precisely so you can handle it in different= ways, depending on what the underlying systems provide.

    I see 3 ways to think of the layer(s) underpinning ILP:
  • The "Ledger Layer" provides both messaging= capabilities and some type of HTLA
  • There are separate plugin= s for messaging and for transfers and when you peer with someone you have t= o agree on a plugin for each
  • We standardize the messaging part and = say that all goes over IP and then just have more minimal plugins for the o= n-ledger settlements
    • Number 1 is what we have and I think tha= t still makes the most sense.

    I th= ink you're confusing implementation details and defining of interfaces = with definition of a protocol stack. The only differences between the tree = examples you have above is in implementation.

    From the perspective o= f the Interledger Protocol the implementation of the lower layers is not im= portant, that's the whole point of layering. By forcing important aspec= ts of ILP like the condition, fulfillment and expiry down into those layers= you muddy the waters and we now have to standardize those protocols too. I= nstead we should just be defining the functions they must provide and then = leave it up to implementations to provide those functions.

    I know we want to define a standard to bootstrap th= e system (CLP) but that's misleading us into thinking it's an essen= tial part of the stack. It's perfectly valid for two peers to not use C= LP and still be part of the Interledger.

    That said, you raise an interes= ting consideration about the layers below ILP and actually I think it makes= sense to split these.

    We keep trying to force messaging = through the ledger layer and actually that's the wrong place to put it = if we can split the ledger layer into a messaging layer and a ledger layer.= That way we can stop trying to think of all HLTAs as ledgers.

    A thought, why not use sub-layers as is common in other stacks:
    1. Link layer: Layer upon which two peers that have a direct l= ink, or participate in the same payment network, communicate
    = 2. Transfer/ ledger: Layer on which financial positions between two peers a= re recorded

    This reflects the already emerging HTLA model and many o= f our existing plugins and ledger integrations.
    Link Layer: X= RP Paychan, Lightning
    Ledger Layer: XRP Ledger, Bitcoin

    This doesn't prevent us from defining a standar= d binary protocol that defines all of the operations for both layers (like = CLP) but I see value in distinguishing between these two.
    =C2=A0

    >=C2=A0- The pr= otocol should differentiate between the operation of preparing a transfer o= n a ledger and the operation of passing an ILP packet from one peer to anot= her.

    The protocol= assumes your conditional transfer is underpinned by some HTLA. It doesn'= ;t care whether that's on-ledger or not.
    <= br>
    What do you mean when you say "the protocol"? In = my statement I am referring to ILP.
    My point above being that ILP expec= ts ILP packets to be passed from peer to peer but has no expectations about= transfers.

    It's perfectly lega= l (from an ILP perspective) for two peers to exchange ILP packets with no t= ransfers. Clearly if a node routes a packet on and has no incoming transfer= it's going to lose money but that's a consideration for that node.= It doesn't affect anyone else in the chain.

    ILP doesn't assume anything about transfers at all, let a= lone conditional transfers. It provides useful semantics for conditional tr= ansfers to be used by two peers to transact as part of a larger ILP payment= .
    =C2=A0

    >=C2=A0- The condition and timeout should be includ= ed in the ILP payment packet.

    I stro= ngly disagree with this. We had this debate a year ago and I was on your si= de but was convinced that this is not a good idea.
    =

    Yes, I recall this and I'm sorry I didn'= t push harder on this point. Unfortunately I think the decision to pull it = out of the packet is mostly driven by how our prototypes were implemented r= ather than good architecture.

    The layer below ILP must be ca= pable of doing conditional transfers based on sha256 hashlocks with 32-byte= preimages.

    This is not= true and I think it would be useful for us to agree on this as this seems = to be the argument I am coming up against most often. The peers participati= ng in a transfer that is part of an ILP payment may wish to use conditional= transfers as a way to enforce their agreement but this is not a requiremen= t of the protocol.

    The agreement between any two peers is= : "I will pay you X if you can provide a receipt that Y was paid Z bef= ore T".
    ILP provides a standard for expressing this agre= ement so that these can be chained together BUT it is not a requirement tha= t every agreement in the chain uses the condition, and fulfillment provided= at the ILP layer.

    =C2=A0
    As a result, the original condition and the co= rresponding preimage MUST be expressed in that layer.

    As I have shown above, this is not true.
    =
    =C2=A0
    Then the question is whether we should also include it in the= packet that is forwarded. What ultimately convinced me is the following: A= ll connectors MUST ignore the condition if it is in the packet, because the= y are only guaranteed their money back if they use the same condition from = the incoming transfer they got.

    Here is where the layering is being corrupte= d.

    All connectors MUST inspect the condition in the ILP packet as pa= rt of their decision to route the packet or not.
    When the local transfer module of the connectors stack passes the= ILP packet up to the ILP module it should indicate the properties of the i= ncoming transfer that carried the packet.
    This is essential firstly so that the routing logic in the ILP module ca= n record the incoming transfer identifier so it is able to use the correct = response id when it passes back the fulfillment or error.
    The other prop= erties that the ILP module should look at are the condition and expiry on t= he incoming transfer.

    If the incoming route uses conditional transfers and these are supposed = to match the condition and expiry in the ILP packet then the ILP module sho= uld compare them and reject the packet if:
    a) the conditions = don't match OR
    b) the expiry is too short

    We should still discuss if the expiry should be set by the sender and le= ft unchanged or used like a TTL and decremented by each node.
    =C2=A0
    <= div>Also, the receiver will need to take out the condition in order to hash= the packet for PSK or IPR.

    =
    This is completely normal. Zeroing a checksum field in a header before= calculating the checksum is VERY common precisely because it's long be= en accepted that the right place to put that data is in the headers and the= work of zero'ing it out to calculate the checksum (or signature in our= case) is not material.
    =C2=A0
    So basically, no one wants the c= ondition in there. It feels like it ought to be in there, but literally non= e of the parties want the extra 32 bytes in there.
    =

    "Nobody wants it there" is a terrible = reason to abandon the correct design. The whole purpose of a good architect= ure is you accept that there may be cases in future that haven't been c= onsidered now so designing just for the known cases is a bad idea.

    <= /div>
    Good architecture is not the same as optimization. Taking stuff o= ut (even when it feels wrong) to save a few bytes is a good sign that it= 9;s a bad idea.
    =C2=A0

    The reason the timeout shou= ld not be in there is that there isn't a single timeout for the payment= . There are multiple separate timeouts for each of the bilateral transfers.= Those must go in the individual transfers and there is no sensible value t= o put in the Interledger packet.
    =C2=A0
    <= /span>
    As above, this is somewhat equivalent to the TTL in an IP packet= . I'm open to discussing if it should be a fixed value set by the sende= r where each node uses their own value but has the sender-defined value as = a reference or it is actually decremented at each hop.

    Ei= ther way, this is part of ILP not the ledger layer just like the condition = and fulfillment. It may be used by the ledger layer but that's implemen= tation specific. It belongs in the ILP packet.
    =C2=A0





    --
    Sent from a mobile devi= ce, please excuse any typos

    --001a11442d84d2cd5f0556db707e-- From nobody Thu Aug 17 10:32:56 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDE51323F7 for ; Thu, 17 Aug 2017 10:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 7CzfWJ1V1Sih for ; Thu, 17 Aug 2017 10:32:49 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 DA39B1323C3 for ; Thu, 17 Aug 2017 10:32:48 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id r199so24724595vke.4 for ; Thu, 17 Aug 2017 10:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kQwc/yj4imKH9Q2q/CZYjn7Yj+WbiPC5bBJCDEKdUOg=; b=OfZDZzLfdfXIRJ5efKsSVvMiNdXG4lr0xRRKfBqCnQw0jZp0Gu0uw5D4lu5pnBztQJ 5FBaBW0HnRgL4uobIjcDWzpZuZ5hRvdcHsCs0vXZDlo8nafVXdHJLXhjzZLbWNsYit0x ReY9d5013RALswWhnn5iWw18OI5u9tHvTeSBg= 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=kQwc/yj4imKH9Q2q/CZYjn7Yj+WbiPC5bBJCDEKdUOg=; b=Gh2wiR8M1B8L30NrhmR2w8HX6Z6LLdvH3dtRRXx07gQKZUoVaMy2BhrtBRZYLp0z+e nvZtYu2kOO6dNws6YzLNEKItDwqUqM4KVB8tOIsTQ7blb7nFnL+2BfEZY3YlEtdl0B09 ZfrXonRdB9WFFpyRrba1w01HOUqXmZDzkAz3XeLYCHGuYw6Xe7nAe5NN/UcIfUyjuIZb T7Kj3kN2SDX/jsNW2E4f0A4uXI0BIhixJMJH4hJjOxfi5MQQH21Pm08Cowki4BoMSu7i B7vnK4WF1/lIfbgdlVnZfMSD3tSUqzCVE9VtIGzJI7e3I89p1KAr427i56UztulxjULm ygiQ== X-Gm-Message-State: AHYfb5g/oEWy6oQGFE8q7/S7DBg94qempGrm/ul+jYD7BYZjk2QqssN2 +1mb5gNCzaDWgmrQFtn3fplmIwLz5pxq X-Received: by 10.31.128.144 with SMTP id b138mr4092010vkd.22.1502991167668; Thu, 17 Aug 2017 10:32:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.62.90 with HTTP; Thu, 17 Aug 2017 10:32:46 -0700 (PDT) In-Reply-To: References: From: Adrian Hope-Bailie Date: Thu, 17 Aug 2017 18:32:46 +0100 Message-ID: To: Ben Sharafian Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1142a1d0a66f4e0556f666ef" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 17:32:54 -0000 --001a1142a1d0a66f4e0556f666ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 16 August 2017 at 10:22, Ben Sharafian wrote: > OK, I think in that case we're mostly disagreeing over where the > condition/fulfillment/expiry actually go in the data. > That's one way to look at it but that's ultimately what the architecting the layering is. Deciding at which layer (and therefor encapsulated in what packet) certain data should be. > The reason I don't agree with your position is based on which parties I > think should be aware of ILP. > I don't think that's the right way to look at it. The connector needs to be able to understand at least the ILP layer data AND the lower layer data. Normally the way the processing stack is implemented is that there is a module for each layer that processes the data from that layer and then passes the payload and any other important information up to the next layer= . > In order to track the balance between each other accurately, the two > connectors have to keep track of conditions, fulfillments, and expiries o= n > each of the transfers. > This is where I disagree with you. Two connectors exchanging a transfer only care about the data that is relevant to them for that transfer. It's quite possible for two connectors to perform a transfer that has no conditions or fulfillments or a transfer that has a different condition and fulfillment (such as an atomic mode transfer where the condition is a compound one that has multiple sub-conditions). > That means the connectors' accounting logic that handles the conditions, > fulfillments, and expiries is going to be using some information inside t= he > ILP packet and some information outside of it in order to perform these > transfers. > It will only use info inside the packet if it uses conditional transfers that use that same condition. This is the most likely scenario but that is not a protocol requirement. > > I think it's cleaner to say everything required to make these local > transfers should go in one protocol, so the accounting logic of these > connectors doesn't have to deal with ILP directly. > I strongly disagree with that. That's entirely the wrong reason to put data into a specific layer. The data in the ILP layer is there because it's "end-to-end" data. If a protocol at a lower layer wants to use that data then it must replicate it. That seems inefficient but it's the correct way to do it. One could define a lower layer protocol that doesn't replicate the data but the rules of the protocol are "Get the condition from the ILP packet". In that case, that specific lower level protocol is forcing implementations to understand the ILP packet format, that's an implementation detail. Another lower layer protocol might take the condition from the ILP packet and re-encode it in a different form (like a base64ulr string or NI: uri) > Then the connectors' ILP-packet-related behavior can all be routing > related. > Routing requires looking at the condition, expiry and amount. A connector's routing logic shouldn't forward a packet if the expiry is too low or if the condition is obviously corrupted. If the protocols were designed correctly as I am proposing then another routing decision would be, is the condition that was used in the incoming transfer the same as the one used in the ILP packet? > This would add a few benefits; two connectors could perform non-ILP > conditional transfers between one another (which would be useful for > reconciliation and settlement), and could also allow two connectors to us= e > more complex condition types (i.e. signatures for atomic mode) without > forcing us to support that in the ILP packet. > You seem to have this backwards. Both of these things are supported if the condition and expiry ARE in the ILP packet. Atomic mode is not supported in the ILP protocol it is supported in the lower layer transfer protocol. The ILP packet just contains the end-to-end condition (always a SHA-256 hash) and then the local transfer can have a different condition that is derived from the condition in the ILP packet. > It also keeps the integrity of the ILP packet as something lower levels > don't modify; the connector has to modify the expiry in order to pass alo= ng > an ILP payment (they may not modify the expiry if they're using something > like atomic mode, but then we have the issue with advanced condition type= s > not being supported in the ILP packet). > I think the expiry should always be the expiry set by the sender. It won't be changed. > > In the case where the ledger _does_ care about the condition and > fulfillment, the argument in favor of separating > condition/fulfillment/expiry from the rest of the packet is similar. > Because we don't control the features of all ledgers, we'll need our > plugins or ledger adapters to be aware of ILP. This makes it hard to > interact with any events that don't involve ILP packets, and impossible t= o > handle features that extend beyond what we support in the ILP packet. We > could pass details about non-ILP ledger features (like a crypto condition= ) > in the side data, but in the event of any redundancy we have to check the > ledger-supplied info, not the info in the ILP packet. > Comparing the condition in the local transfer and the one in the ILP packet should be part of the routing logic. > > Basically, condition/fulfillment/expiry are used for accounting local > transfers (even if they aren't being "ledger" enforced) in addition to > their role as every-hop information. By putting them in the ILP packet, w= e > limit the special features that ledgers can support and make our software > abstractions harder to separate cleanly. By putting them in the local > transfer alongside the ILP packet but not inside it, we do separate the > data a little more, but we have more freedom in what the underlying > accounting and ledger logic can do, and our software modules will have mo= re > clearly separated domains. > They should be in both the local transfer AND the ILP packet if they are needed by the local transfer protocol. This allows the flexibility you desire because the local transfer protocol can do ANYTHING including using the condition from the ILP packet as-is, not at all or enhanced for something like atomic mode. > > On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie < > adrian@hopebailie.com> wrote: > >> Exactly =F0=9F=91=8D >> >> On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian >> wrote: >> >>> Ok, I think I have a better idea of what you're saying. >>> >>> It sounds like you're saying the ILP layer contains all information tha= t >>> is common between every hop (destination, destination amount, opaque da= ta, >>> condition, fulfillment, expiry). The lower level would then be used for= all >>> the transfer-local details (source amount, next connector account, >>> custom/local data). >>> >>> If the lower level wanted to do anything related to the every-hop >>> payment, i.e. escrow funds until the receipt has been produced, it woul= d >>> look into the ILP layer for that information. If the lower level didn't= do >>> any escrow or expiries that require every-hop details, it would simply >>> function as a communication method. >>> >>> Is that right? >>> >>> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >>> adrian@hopebailie.com> wrote: >>> >>>> >>>> >>>> On 15 August 2017 at 16:00, Ben Sharafian wrote= : >>>> >>>>> In that case, the plugin or whatever is doing the accounting is the >>>>>>>> ledger. Digital value is always tracked in ledgers, so I think it = does make >>>>>>>> sense to think of this as the base layer. The reason to abstract t= he >>>>>>>> functionality you expect from the ledger layer is precisely so you= can >>>>>>>> handle it in different ways, depending on what the underlying syst= ems >>>>>>>> provide. >>>>>>> >>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>> >>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>> some type of HTLA >>>>>>> >>>>>>> >>>>>>> >>>>>>> 1. There are separate plugins for messaging and for transfers >>>>>>> and when you peer with someone you have to agree on a plugin for= each >>>>>>> >>>>>>> >>>>>>> 1. We standardize the messaging part and say that all goes over >>>>>>> IP and then just have more minimal plugins for the on-ledger set= tlements >>>>>>> >>>>>>> Number 1 is what we have and I think that still makes the most sens= e. >>>>>> >>>>>> >>>>> I think you're confusing implementation details and defining of >>>>>> interfaces with definition of a protocol stack. The only differences >>>>>> between the tree examples you have above is in implementation. >>>>> >>>>> >>>>> I had to scroll up after reading this to make sure it was @adrian >>>>> talking, because that seems like the opposite of what you were arguin= g for. >>>>> >>>> >>>> I don't think so. But I think that is part of the problem. We are not >>>> all focused on the same thing. I am actually not very interested in CL= P at >>>> all. It is one of potentially many protocols that may exist below the = ILP >>>> layer. All we're doing by defining CLP is bootstrapping the network by >>>> defining a protocol for everyone to use to get started. >>>> >>>> In designing the ILP layer properly we should try and forget everythin= g >>>> we know about the lower layers other than what features we require of = them. >>>> >>>> There is a misconception that ILP requires the lower layers to support >>>> conditional transfers, that is not true. >>>> >>>> All we actually need from a lower layer protocol is to transfer data >>>> back and forth and provide a way to reliably map requests to responses= . >>>> >>>> What ILP provides lower layers is a way to reward your peer for passin= g >>>> on the packet. The Internetworking layer defines a condition, a reward= that >>>> must be paid to the receiver for the fulfillment and the time allowed = to >>>> claim this reward. >>>> >>>> Because of this, within lower-layer protocols that offer the basic >>>> request/response features we need, we could add conditional payment >>>> semantics that use the condition, expiry and fulfillment provided by I= LP. >>>> This would allow a node to offer a reward to their next peer to for >>>> delivering the packet they send them and to make the local financial >>>> transaction contingent on the end-to-end transaction. >>>> >>>> But crucially, adding that semantic to the lower layer protocol >>>> provides nothing extra to the ILP layer. The value is purely derived f= rom >>>> the two peers who use that protocol and can now use conditional paymen= ts to >>>> protect themselves from their peers. >>>> >>>> >>>>> The proposal that you're arguing for is basically asserting that we'r= e >>>>> going to be using CLP, because it makes the assumption that the conne= ctors >>>>> (who understand ILP) are managing the HTLA logic. >>>>> >>>> >>>> Not at all. I am asserting that it doesn't matter what protocol you us= e >>>> below the ILP layer because it shouldn't matter. All of this talk abou= t ILP >>>> being different because money is more important than data is nonsense. >>>> >>>> The difference between ILP and IP that makes ILP suitable for value >>>> transfer and IP not is at the internetworking layer. ILP requires that= all >>>> packets are either a request or response and that the responses follow= the >>>> same path as the requests. Further ILP defines a signature scheme that >>>> gives the sender a way to be certain the request was received by the >>>> receiver. >>>> >>>> *This could be done entirely without money* but then there would be >>>> little incentive to sign the receipt or deliver the signature back to = the >>>> original sender. >>>> >>>> So, if you add money then you add economic incentives to the mix. At >>>> each hop the sender promises the next upstream peer a payment if they = can >>>> return the receipt. The net effect is that this can be used to transfe= r >>>> money from the sender to the receiver by simply defining up front the >>>> amount that the receiver must get to produce the signature. >>>> >>>> >>>>> >>>>> In the current model, the CLP/trustline model and the direct ledger >>>>> model both work without having to treat anything on the ILP layer >>>>> differently. We're favoring on-ledger messaging because of our >>>>> implementation, yes, but we've been able to switch most all of our pl= ugins >>>>> from on-ledger messaging to RPC-based messaging without changing the = ILP >>>>> layer at all. >>>>> >>>>> With the ledger-level abstraction, we were able to switch from our >>>>> ledger-based mode of thinking to the CLP/trustline based way without >>>>> changing anything other than the plugin. Your argument comes from an >>>>> assumption of a CLP-style ledger protocol with some underlying ledger= , >>>>> which we can't assume is always the case. >>>>> >>>> >>>> I'm not sure what any of that proves tbh. These are all implementation >>>> concerns. They don't change the fact that the condition, expiry and >>>> fulfillment are part of ILP not the lower layer protocols. >>>> >>>>> >>>>> >>>>> From the perspective of the Interledger Protocol the implementation o= f >>>>>> the lower layers is not important, that's the whole point of layerin= g. By >>>>>> forcing important aspects of ILP like the condition, fulfillment and= expiry >>>>>> down into those layers you muddy the waters and we now have to stand= ardize >>>>>> those protocols too. Instead we should just be defining the function= s they >>>>>> must provide and then leave it up to implementations to provide thos= e >>>>>> functions. >>>>> >>>>> >>>>> I don't agree with this point; the condition and fulfillment have >>>>> actual meaning to the ledger layer. >>>>> >>>> >>>> NO THEY DON'T! They have meaning to SOME ledgers that implement SOME >>>> lower layer protocols, IF they choose to use them. >>>> >>>> Excuse the shouting but this is the crux of the issue. We need to all >>>> agree that it is entirely possible for a transfer to be done that does= n't >>>> use the condition and fulfillment and that if this was in the middle o= f a >>>> 10-hop ILP payment it would have no effect on the sender and receiver. >>>> >>>>> >>>>> You've said that the ledger often doesn't care about fulfillment and >>>>> condition, but the ledger _layer_'s (where transfers are done) role i= s to >>>>> take in condition and fulfillment and make a transfer which satisfies= its >>>>> HTLA. >>>>> >>>> >>>> No, the ledger's role is to keep a tab of net financial positions >>>> between two peers. It MAY use conditions and fulfillments that it pull= s >>>> from the ILP layer to help it do that in a way both peers agree on. >>>> >>>> Note that a "layer" doesn't have a role. I think there is some >>>> confusion about the difference between layering the protocol and >>>> abstracting functionality into different components. >>>> >>>> >>>>> If the ledger layer has to look into the ILP packet to do so, that is >>>>> a blatant breaking of layering. >>>>> >>>> >>>> Not at all! The module acting at the layers *below* the >>>> internetworking layer shouldn't modify anything inside the packets of = the >>>> higher layers but they can definitely inspect them and adjust their >>>> behavior based on what they to find. >>>> >>>> In fact the prevalence of this is the subject of a lot of debate at th= e >>>> IETF currently because endpoints are often encrypting their payloads a= nd in >>>> some cases this makes it difficult for middle-boxes to be effective at >>>> their jobs. >>>> >>>> By putting the condition, fulfillment, and expiry on the ledger layer, >>>>> we leave it open for any ledger type to work, rather than forcing all >>>>> ledger-layer software to understand ILP. >>>>> >>>> >>>> Actually you do the opposite. You make it a requirement of every >>>> protocol below the ILP layer to define a way to carry these data eleme= nts >>>> and encode and decode them, even if they don't use them >>>> >>>> Ledger layer components don't have to understand ILP unless they choos= e >>>> to re-use the condition for their own local transfer. Ledgers themselv= es >>>> *never* have to understand ILP. >>>> >>>> Remember a ledger layer protocol could use a completely different >>>> conditional payments scheme, like atomic mode ILP, where it takes the >>>> end-to-end condition and creates a new compound condition that depends= on >>>> the fulfillment and some notary signature. >>>> >>>> There will be a component in a connector's stack that must pass the IL= P >>>> packet to the next peer. If it does this using a transfer protocol tha= t >>>> uses conditional transfers and wants to use the same condition as the = ILP >>>> packet then it must decode the packet. >>>> >>>> But, it will likely do something with that condition before sending th= e >>>> transfer to the ledger like encoding it differently or rehashing it >>>> (lightning?) so that it's in the form expected by the ledger. >>>> >>>> That's an implementation decision of the lower layer protocol used >>>> between those two peers. >>>> >>>> >>>>> >>>>> I agree that Interledger defines how conditions, fulfillments, and >>>>> expiries should be chained together, but it makes no assertions about= their >>>>> data format. >>>>> >>>> >>>> ILP doesn't define how anything is chained together. From the >>>> perspective of ILP the condition and fulfillment are end-to-end data. = They >>>> are agreed by the two endpoints who don't care how they get from Alice= to >>>> Bob and back. >>>> >>>> The design of ILP is such that it facilitates the design of lower leve= l >>>> protocols that can be used to carry the ILP packets across multiple ho= ps >>>> (networks) using economic incentives such that the sender pays enough = for >>>> the first hop to ensure that all nodes in between can extract the fee = they >>>> want and the receiver will still get the amount they expected.. >>>> >>>> >>>> >>>>> ILP says you should send your outgoing transfer with the same >>>>> condition as the incoming one, and a lower expiry. >>>>> >>>> >>>> No it doesn't. An internetworking protocol can't prescribe that kind o= f >>>> thing to lower level protocols. An incoming and outgoing transfer coul= d be >>>> sent using completely different protocols and the financial agreement = with >>>> the peers on those two routes could be vastly different too. >>>> >>>> The only service ILP requires of lower level protocols is that they ca= n >>>> map a response to an original request. This requirement is okay becaus= e it >>>> is isolated to a single route/link at a time not a requirement that cr= osses >>>> the inter-network boundary that ILP crosses. >>>> >>>> >>>>> But because ILP allows for many different types of ledgers, it doesn'= t >>>>> make sense to assert how these are encoded. >>>>> >>>> >>>> By putting them in the ILP packet you do the opposite. You make no >>>> assertions about how they are encoded if they are used at lower layers= , or >>>> how they may be combined with other conditions or even used to derive = new >>>> conditions. >>>> >>>>> >>>>> IP doesn't tell you how to encode an ethernet packet. It doesn't even >>>>> know whether it's going over a computer or a hand-written letter carr= ied by >>>>> a pigeon. IP takes for granted that you can send data over one connec= tion >>>>> by putting it in a lower level. >>>>> >>>> >>>> Correct, but if a link layer protocol wanted to look into the IP packe= t >>>> headers of a packet it wants to transfer and use some data from there = in >>>> its internal logic (or even reuse data in it's own frame) that would b= e >>>> totally fine. >>>> >>>> >>>>> Even though IP tells you how to chain these connections together, it >>>>> doesn't have to put the things it's chaining on the internetworking l= evel. >>>>> >>>> >>>> IP doesn't tell you how to chain things together. IP simply defines th= e >>>> end-to end data envelope and address space. Because of this nodes that >>>> implement the multiple lower layer protocols are able to push IP packe= ts >>>> down a link and expect the node on the other side to understand the he= aders >>>> and route it onward on another link. >>>> >>>> Everything needed by the IP module to decide what to do with the packe= t >>>> is in the IP packet headers. i.e. Has it exceeded a TTL? Is there a ro= ute >>>> for this destination? Is it corrupted (checksum fails)? But also, >>>> everything that is needed by the endpoint (like the source address) is= also >>>> in there. >>>> >>>> There is no dependency on nodes to be good citizens and always pass >>>> certain other data from the lower layers into the next link. That woul= d be >>>> breaking the layering. >>>> >>>> >>>>> IP also assumes that if you get some incoming data on a connection yo= u >>>>> can copy it and send it out on the next connection. Because you can a= lready >>>>> send data over a connection, all IP adds is the missing piece: a pack= et >>>>> that tells you where to go. >>>>> >>>>> With ILP, we assume that there is a way to prepare a conditional >>>>> transfer, expire a conditional transfer, and fulfill a conditional >>>>> transfer. >>>>> >>>> >>>> No we don't! We assume that if we deliver the packet as intended we'll >>>> get back a response packet with a signature that matches the condition= in >>>> the packet. So, if we have an agreement with someone that they will pa= y us >>>> when we present that signature then we are prepared to enter a similar >>>> agreement with the next peer because we expect that signature to come = all >>>> the way back along the interledger layer route.. >>>> >>>> >>>>> We also assume that if you get an incoming transfer you can create an >>>>> outgoing transfer with the same condition. The abstraction we made me= ans >>>>> that conditions and fulfillments are already carried in the lower lev= els. >>>>> >>>> >>>> That is a bad assumption that comes from the broken layering. What if >>>> my outgoing link doesn't support conditional transfers? So now where d= o I >>>> put the condition? >>>> >>>>> >>>>> >>>>> We could have assumed that no ledgers ever support conditional >>>>> transfers, and said the only thing ILP gets from lower levels is the >>>>> ability to send a transfer. But if we want to support the case where = any of >>>>> them do, we have to keep the conditions and fulfillments in the layer= where >>>>> they're actually used. >>>>> >>>> >>>> I don't follow that logic at all. If we want to support the case where >>>> any of them do then we must ensure the condition and expiry are always >>>> carried in a consistent place at the internetworking layer so that if = they >>>> do want to use them they know where to find them. >>>> >>>> >>>>> >>>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>>> adrian@hopebailie.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 14 August 2017 at 22:03, Evan Schwartz wrote: >>>>>> >>>>>>> I think this thread is going to get extremely unwieldy but here goe= s: >>>>>>> >>>>>>> > - All interledger layer messages should be ILP packets (including >>>>>>> fulfillments) and be capable of carrying higher layer protocol payl= oads. >>>>>>> >>>>>>> Interledger has higher requirements than ILP for the lowest layer, >>>>>>> specifically because we are carrying money and not just data. One o= f the >>>>>>> requirements is being able to transmit a 32-byte fulfillment back a= long the >>>>>>> same path that carried the payment originally. If we expect this of= the >>>>>>> lower layer, I don't see a point in putting the fulfillment into an= ILP >>>>>>> packet and transmitting it as Interledger data along the same path.= All >>>>>>> ledger-layer protocols will need to interpret the fulfillment passe= d in >>>>>>> their protocol, not the one passed through the Interledger layer. >>>>>>> >>>>>> >>>>>> This is not correct. There is no requirement on ledger layer >>>>>> protocols to transmit or understand the fulfillment. You are looking= at >>>>>> this through the lens of existing implementations from the bottom up >>>>>> instead of starting at the interledger layer. >>>>>> >>>>>> The primary function of the condition and fulfillment is as a signed >>>>>> end-to-end receipt. If the sender agrees a condition with a receiver= and >>>>>> then gets back the valid fulfillment they don't care what happened i= n the >>>>>> middle. The receiver has signed a receipt saying they have their mon= ey. >>>>>> >>>>>> The value of using a standard for the receipt and signature is that >>>>>> each transfer along the way CAN re-use it. One the one hand you can = have a >>>>>> transfer between two peers that have zero trust and the ledger they = use >>>>>> supports conditional payments completely. On the other extreme you c= an have >>>>>> two peers that have a full trust and ignore the condition and fulfil= lment >>>>>> completely. >>>>>> >>>>>> The ledger layer protocols carry ILP packets. Payment requests and >>>>>> either fulfillment or error responses. If a ledger layer protocol wa= nts to >>>>>> use the condition and fulfillment for their own operations they can = extract >>>>>> these from the ILP packets and use them. >>>>>> >>>>>> >>>>>>> > - While it may make sense to split the interledger payment and >>>>>>> interledger quoting protocols into new higher level protocols that = seems >>>>>>> like an unnecessary abstraction. Instead the packet definitions sho= uld just >>>>>>> have some consistency and probably a common base/header. >>>>>>> >>>>>>> The current protocols effectively have this header but it isn't >>>>>>> separated out. There are two fields in the request header: type and >>>>>>> destination address. There is one field in the response header: typ= e. I >>>>>>> don't think it makes that much of a big difference to separate thes= e fields >>>>>>> if all of the fields in that packet need to be interpreted together= (for >>>>>>> example, you can't understand a quote request if you strip off the >>>>>>> destination address). >>>>>>> >>>>>> >>>>>> I agree that we don't HAVE to explicitly separate them out but I >>>>>> think ti would make it clearer how the stack is architected if there= was a >>>>>> header that was consistent across all packets. Currently the only th= ing >>>>>> that is consitent across all ILP packets is that they are defined in= t he >>>>>> same file. >>>>>> >>>>>> >>>>>>> >>>>>>> > - We should define two base ILP packet types: request and >>>>>>> response. >>>>>>> >>>>>>> Unless this adds some substantive benefit or new fields I don't >>>>>>> think it's worth breaking all of the formats we have just to rearra= nge >>>>>>> things. >>>>>>> >>>>>> >>>>>> The goal of this exercise is to tease out the best design and ignore >>>>>> the cost of change until we can compare the results with the current= design. >>>>>> >>>>>> >>>>>>> >>>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>>> nodes/hosts. >>>>>>> >>>>>>> A ledger is any system that tracks accounts and balances. When you >>>>>>> use a trustline all of your messages still need to go through an ac= counting >>>>>>> system (such as the plugin in the JS implementation) and then on to= the >>>>>>> other program logic. >>>>>>> >>>>>> >>>>>> As above, this is incorrect. There is no requirement for "all >>>>>> messages to go through an accounting system". >>>>>> >>>>>> Since designing the first implementation of 5-bells ledger we have >>>>>> assumed that passing the ILP packet MUST be done by the ledger becau= se that >>>>>> is how we implemented it. But that is not true. It is perfectly vali= d for >>>>>> the passing of an ILP packet from one peer to another to be simply a= n >>>>>> exchange of data. >>>>>> >>>>>> The receiving peer makes a decision about whether or not to forward >>>>>> the packet based on the current financial position they have with th= e >>>>>> sending peer. >>>>>> >>>>>> It is convenient if the ledger that records the net positions of the >>>>>> peers also forwards the messaging and even better if it natively sup= ports >>>>>> conditional payments and can use the condition and the fulfillment f= rom the >>>>>> ILP packet for those but that's all it is, convenient. >>>>>> >>>>>> >>>>>> >>>>>>> In that case, the plugin or whatever is doing the accounting is the >>>>>>> ledger. Digital value is always tracked in ledgers, so I think it d= oes make >>>>>>> sense to think of this as the base layer. The reason to abstract th= e >>>>>>> functionality you expect from the ledger layer is precisely so you = can >>>>>>> handle it in different ways, depending on what the underlying syste= ms >>>>>>> provide. >>>>>>> >>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>> >>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>> some type of HTLA >>>>>>> >>>>>>> 2. There are separate plugins for messaging and for transfers >>>>>>> and when you peer with someone you have to agree on a plugin for= each >>>>>>> 3. We standardize the messaging part and say that all goes over >>>>>>> IP and then just have more minimal plugins for the on-ledger set= tlements >>>>>>> >>>>>>> Number 1 is what we have and I think that still makes the most sens= e. >>>>>>> >>>>>> >>>>>> I think you're confusing implementation details and defining of >>>>>> interfaces with definition of a protocol stack. The only differences >>>>>> between the tree examples you have above is in implementation. >>>>>> >>>>>> From the perspective of the Interledger Protocol the implementation >>>>>> of the lower layers is not important, that's the whole point of laye= ring. >>>>>> By forcing important aspects of ILP like the condition, fulfillment = and >>>>>> expiry down into those layers you muddy the waters and we now have t= o >>>>>> standardize those protocols too. Instead we should just be defining = the >>>>>> functions they must provide and then leave it up to implementations = to >>>>>> provide those functions. >>>>>> >>>>>> I know we want to define a standard to bootstrap the system (CLP) bu= t >>>>>> that's misleading us into thinking it's an essential part of the sta= ck. >>>>>> It's perfectly valid for two peers to not use CLP and still be part = of the >>>>>> Interledger. >>>>>> >>>>>> That said, you raise an interesting consideration about the layers >>>>>> below ILP and actually I think it makes sense to split these. >>>>>> >>>>>> We keep trying to force messaging through the ledger layer and >>>>>> actually that's the wrong place to put it if we can split the ledger= layer >>>>>> into a messaging layer and a ledger layer. That way we can stop tryi= ng to >>>>>> think of all HLTAs as ledgers. >>>>>> >>>>>> A thought, why not use sub-layers as is common in other stacks: >>>>>> >>>>>> 1. Link layer: Layer upon which two peers that have a direct link, o= r >>>>>> participate in the same payment network, communicate >>>>>> 2. Transfer/ ledger: Layer on which financial positions between two >>>>>> peers are recorded >>>>>> >>>>>> This reflects the already emerging HTLA model and many of our >>>>>> existing plugins and ledger integrations. >>>>>> Link Layer: XRP Paychan, Lightning >>>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>>> >>>>>> This doesn't prevent us from defining a standard binary protocol tha= t >>>>>> defines all of the operations for both layers (like CLP) but I see v= alue in >>>>>> distinguishing between these two. >>>>>> >>>>>> >>>>>>> >>>>>>> > - The protocol should differentiate between the operation of >>>>>>> preparing a transfer on a ledger and the operation of passing an IL= P packet >>>>>>> from one peer to another. >>>>>>> >>>>>>> The protocol assumes your conditional transfer is underpinned by >>>>>>> some HTLA >>>>>>> . >>>>>>> It doesn't care whether that's on-ledger or not. >>>>>>> >>>>>> >>>>>> What do you mean when you say "the protocol"? In my statement I am >>>>>> referring to ILP. >>>>>> My point above being that ILP expects ILP packets to be passed from >>>>>> peer to peer but has no expectations about transfers. >>>>>> >>>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>>> exchange ILP packets with no transfers. Clearly if a node routes a p= acket >>>>>> on and has no incoming transfer it's going to lose money but that's = a >>>>>> consideration for that node. It doesn't affect anyone else in the ch= ain. >>>>>> >>>>>> ILP doesn't assume anything about transfers at all, let alone >>>>>> conditional transfers. It provides useful semantics for conditional >>>>>> transfers to be used by two peers to transact as part of a larger IL= P >>>>>> payment. >>>>>> >>>>>> >>>>>>> >>>>>>> > - The condition and timeout should be included in the ILP payment >>>>>>> packet. >>>>>>> >>>>>>> I strongly disagree with this. We had this debate a year ago and I >>>>>>> was on your side but was convinced that this is not a good idea. >>>>>>> >>>>>> >>>>>> Yes, I recall this and I'm sorry I didn't push harder on this point. >>>>>> Unfortunately I think the decision to pull it out of the packet is m= ostly >>>>>> driven by how our prototypes were implemented rather than good archi= tecture. >>>>>> >>>>>>> >>>>>>> The layer below ILP must be capable of doing conditional transfers >>>>>>> based on sha256 hashlocks with 32-byte preimages. >>>>>>> >>>>>> >>>>>> This is not true and I think it would be useful for us to agree on >>>>>> this as this seems to be the argument I am coming up against most of= ten. >>>>>> The peers participating in a transfer that is part of an ILP payment= may >>>>>> wish to use conditional transfers as a way to enforce their agreemen= t but >>>>>> this is not a requirement of the protocol. >>>>>> >>>>>> The agreement between any two peers is: "I will pay you X if you can >>>>>> provide a receipt that Y was paid Z before T". >>>>>> ILP provides a standard for expressing this agreement so that these >>>>>> can be chained together BUT it is not a requirement that every agree= ment in >>>>>> the chain uses the condition, and fulfillment provided at the ILP la= yer. >>>>>> >>>>>> >>>>>>> >>>>>>> As a result, the original condition and the corresponding preimage >>>>>>> MUST be expressed in that layer. >>>>>>> >>>>>> >>>>>> As I have shown above, this is not true. >>>>>> >>>>>> >>>>>>> Then the question is whether we should also include it in the packe= t >>>>>>> that is forwarded. What ultimately convinced me is the following: A= ll >>>>>>> connectors MUST ignore the condition if it is in the packet, becaus= e they >>>>>>> are only guaranteed their money back if they use the same condition= from >>>>>>> the incoming transfer they got. >>>>>>> >>>>>> >>>>>> Here is where the layering is being corrupted. >>>>>> >>>>>> All connectors MUST inspect the condition in the ILP packet as part >>>>>> of their decision to route the packet or not. >>>>>> When the local transfer module of the connectors stack passes the IL= P >>>>>> packet up to the ILP module it should indicate the properties of the >>>>>> incoming transfer that carried the packet. >>>>>> This is essential firstly so that the routing logic in the ILP modul= e >>>>>> can record the incoming transfer identifier so it is able to use the >>>>>> correct response id when it passes back the fulfillment or error. >>>>>> The other properties that the ILP module should look at are the >>>>>> condition and expiry on the incoming transfer. >>>>>> >>>>>> If the incoming route uses conditional transfers and these are >>>>>> supposed to match the condition and expiry in the ILP packet then th= e ILP >>>>>> module should compare them and reject the packet if: >>>>>> a) the conditions don't match OR >>>>>> b) the expiry is too short >>>>>> >>>>>> We should still discuss if the expiry should be set by the sender an= d >>>>>> left unchanged or used like a TTL and decremented by each node. >>>>>> >>>>>> >>>>>>> Also, the receiver will need to take out the condition in order to >>>>>>> hash the packet for PSK or IPR. >>>>>>> >>>>>> >>>>>> This is completely normal. Zeroing a checksum field in a header >>>>>> before calculating the checksum is VERY common precisely because it'= s long >>>>>> been accepted that the right place to put that data is in the header= s and >>>>>> the work of zero'ing it out to calculate the checksum (or signature = in our >>>>>> case) is not material. >>>>>> >>>>>> >>>>>>> So basically, no one wants the condition in there. It feels like it >>>>>>> ought to be in there, but literally none of the parties want the ex= tra 32 >>>>>>> bytes in there. >>>>>>> >>>>>> >>>>>> "Nobody wants it there" is a terrible reason to abandon the correct >>>>>> design. The whole purpose of a good architecture is you accept that = there >>>>>> may be cases in future that haven't been considered now so designing= just >>>>>> for the known cases is a bad idea. >>>>>> >>>>>> Good architecture is not the same as optimization. Taking stuff out >>>>>> (even when it feels wrong) to save a few bytes is a good sign that i= t's a >>>>>> bad idea. >>>>>> >>>>>> >>>>>>> >>>>>>> The reason the timeout should not be in there is that there isn't a >>>>>>> single timeout for the payment. There are multiple separate timeout= s for >>>>>>> each of the bilateral transfers. Those must go in the individual tr= ansfers >>>>>>> and there is no sensible value to put in the Interledger packet. >>>>>>> >>>>>> >>>>>> As above, this is somewhat equivalent to the TTL in an IP packet. I'= m >>>>>> open to discussing if it should be a fixed value set by the sender w= here >>>>>> each node uses their own value but has the sender-defined value as a >>>>>> reference or it is actually decremented at each hop. >>>>>> >>>>>> Either way, this is part of ILP not the ledger layer just like the >>>>>> condition and fulfillment. It may be used by the ledger layer but th= at's >>>>>> implementation specific. It belongs in the ILP packet. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> -- >> Sent from a mobile device, please excuse any typos >> > > --001a1142a1d0a66f4e0556f666ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On 16 August 2017 at 10:22, Ben Sharafian <sharafian@ripple.com= > wrote:
    OK, I think in that c= ase we're mostly disagreeing over where the condition/fulfillment/expir= y actually go in the data.

    =
    That's one way to look at it but that's ultimately what the ar= chitecting the layering is. Deciding at which layer (and therefor encapsula= ted in what packet) certain data should be.
    =C2=A0
    The reason I don't agree with your position = is based on which parties I think should be aware of ILP.

    I don't think that's the right = way to look at it. The connector needs to be able to understand at least th= e ILP layer data AND the lower layer data. Normally the way the processing = stack is implemented is that there is a module for each layer that processe= s the data from that layer and then passes the payload and any other import= ant information up to the next layer.
    =C2=A0
    In order to track the balance between each oth= er accurately, the two connectors have to keep track of conditions, fulfill= ments, and expiries on each of the transfers.

    This is where I disagree with you. Two connectors exchangi= ng a transfer only care about the data that is relevant to them for that tr= ansfer. It's quite possible for two connectors to perform a transfer th= at has no conditions or fulfillments or a transfer that has a different con= dition and fulfillment (such as an atomic mode transfer where the condition= is a compound one that has multiple sub-conditions).
    =C2=A0<= /div>
    That means the connectors' accounti= ng logic that handles the conditions, fulfillments, and expiries is going t= o be using some information inside the ILP packet and some information outs= ide of it in order to perform these transfers.

    It will only use info inside the packet if it uses c= onditional transfers that use that same condition. This is the most likely = scenario but that is not a protocol requirement.
    =C2=A0
    =
    <= div style=3D"font-size:12.8px">
    I = think it's cleaner to say everything required to make these local trans= fers should go in one protocol, so the accounting logic of these connectors= doesn't have to deal with ILP directly.

    I strongly disagree with that. That's entirely th= e wrong reason to put data into a specific layer. The data in the ILP layer= is there because it's "end-to-end" data.

    I= f a protocol at a lower layer wants to use that data then it must replicate= it. That seems inefficient but it's the correct way to do it.

    <= /div>
    One could define a lower layer protocol that doesn't replicat= e the data but the rules of the protocol are "Get the condition from t= he ILP packet". In that case, that specific lower level protocol is fo= rcing implementations to understand the ILP packet format, that's an im= plementation detail.

    Another lower layer protocol might t= ake the condition from the ILP packet and re-encode it in a different form = (like a base64ulr string or NI: uri)
    =C2=A0
    Then the connectors' ILP-packet-related behavior can= all be routing related.

    Routing requires looking at the condition, expiry and amount. A connector= 's routing logic shouldn't forward a packet if the expiry is too lo= w or if the condition is obviously corrupted.

    If the prot= ocols were designed correctly as I am proposing then another routing decisi= on would be, is the condition that was used in the incoming transfer the sa= me as the one used in the ILP packet?

    =C2=A0<= /div>
    This would add a few benefits; two conn= ectors could perform non-ILP conditional transfers between one another (whi= ch would be useful for reconciliation and settlement), and could also allow= two connectors to use more complex condition types (i.e. signatures for at= omic mode) without forcing us to support that in the ILP packet.

    You seem to have this backwards. = Both of these things are supported if the condition and expiry ARE in the I= LP packet. Atomic mode is not supported in the ILP protocol it is supported= in the lower layer transfer protocol. The ILP packet just contains the end= -to-end condition (always a SHA-256 hash) and then the local transfer can h= ave a different condition that is derived from the condition in the ILP pac= ket.
    =C2=A0
    It also kee= ps the integrity of the ILP packet as something lower levels don't modi= fy; the connector has to modify the expiry in order to pass along an ILP pa= yment (they may not modify the expiry if they're using something like a= tomic mode, but then we have the issue with advanced condition types not be= ing supported in the ILP packet).

    <= /div>I think the expiry should always be the expiry set by the sender. It w= on't be changed.

    In the case where t= he ledger _does_ care about the condition and fulfillment, the argument in = favor of separating condition/fulfillment/expiry from the rest of the packe= t is similar. Because we don't control the features of all ledgers, we&= #39;ll need our plugins or ledger adapters to be aware of ILP. This makes i= t hard to interact with any events that don't involve ILP packets, and = impossible to handle features that extend beyond what we support in the ILP= packet. We could pass details about non-ILP ledger features (like a crypto= condition) in the side data, but in the event of any redundancy we have to= check the ledger-supplied info, not the info in the ILP packet.

    Comparing the condition in the loc= al transfer and the one in the ILP packet should be part of the routing log= ic.
    =C2=A0

    Basically, condition/fulfillment/expiry are use= d for accounting local transfers (even if they aren't being "ledge= r" enforced) in addition to their role as every-hop information. By pu= tting them in the ILP packet, we limit the special features that ledgers ca= n support and make our software abstractions harder to separate cleanly. By= putting them in the local transfer alongside the ILP packet but not inside= it, we do separate the data a little more, but we have more freedom in wha= t the underlying accounting and ledger logic can do, and our software modul= es will have more clearly separated domains.

    They should be in both the local transfer AND the ILP = packet if they are needed by the local transfer protocol. This allows the f= lexibility you desire because the local transfer protocol can do ANYTHING i= ncluding using the condition from the ILP packet as-is, not at all or enhan= ced for something like atomic mode.

    =C2=A0

    On Tue, Aug 15, 2017 at 10:24 = AM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
    Exactly =F0=9F=91=8D=

    On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian <sharafian@ripple.com> wr= ote:
    Ok, I think I have a bett= er idea of what you're saying.

    It sounds like you= 9;re saying the ILP layer contains all information that is common between e= very hop (destination, destination amount, opaque data, condition, fulfillm= ent, expiry). The lower level would then be used for all the transfer-local= details (source amount, next connector account, custom/local data).
    <= div>
    If the lower level wanted to do anything related to the = every-hop payment, i.e. escrow funds until the receipt has been produced, i= t would look into the ILP layer for that information. If the lower level di= dn't do any escrow or expiries that require every-hop details, it would= simply function as a communication method.

    Is tha= t right?

    On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie <adrian@hopebailie.com&= gt; wrote:


    On 15 August 2017 at 16:0= 0, Ben Sharafian <sharafian@ripple.com> wrote:
    In that case, the plugin or whatever is doing the accountin= g is the ledger. Digital value is always tracked in ledgers, so I think it = does make sense to think of this as the base layer. The reason to abstract = the functionality you expect from the ledger layer is precisely so you can = handle it in different ways, depending on what the underlying systems provi= de.
    I see 3 ways to think of the layer(s) underpinning ILP:
      =
    1. The "Ledger Layer"= ; provides both messaging capabilities and some type of=C2=A0HTLA
    1. There are separate plugins for mes= saging and for transfers and when you peer with someone you have to agree o= n a plugin for each
    1. We standard= ize the messaging part and say that all goes over IP and then just have mor= e minimal plugins for the on-ledger settlements
    Number 1 is what w= e have and I think that still makes the most sense.

    I think you're confusing implementation deta= ils and defining of interfaces with definition of a protocol stack. The onl= y differences between the tree examples you have above is in implementation= .

    I had to scroll up after re= ading this to make sure it was @adrian talking, because that seems like the= opposite of what you were arguing for.

    <= /div>
    I don't think so. But I think that is part of the prob= lem. We are not all focused on the same thing. I am actually not very inter= ested in CLP at all. It is one of potentially many protocols that may exist= below the ILP layer. All we're doing by defining CLP is bootstrapping = the network by defining a protocol for everyone to use to get started.
    <= br>
    In designing the ILP layer properly we should try and forget = everything we know about the lower layers other than what features we requi= re of them.

    There is a misconception that ILP requires th= e lower layers to support conditional transfers, that is not true.

    <= /div>
    All we actually need from a lower layer protocol is to transfer d= ata back and forth and provide a way to reliably map requests to responses.=

    What ILP provides lower layers is a way to reward your p= eer for passing on the packet. The Internetworking layer defines a conditio= n, a reward that must be paid to the receiver for the fulfillment and the t= ime allowed to claim this reward.

    Because of t= his, within lower-layer protocols that offer the basic request/response fea= tures we need, we could add conditional payment semantics that use the cond= ition, expiry and fulfillment provided by ILP. This would allow a node to o= ffer a reward to=C2=A0 their next peer to for delivering the packet they se= nd them and to make the local financial transaction contingent on the end-t= o-end transaction.

    But crucially, adding that semantic to= the lower layer protocol provides nothing extra to the ILP layer. The valu= e is purely derived from the two peers who use that protocol and can now us= e conditional payments to protect themselves from their peers.
    =C2=A0
    =
    The proposal that you're arguing for is basically asserting that w= e're going to be using CLP, because it makes the assumption that the co= nnectors (who understand ILP) are managing the HTLA logic.

    Not at all. I am asserting that it doesn= 't matter what protocol you use below the ILP layer because it shouldn&= #39;t matter. All of this talk about ILP being different because money is m= ore important than data is nonsense.

    The difference between IL= P and IP that makes ILP suitable for value transfer and IP not is at the in= ternetworking layer. ILP requires that all packets are either a request or = response and that the responses follow the same path as the requests. Furth= er ILP defines a signature scheme that gives the sender a way to be certain= the request was received by the receiver.

    This could be done entirely without money but then there wou= ld be little incentive to sign the receipt or deliver the signature back to= the original sender.

    So, if you ad= d money then you add economic incentives to the mix. At each hop the sender= promises the next upstream peer a payment if they can return the receipt. = The net effect is that this can be used to transfer money from the sender t= o the receiver by simply defining up front the amount that the receiver mus= t get to produce the signature.
    =C2=A0<= br>

    In the current model, the CLP/tru= stline model and the direct ledger model both work without having to treat = anything on the ILP layer differently. We're favoring on-ledger messagi= ng because of our implementation, yes, but we've been able to switch mo= st all of our plugins from on-ledger messaging to RPC-based messaging witho= ut changing the ILP layer at all.

    With the ledger-= level abstraction, we were able to switch from our ledger-based mode of thi= nking to the CLP/trustline based way without changing anything other than t= he plugin. Your argument comes from an assumption of a CLP-style ledger pro= tocol with some underlying ledger, which we can't assume is always the = case.

    I'm not sure what a= ny of that proves tbh. These are all implementation concerns. They don'= t change the fact that the condition, expiry and fulfillment are part of IL= P not the lower layer protocols.
    =C2=A0

    From the perspective of the In= terledger Protocol the implementation of the lower layers is not important,= that's the whole point of layering. By forcing important aspects of IL= P like the condition, fulfillment and expiry down into those layers you mud= dy the waters and we now have to standardize those protocols too. Instead w= e should just be defining the functions they must provide and then leave it= up to implementations to provide those functions.
    =
    I don't agree with this point; the condition and = fulfillment have actual meaning to the ledger layer.

    NO THEY DON'T! They have meaning to SOME = ledgers that implement SOME lower layer protocols, IF they choose to use th= em.

    Excuse the shouting but this is the crux of the issue= . We need to all agree that it is entirely possible for a transfer to be do= ne that doesn't use the condition and fulfillment and that if this was = in the middle of a 10-hop ILP payment it would have no effect on the sender= and receiver.
    =C2=A0
    You've said that the ledger often doesn't care= about fulfillment and condition, but the ledger _layer_'s (where trans= fers are done) role is to take in condition and fulfillment and make a tran= sfer which satisfies its HTLA.

    No, the ledger's role is to keep a tab of net financial positions be= tween two peers. It MAY use conditions and fulfillments that it pulls from = the ILP layer to help it do that in a way both peers agree on.

    Note that a "layer" doesn't have = a role. I think there is some confusion about the difference between layeri= ng the protocol and abstracting functionality into different components.
    =C2=A0
    If the = ledger layer has to look into the ILP packet to do so, that is a blatant br= eaking of layering.

    Not= at all! The module acting at the layers below the internetworking l= ayer shouldn't modify anything inside the packets of the higher layers = but they can definitely inspect them and adjust their behavior based on wha= t they to find.

    In fact the prevalence of this is the subject = of a lot of debate at the IETF currently because endpoints are often encryp= ting their payloads and in some cases this makes it difficult for middle-bo= xes to be effective at their jobs.

    =
    By puttin= g the condition, fulfillment, and expiry on the ledger layer, we leave it o= pen for any ledger type to work, rather than forcing all ledger-layer softw= are to understand ILP.

    A= ctually you do the opposite. You make it a requirement of every protocol be= low the ILP layer to define a way to carry these data elements and encode a= nd decode them, even if they don't use them

    Ledger la= yer components don't have to understand ILP unless they choose to re-us= e the condition for their own local transfer. Ledgers themselves never have to understand ILP.

    Remember a ledger layer protocol could u= se a completely different conditional payments scheme, like atomic mode ILP= , where it takes the end-to-end condition and creates a new compound condit= ion that depends on the fulfillment and some notary signature.

    There will be a component in a connector's stack that must pass t= he ILP packet to the next peer. If it does this using a transfer protocol t= hat uses conditional transfers and wants to use the same condition as the I= LP packet then it must decode the packet.

    But, it will li= kely do something with that condition before sending the transfer to the le= dger like encoding it differently or rehashing it (lightning?) so that it&#= 39;s in the form expected by the ledger.

    That&= #39;s an implementation decision of the lower layer protocol used between t= hose two peers.
    =C2=A0

    I agree that Interledger de= fines how conditions, fulfillments, and expiries should be chained together= , but it makes no assertions about their data format.

    ILP doesn't define how anything is chain= ed together. From the perspective of ILP the condition and fulfillment are = end-to-end data. They are agreed by the two endpoints who don't care ho= w they get from Alice to Bob and back.

    The design of ILP = is such that it facilitates the design of lower level protocols that can be= used to carry the ILP packets across multiple hops (networks) using econom= ic incentives such that the sender pays enough for the first hop to ensure = that all nodes in between can extract the fee they want and the receiver wi= ll still get the amount they expected..

    =C2=A0
    ILP says you s= hould send your outgoing transfer with the same condition as the incoming o= ne, and a lower expiry.

    No it doesn't. An internetworking protocol can't prescribe that ki= nd of thing to lower level protocols. An incoming and outgoing transfer cou= ld be sent using completely different protocols and the financial agreement= with the peers on those two routes could be vastly different too.

    T= he only service ILP requires of lower level protocols is that they can map = a response to an original request. This requirement is okay because it is i= solated to a single route/link at a time not a requirement that crosses the= inter-network boundary that ILP crosses.
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
    But because ILP = allows for many different types of ledgers, it doesn't make sense to as= sert how these are encoded.

    <= div>By putting them in the ILP packet you do the opposite. You make no asse= rtions about how they are encoded if they are used at lower layers, or how = they may be combined with other conditions or even used to derive new condi= tions.

    IP doesn't tell you how to encode an ethernet pac= ket. It doesn't even know whether it's going over a computer or a h= and-written letter carried by a pigeon. IP takes for granted that you can s= end data over one connection by putting it in a lower level.

    Correct, but if a link layer protocol= wanted to look into the IP packet headers of a packet it wants to transfer= and use some data from there in its internal logic (or even reuse data in = it's own frame) that would be totally fine.
    =C2=A0<= /div>
    Even thoug= h IP tells you how to chain these connections together, it doesn't have= to put the things it's chaining on the internetworking level.

    IP doesn't tell you how to = chain things together. IP simply defines the end-to end data envelope and a= ddress space. Because of this nodes that implement the multiple lower layer= protocols are able to push IP packets down a link and expect the node on t= he other side to understand the headers and route it onward on another link= .

    Everything needed by the IP module to decide what to do= with the packet is in the IP packet headers. i.e. Has it exceeded a TTL? I= s there a route for this destination? Is it corrupted (checksum fails)? But= also, everything that is needed by the endpoint (like the source address) = is also in there.

    There is no dependency on nodes to be g= ood citizens and always pass certain other data from the lower layers into = the next link. That would be breaking the layering.
    =C2= =A0
    IP als= o assumes that if you get some incoming data on a connection you can copy i= t and send it out on the next connection. Because you can already send data= over a connection, all IP adds is the missing piece: a packet that tells y= ou where to go.

    With ILP, we assume that there is = a way to prepare a conditional transfer, expire a conditional transfer, and= fulfill a conditional transfer.

    No we don't! We assume that if we deliver the packet as inten= ded we'll get back a response packet with a signature that matches the = condition in the packet. So, if we have an agreement with someone that they= will pay us when we present that signature then we are prepared to enter a= similar agreement with the next peer because we expect that signature to c= ome all the way back along the interledger layer route..
    =C2=A0
    W= e also assume that if you get an incoming transfer you can create an outgoi= ng transfer with the same condition. The abstraction we made means that con= ditions and fulfillments are already carried in the lower levels.

    That is a bad assumption that com= es from the broken layering. What if my outgoing link doesn't support c= onditional transfers? So now where do I put the condition?
    = =C2=A0

    We could have assumed that no ledgers ever support conditional transf= ers, and said the only thing ILP gets from lower levels is the ability to s= end a transfer. But if we want to support the case where any of them do, we= have to keep the conditions and fulfillments in the layer where they'r= e actually used.

    I don&#= 39;t follow that logic at all. If we want to support the case where any of = them do then we must ensure the condition and expiry are always carried in = a consistent place at the internetworking layer so that if they do want to = use them they know where to find them.
    =C2=A0

    On Tue, Aug 15, 2017 at 12:04 PM, Adrian Ho= pe-Bailie <adrian@hopebailie.com> wrote:


    On 14 August 2017 at 22:03, Evan Schwartz <= ;evan@ripple.com&g= t; wrote:
    = I think this thread is going to get extremely unwieldy but here goes:=

    >=C2=A0- All int= erledger layer messages should be ILP packets (including fulfillments) and = be capable of carrying higher layer protocol payloads.
    Interledger has higher requirements than ILP for the low= est layer, specifically because we are carrying money and not just data. On= e of the requirements is being able to transmit a 32-byte fulfillment back = along the same path that carried the payment originally. If we expect this = of the lower layer, I don't see a point in putting the fulfillment into= an ILP packet and transmitting it as Interledger data along the same path.= All ledger-layer protocols will need to interpret the fulfillment passed i= n their protocol, not the one passed through the Interledger layer.

    This is not correct. There is no req= uirement on ledger layer protocols to transmit or understand the fulfillmen= t. You are looking at this through the lens of existing implementations fro= m the bottom up instead of starting at the interledger layer.

    The primary function of the condition and fulfi= llment is as a signed end-to-end receipt. If the sender agrees a condition = with a receiver and then gets back the valid fulfillment they don't car= e what happened in the middle. The receiver has signed a receipt saying the= y have their money.

    The value of us= ing a standard for the receipt and signature is that each transfer along th= e way CAN re-use it. One the one hand you can have a transfer between two p= eers that have zero trust and the ledger they use supports conditional paym= ents completely. On the other extreme you can have two peers that have a fu= ll trust and ignore the condition and fulfillment completely.
    =C2= =A0
    The ledger layer protocols carry IL= P packets. Payment requests and either fulfillment or error responses. If a= ledger layer protocol wants to use the condition and fulfillment for their= own operations they can extract these from the ILP packets and use them.


    >=C2=A0- While it may make sense = to split the interledger payment and interledger quoting protocols into new= higher level protocols that seems like an unnecessary abstraction. Instead= the packet definitions should just have some consistency and probably a co= mmon base/header.

    =
    The current pr= otocols effectively have this header but it isn't separated out. There = are two fields in the request header: type and destination address. There i= s one field in the response header: type. I don't think it makes that m= uch of a big difference to separate these fields if all of the fields in th= at packet need to be interpreted together (for example, you can't under= stand a quote request if you strip off the destination address).

    I agree that we don't H= AVE to explicitly separate them out but I think ti would make it clearer ho= w the stack is architected if there was a header that was consistent across= all packets. Currently the only thing that is consitent across all ILP pac= kets is that they are defined int he same file.
    =C2=A0<= /div>

    >=C2=A0- We sh= ould define two base ILP packet types: request and response.
    Unless t= his adds some substantive benefit or new fields I don't think it's = worth breaking all of the formats we have just to rearrange things.

    The goal of this exercise is to= tease out the best design and ignore the cost of change until we can compa= re the results with the current design.
    =C2=A0

    >=C2=A0- ILP is not about ledgers= , it is about trustlines between nodes/hosts.

    A ledger is any system that tracks accounts an= d balances. When you use a trustline all of your messages still need to go = through an accounting system (such as the plugin in the JS implementation) = and then on to the other program logic.

    <= /div>
    As above, this is incorrect. There is no requirement for &= quot;all messages to go through an accounting system".

    Since designing the first implementation of 5-bells ledger we have assum= ed that passing the ILP packet MUST be done by the ledger because that is h= ow we implemented it. But that is not true. It is perfectly valid for the p= assing of an ILP packet from one peer to another to be simply an exchange o= f data.

    The receiving peer makes a decision about whether= or not to forward the packet based on the current financial position they = have with the sending peer.

    It is convenient i= f the ledger that records the net positions of the peers also forwards the = messaging and even better if it natively supports conditional payments and = can use the condition and the fulfillment from the ILP packet for those but= that's all it is, convenient.

    =C2=A0
    In that case, the p= lugin or whatever is doing the accounting is the ledger. Digital value is a= lways tracked in ledgers, so I think it does make sense to think of this as= the base layer. The reason to abstract the functionality you expect from t= he ledger layer is precisely so you can handle it in different ways, depend= ing on what the underlying systems provide.

    I see = 3 ways to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messaging capabilities= and some type of HTLA
    2. There are separate plugins for messagi= ng and for transfers and when you peer with someone you have to agree on a = plugin for each
    3. We standardize the messaging part and say that all = goes over IP and then just have more minimal plugins for the on-ledger sett= lements
    Number 1 is what we have and I think that still makes= the most sense.

    I think you'r= e confusing implementation details and defining of interfaces with definiti= on of a protocol stack. The only differences between the tree examples you = have above is in implementation.

    From the perspective of the Interle= dger Protocol the implementation of the lower layers is not important, that= 's the whole point of layering. By forcing important aspects of ILP lik= e the condition, fulfillment and expiry down into those layers you muddy th= e waters and we now have to standardize those protocols too. Instead we sho= uld just be defining the functions they must provide and then leave it up t= o implementations to provide those functions.

    I know we want to define a standard to bootstrap the system (CLP= ) but that's misleading us into thinking it's an essential part of = the stack. It's perfectly valid for two peers to not use CLP and still = be part of the Interledger.

    <= div class=3D"gmail_quote">
    That said, you raise an interesting consider= ation about the layers below ILP and actually I think it makes sense to spl= it these.

    We keep trying to force messaging through the l= edger layer and actually that's the wrong place to put it if we can spl= it the ledger layer into a messaging layer and a ledger layer. That way we = can stop trying to think of all HLTAs as ledgers.

    A thoug= ht, why not use sub-layers as is common in other stacks:

    = 1. Link layer: Layer upon which two peers that have a direct link, or parti= cipate in the same payment network, communicate
    2. Transfer/ = ledger: Layer on which financial positions between two peers are recorded
    This reflects the already emerging HTLA model and many of our existin= g plugins and ledger integrations.
    Link Layer: XRP Paychan, L= ightning
    Ledger Layer: XRP Ledger, Bitcoin

    =
    This doesn't prevent us from defining a standard binary prot= ocol that defines all of the operations for both layers (like CLP) but I se= e value in distinguishing between these two.
    =C2=A0

    >=C2=A0- The protocol should= differentiate between the operation of preparing a transfer on a ledger an= d the operation of passing an ILP packet from one peer to another.
    The protocol assumes your= conditional transfer is underpinned by some HTLA. It doesn't care wheth= er that's on-ledger or not.

    What do you mean when you say "the protocol"? In my statement = I am referring to ILP.
    My point above being that ILP expects ILP packet= s to be passed from peer to peer but has no expectations about transfers.
    It's perfectly legal (from an IL= P perspective) for two peers to exchange ILP packets with no transfers. Cle= arly if a node routes a packet on and has no incoming transfer it's goi= ng to lose money but that's a consideration for that node. It doesn'= ;t affect anyone else in the chain.
    ILP doesn't assume anything about transfers at all, let alone conditio= nal transfers. It provides useful semantics for conditional transfers to be= used by two peers to transact as part of a larger ILP payment.
    =C2=A0

    >=C2=A0- The condition and timeout should be included in the ILP= payment packet.

    I strongly disagree= with this. We had this debate a year ago and I was on your side but was co= nvinced that this is not a good idea.

    Yes, I recall this and I'm sorry I didn't push harder= on this point. Unfortunately I think the decision to pull it out of the pa= cket is mostly driven by how our prototypes were implemented rather than go= od architecture.

    The layer below ILP must be capable of doin= g conditional transfers based on sha256 hashlocks with 32-byte preimages. <= /div>

    This is not true and I t= hink it would be useful for us to agree on this as this seems to be the arg= ument I am coming up against most often. The peers participating in a trans= fer that is part of an ILP payment may wish to use conditional transfers as= a way to enforce their agreement but this is not a requirement of the prot= ocol.

    The agreement between any two peers is: "I wil= l pay you X if you can provide a receipt that Y was paid Z before T".<= br>
    ILP provides a standard for expressing this agreement so that= these can be chained together BUT it is not a requirement that every agree= ment in the chain uses the condition, and fulfillment provided at the ILP l= ayer.

    =C2=A0
    As a result, the original condition and the corresponding p= reimage MUST be expressed in that layer.

    =
    As I have shown above, this is not true.
    <= div>=C2=A0
    Then the question is whether we should also include it in the packet that = is forwarded. What ultimately convinced me is the following: All connectors= MUST ignore the condition if it is in the packet, because they are only gu= aranteed their money back if they use the same condition from the incoming = transfer they got.

    Here is where the layering is being corrupted.

    All= connectors MUST inspect the condition in the ILP packet as part of their d= ecision to route the packet or not.
    Whe= n the local transfer module of the connectors stack passes the ILP packet u= p to the ILP module it should indicate the properties of the incoming trans= fer that carried the packet.
    This is es= sential firstly so that the routing logic in the ILP module can record the = incoming transfer identifier so it is able to use the correct response id w= hen it passes back the fulfillment or error.
    The other properties that t= he ILP module should look at are the condition and expiry on the incoming t= ransfer.

    If the inc= oming route uses conditional transfers and these are supposed to match the = condition and expiry in the ILP packet then the ILP module should compare t= hem and reject the packet if:
    a) the conditions don't mat= ch OR
    b) the expiry is too short

    We should = still discuss if the expiry should be set by the sender and left unchanged = or used like a TTL and decremented by each node.
    =C2=A0=
    Also, the= receiver will need to take out the condition in order to hash the packet f= or PSK or IPR.

    This is = completely normal. Zeroing a checksum field in a header before calculating = the checksum is VERY common precisely because it's long been accepted t= hat the right place to put that data is in the headers and the work of zero= 'ing it out to calculate the checksum (or signature in our case) is not= material.
    =C2=A0
    So basically, no one wants the condition in the= re. It feels like it ought to be in there, but literally none of the partie= s want the extra 32 bytes in there.

    =
    "Nobody wants it there" is a terrible reason to aband= on the correct design. The whole purpose of a good architecture is you acce= pt that there may be cases in future that haven't been considered now s= o designing just for the known cases is a bad idea.

    Good = architecture is not the same as optimization. Taking stuff out (even when i= t feels wrong) to save a few bytes is a good sign that it's a bad idea.=
    =C2=A0

    The reason the timeout should not be in th= ere is that there isn't a single timeout for the payment. There are mul= tiple separate timeouts for each of the bilateral transfers. Those must go = in the individual transfers and there is no sensible value to put in the In= terledger packet.
    =C2=A0
    As a= bove, this is somewhat equivalent to the TTL in an IP packet. I'm open = to discussing if it should be a fixed value set by the sender where each no= de uses their own value but has the sender-defined value as a reference or = it is actually decremented at each hop.

    Either way, this = is part of ILP not the ledger layer just like the condition and fulfillment= . It may be used by the ledger layer but that's implementation specific= . It belongs in the ILP packet.
    =C2=A0





    --
    Sent from a mobile device, please excuse any typos


    --001a1142a1d0a66f4e0556f666ef-- From nobody Fri Aug 18 02:38:21 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4532513293F for ; Fri, 18 Aug 2017 02:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=ripple.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 30H2a8OzSgzp for ; Fri, 18 Aug 2017 02:38:11 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 B9093132944 for ; Fri, 18 Aug 2017 02:38:08 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id b65so65300711wrd.0 for ; Fri, 18 Aug 2017 02:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HiPLNfKLVnupywolWwUKMICWkJjsuvz8ZwsGVmSHQfc=; b=jNy91K88M1sNnGpjxyESHijAF1Q6RKVObfwwST4uMsJZvc5+JSMFCUh4BwxsR1FiRV uTlm8opgrl+49U0iqra13EnaWblbWxxnsJSDZz6l22HpK1OJ8VNSXIhD7hiqwGHOZUp4 wfFaeboPKb96oQD4tNsV8pAF9j7cz307Oq7pk= 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=HiPLNfKLVnupywolWwUKMICWkJjsuvz8ZwsGVmSHQfc=; b=bXEqfqTqWlhyY0NFTU4A4DjM+PJrULk+sHySxzIoDswDcyBsKcyXf65Kob35CMf6NG DAO8WHNRr5XiA6Jj62AtMulRnHme52JqNuhsMfFgAK8E+9TOVpB9DwRi/+lC5KBW+SOQ J1i+ll3dErm2CFcyZu5BXSsiAyBCWkFAFAEFsshw4dqbMIj9Cjr99kDNytgXqpwP+t5Y GTkSX5e8qafIcjBi3Pv7s/CftTWZdczIVPb1cVWAI9OeG5oLtObV66D2GWYyB366L+M1 StPwpUpEK5UZYPHPEdLSWaRTyfQNqmNi0XpViI3zpNIU9N984uUStw2gU8YqKT5W+YWp X3YA== X-Gm-Message-State: AHYfb5juq/UxisRd+6XX3MJgx4UIp/b8BAUNGQb80eU+snLy3MIEDMJb DszBmH9fDbKKBn1cNoWSgRCzKc6y1bgi X-Received: by 10.223.170.12 with SMTP id p12mr5841555wrd.238.1503049086948; Fri, 18 Aug 2017 02:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.60.135 with HTTP; Fri, 18 Aug 2017 02:38:06 -0700 (PDT) In-Reply-To: References: From: Ben Sharafian Date: Fri, 18 Aug 2017 11:38:06 +0200 Message-ID: To: Adrian Hope-Bailie Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="94eb2c1cd75ee872aa055703e2c9" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 09:38:19 -0000 --94eb2c1cd75ee872aa055703e2c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Two connectors exchanging a transfer only care about the data that is > relevant to them for that transfer. It's quite possible for two connector= s > to perform a transfer that has no conditions or fulfillments or a transfe= r > that has a different condition and fulfillment (such as an atomic mode > transfer where the condition is a compound one that has multiple > sub-conditions). Yes, two connectors could absolutely send an unconditional transfer on an underlying ledger in order to settle an Interledger payment. But in order to benefit from any of Interledger's guarantees (trustless connectors, retry-ability, etc.), they MUST keep a conditional local transfer, at least for clearing. If the local transfer cannot time out, it cannot be safely retried. If the local transfer clears without a fulfillment, it loses the "receipt or your money back" property. Yes, two parties in the chain could eschew these benefits but that is no longer a correct implementation of Interledger. If a protocol at a lower layer wants to use that data then it must > replicate it. That seems inefficient but it's the correct way to do it. What's the actual reasoning behind this, and why is it considered the correct approach? If there's some IETF document that says this I'd like to see it, because it intuitively feels wrong to have lower level abstractions looking into higher levels. Routing requires looking at the condition, expiry and amount. A connector's > routing logic shouldn't forward a packet if the expiry is too low or if t= he > condition is obviously corrupted. Those are validity checks and you're right that they are performed in the connector, but the destination account, destination amount, and data are enough to figure out what the best next hop is. The ILP Packet's purpose is to describe where a payment is going. The data it carries is only for the purpose of making sure the receiver can identify that payment. In that context, the expiry has no bearing on where it will be routed nor on how much to route, only on whether or not an individual connector will take the risk of forwarding it. The ILP packet just contains the end-to-end condition (always a SHA-256 > hash) and then the local transfer can have a different condition that is > derived from the condition in the ILP packet. Fair enough; in your case you can transmit the condition twice and verify the structure of the complex local condition, and in the no-condition-in-ILP version you can verify the structure of the local condition and extract the SHA256 condition to pass on. I think the expiry should always be the expiry set by the sender. It won't > be changed. That increases connector risk enormously, allowing anybody to cause a connector to lose money by submitting a fulfillment at the last moment. If an attacker knows enough about latency in the chain, they could even target this attack at somebody many hops away. Staggering expiries (giving you a minimum amount of time to fulfill a source transfer) is an easy mitigation against this attack; we shouldn't take it out. Comparing the condition in the local transfer and the one in the ILP packet > should be part of the routing logic. Sure, it can be done as an extra validity check, but it's just more code and more attack surface. I still don't see any tangible benefit from doing the layering in this way, aside from your assertion that it's the correct way to do it. If you've read any documents that explain why this is the correct way to do layering, I think I'd understand you better. On Thu, Aug 17, 2017 at 7:32 PM, Adrian Hope-Bailie wrote: > > > On 16 August 2017 at 10:22, Ben Sharafian wrote: > >> OK, I think in that case we're mostly disagreeing over where the >> condition/fulfillment/expiry actually go in the data. >> > > That's one way to look at it but that's ultimately what the architecting > the layering is. Deciding at which layer (and therefor encapsulated in wh= at > packet) certain data should be. > > >> The reason I don't agree with your position is based on which parties I >> think should be aware of ILP. >> > > I don't think that's the right way to look at it. The connector needs to > be able to understand at least the ILP layer data AND the lower layer dat= a. > Normally the way the processing stack is implemented is that there is a > module for each layer that processes the data from that layer and then > passes the payload and any other important information up to the next lay= er. > > >> In order to track the balance between each other accurately, the two >> connectors have to keep track of conditions, fulfillments, and expiries = on >> each of the transfers. >> > > This is where I disagree with you. Two connectors exchanging a transfer > only care about the data that is relevant to them for that transfer. It's > quite possible for two connectors to perform a transfer that has no > conditions or fulfillments or a transfer that has a different condition a= nd > fulfillment (such as an atomic mode transfer where the condition is a > compound one that has multiple sub-conditions). > > >> That means the connectors' accounting logic that handles the conditions, >> fulfillments, and expiries is going to be using some information inside = the >> ILP packet and some information outside of it in order to perform these >> transfers. >> > > It will only use info inside the packet if it uses conditional transfers > that use that same condition. This is the most likely scenario but that i= s > not a protocol requirement. > > >> >> I think it's cleaner to say everything required to make these local >> transfers should go in one protocol, so the accounting logic of these >> connectors doesn't have to deal with ILP directly. >> > > I strongly disagree with that. That's entirely the wrong reason to put > data into a specific layer. The data in the ILP layer is there because it= 's > "end-to-end" data. > > If a protocol at a lower layer wants to use that data then it must > replicate it. That seems inefficient but it's the correct way to do it. > > One could define a lower layer protocol that doesn't replicate the data > but the rules of the protocol are "Get the condition from the ILP packet"= . > In that case, that specific lower level protocol is forcing implementatio= ns > to understand the ILP packet format, that's an implementation detail. > > Another lower layer protocol might take the condition from the ILP packet > and re-encode it in a different form (like a base64ulr string or NI: uri) > > >> Then the connectors' ILP-packet-related behavior can all be routing >> related. >> > > Routing requires looking at the condition, expiry and amount. A > connector's routing logic shouldn't forward a packet if the expiry is too > low or if the condition is obviously corrupted. > > If the protocols were designed correctly as I am proposing then another > routing decision would be, is the condition that was used in the incoming > transfer the same as the one used in the ILP packet? > > > >> This would add a few benefits; two connectors could perform non-ILP >> conditional transfers between one another (which would be useful for >> reconciliation and settlement), and could also allow two connectors to u= se >> more complex condition types (i.e. signatures for atomic mode) without >> forcing us to support that in the ILP packet. >> > > You seem to have this backwards. Both of these things are supported if th= e > condition and expiry ARE in the ILP packet. Atomic mode is not supported = in > the ILP protocol it is supported in the lower layer transfer protocol. Th= e > ILP packet just contains the end-to-end condition (always a SHA-256 hash) > and then the local transfer can have a different condition that is derive= d > from the condition in the ILP packet. > > >> It also keeps the integrity of the ILP packet as something lower levels >> don't modify; the connector has to modify the expiry in order to pass al= ong >> an ILP payment (they may not modify the expiry if they're using somethin= g >> like atomic mode, but then we have the issue with advanced condition typ= es >> not being supported in the ILP packet). >> > > I think the expiry should always be the expiry set by the sender. It won'= t > be changed. > >> >> In the case where the ledger _does_ care about the condition and >> fulfillment, the argument in favor of separating >> condition/fulfillment/expiry from the rest of the packet is similar. >> Because we don't control the features of all ledgers, we'll need our >> plugins or ledger adapters to be aware of ILP. This makes it hard to >> interact with any events that don't involve ILP packets, and impossible = to >> handle features that extend beyond what we support in the ILP packet. We >> could pass details about non-ILP ledger features (like a crypto conditio= n) >> in the side data, but in the event of any redundancy we have to check th= e >> ledger-supplied info, not the info in the ILP packet. >> > > Comparing the condition in the local transfer and the one in the ILP > packet should be part of the routing logic. > > >> >> Basically, condition/fulfillment/expiry are used for accounting local >> transfers (even if they aren't being "ledger" enforced) in addition to >> their role as every-hop information. By putting them in the ILP packet, = we >> limit the special features that ledgers can support and make our softwar= e >> abstractions harder to separate cleanly. By putting them in the local >> transfer alongside the ILP packet but not inside it, we do separate the >> data a little more, but we have more freedom in what the underlying >> accounting and ledger logic can do, and our software modules will have m= ore >> clearly separated domains. >> > > They should be in both the local transfer AND the ILP packet if they are > needed by the local transfer protocol. This allows the flexibility you > desire because the local transfer protocol can do ANYTHING including usin= g > the condition from the ILP packet as-is, not at all or enhanced for > something like atomic mode. > > > >> >> On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie < >> adrian@hopebailie.com> wrote: >> >>> Exactly =F0=9F=91=8D >>> >>> On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian >>> wrote: >>> >>>> Ok, I think I have a better idea of what you're saying. >>>> >>>> It sounds like you're saying the ILP layer contains all information >>>> that is common between every hop (destination, destination amount, opa= que >>>> data, condition, fulfillment, expiry). The lower level would then be u= sed >>>> for all the transfer-local details (source amount, next connector acco= unt, >>>> custom/local data). >>>> >>>> If the lower level wanted to do anything related to the every-hop >>>> payment, i.e. escrow funds until the receipt has been produced, it wou= ld >>>> look into the ILP layer for that information. If the lower level didn'= t do >>>> any escrow or expiries that require every-hop details, it would simply >>>> function as a communication method. >>>> >>>> Is that right? >>>> >>>> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >>>> adrian@hopebailie.com> wrote: >>>> >>>>> >>>>> >>>>> On 15 August 2017 at 16:00, Ben Sharafian >>>>> wrote: >>>>> >>>>>> In that case, the plugin or whatever is doing the accounting is the >>>>>>>>> ledger. Digital value is always tracked in ledgers, so I think it= does make >>>>>>>>> sense to think of this as the base layer. The reason to abstract = the >>>>>>>>> functionality you expect from the ledger layer is precisely so yo= u can >>>>>>>>> handle it in different ways, depending on what the underlying sys= tems >>>>>>>>> provide. >>>>>>>> >>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>> >>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>>> some type of HTLA >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 1. There are separate plugins for messaging and for transfers >>>>>>>> and when you peer with someone you have to agree on a plugin fo= r each >>>>>>>> >>>>>>>> >>>>>>>> 1. We standardize the messaging part and say that all goes over >>>>>>>> IP and then just have more minimal plugins for the on-ledger se= ttlements >>>>>>>> >>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>> sense. >>>>>>> >>>>>>> >>>>>> I think you're confusing implementation details and defining of >>>>>>> interfaces with definition of a protocol stack. The only difference= s >>>>>>> between the tree examples you have above is in implementation. >>>>>> >>>>>> >>>>>> I had to scroll up after reading this to make sure it was @adrian >>>>>> talking, because that seems like the opposite of what you were argui= ng for. >>>>>> >>>>> >>>>> I don't think so. But I think that is part of the problem. We are not >>>>> all focused on the same thing. I am actually not very interested in C= LP at >>>>> all. It is one of potentially many protocols that may exist below the= ILP >>>>> layer. All we're doing by defining CLP is bootstrapping the network b= y >>>>> defining a protocol for everyone to use to get started. >>>>> >>>>> In designing the ILP layer properly we should try and forget >>>>> everything we know about the lower layers other than what features we >>>>> require of them. >>>>> >>>>> There is a misconception that ILP requires the lower layers to suppor= t >>>>> conditional transfers, that is not true. >>>>> >>>>> All we actually need from a lower layer protocol is to transfer data >>>>> back and forth and provide a way to reliably map requests to response= s. >>>>> >>>>> What ILP provides lower layers is a way to reward your peer for >>>>> passing on the packet. The Internetworking layer defines a condition,= a >>>>> reward that must be paid to the receiver for the fulfillment and the = time >>>>> allowed to claim this reward. >>>>> >>>>> Because of this, within lower-layer protocols that offer the basic >>>>> request/response features we need, we could add conditional payment >>>>> semantics that use the condition, expiry and fulfillment provided by = ILP. >>>>> This would allow a node to offer a reward to their next peer to for >>>>> delivering the packet they send them and to make the local financial >>>>> transaction contingent on the end-to-end transaction. >>>>> >>>>> But crucially, adding that semantic to the lower layer protocol >>>>> provides nothing extra to the ILP layer. The value is purely derived = from >>>>> the two peers who use that protocol and can now use conditional payme= nts to >>>>> protect themselves from their peers. >>>>> >>>>> >>>>>> The proposal that you're arguing for is basically asserting that >>>>>> we're going to be using CLP, because it makes the assumption that th= e >>>>>> connectors (who understand ILP) are managing the HTLA logic. >>>>>> >>>>> >>>>> Not at all. I am asserting that it doesn't matter what protocol you >>>>> use below the ILP layer because it shouldn't matter. All of this talk= about >>>>> ILP being different because money is more important than data is nons= ense. >>>>> >>>>> The difference between ILP and IP that makes ILP suitable for value >>>>> transfer and IP not is at the internetworking layer. ILP requires tha= t all >>>>> packets are either a request or response and that the responses follo= w the >>>>> same path as the requests. Further ILP defines a signature scheme tha= t >>>>> gives the sender a way to be certain the request was received by the >>>>> receiver. >>>>> >>>>> *This could be done entirely without money* but then there would be >>>>> little incentive to sign the receipt or deliver the signature back to= the >>>>> original sender. >>>>> >>>>> So, if you add money then you add economic incentives to the mix. At >>>>> each hop the sender promises the next upstream peer a payment if they= can >>>>> return the receipt. The net effect is that this can be used to transf= er >>>>> money from the sender to the receiver by simply defining up front the >>>>> amount that the receiver must get to produce the signature. >>>>> >>>>> >>>>>> >>>>>> In the current model, the CLP/trustline model and the direct ledger >>>>>> model both work without having to treat anything on the ILP layer >>>>>> differently. We're favoring on-ledger messaging because of our >>>>>> implementation, yes, but we've been able to switch most all of our p= lugins >>>>>> from on-ledger messaging to RPC-based messaging without changing the= ILP >>>>>> layer at all. >>>>>> >>>>>> With the ledger-level abstraction, we were able to switch from our >>>>>> ledger-based mode of thinking to the CLP/trustline based way without >>>>>> changing anything other than the plugin. Your argument comes from an >>>>>> assumption of a CLP-style ledger protocol with some underlying ledge= r, >>>>>> which we can't assume is always the case. >>>>>> >>>>> >>>>> I'm not sure what any of that proves tbh. These are all implementatio= n >>>>> concerns. They don't change the fact that the condition, expiry and >>>>> fulfillment are part of ILP not the lower layer protocols. >>>>> >>>>>> >>>>>> >>>>>> From the perspective of the Interledger Protocol the implementation >>>>>>> of the lower layers is not important, that's the whole point of lay= ering. >>>>>>> By forcing important aspects of ILP like the condition, fulfillment= and >>>>>>> expiry down into those layers you muddy the waters and we now have = to >>>>>>> standardize those protocols too. Instead we should just be defining= the >>>>>>> functions they must provide and then leave it up to implementations= to >>>>>>> provide those functions. >>>>>> >>>>>> >>>>>> I don't agree with this point; the condition and fulfillment have >>>>>> actual meaning to the ledger layer. >>>>>> >>>>> >>>>> NO THEY DON'T! They have meaning to SOME ledgers that implement SOME >>>>> lower layer protocols, IF they choose to use them. >>>>> >>>>> Excuse the shouting but this is the crux of the issue. We need to all >>>>> agree that it is entirely possible for a transfer to be done that doe= sn't >>>>> use the condition and fulfillment and that if this was in the middle = of a >>>>> 10-hop ILP payment it would have no effect on the sender and receiver= . >>>>> >>>>>> >>>>>> You've said that the ledger often doesn't care about fulfillment and >>>>>> condition, but the ledger _layer_'s (where transfers are done) role = is to >>>>>> take in condition and fulfillment and make a transfer which satisfie= s its >>>>>> HTLA. >>>>>> >>>>> >>>>> No, the ledger's role is to keep a tab of net financial positions >>>>> between two peers. It MAY use conditions and fulfillments that it pul= ls >>>>> from the ILP layer to help it do that in a way both peers agree on. >>>>> >>>>> Note that a "layer" doesn't have a role. I think there is some >>>>> confusion about the difference between layering the protocol and >>>>> abstracting functionality into different components. >>>>> >>>>> >>>>>> If the ledger layer has to look into the ILP packet to do so, that i= s >>>>>> a blatant breaking of layering. >>>>>> >>>>> >>>>> Not at all! The module acting at the layers *below* the >>>>> internetworking layer shouldn't modify anything inside the packets of= the >>>>> higher layers but they can definitely inspect them and adjust their >>>>> behavior based on what they to find. >>>>> >>>>> In fact the prevalence of this is the subject of a lot of debate at >>>>> the IETF currently because endpoints are often encrypting their paylo= ads >>>>> and in some cases this makes it difficult for middle-boxes to be effe= ctive >>>>> at their jobs. >>>>> >>>>> By putting the condition, fulfillment, and expiry on the ledger layer= , >>>>>> we leave it open for any ledger type to work, rather than forcing al= l >>>>>> ledger-layer software to understand ILP. >>>>>> >>>>> >>>>> Actually you do the opposite. You make it a requirement of every >>>>> protocol below the ILP layer to define a way to carry these data elem= ents >>>>> and encode and decode them, even if they don't use them >>>>> >>>>> Ledger layer components don't have to understand ILP unless they >>>>> choose to re-use the condition for their own local transfer. Ledgers >>>>> themselves *never* have to understand ILP. >>>>> >>>>> Remember a ledger layer protocol could use a completely different >>>>> conditional payments scheme, like atomic mode ILP, where it takes the >>>>> end-to-end condition and creates a new compound condition that depend= s on >>>>> the fulfillment and some notary signature. >>>>> >>>>> There will be a component in a connector's stack that must pass the >>>>> ILP packet to the next peer. If it does this using a transfer protoco= l that >>>>> uses conditional transfers and wants to use the same condition as the= ILP >>>>> packet then it must decode the packet. >>>>> >>>>> But, it will likely do something with that condition before sending >>>>> the transfer to the ledger like encoding it differently or rehashing = it >>>>> (lightning?) so that it's in the form expected by the ledger. >>>>> >>>>> That's an implementation decision of the lower layer protocol used >>>>> between those two peers. >>>>> >>>>> >>>>>> >>>>>> I agree that Interledger defines how conditions, fulfillments, and >>>>>> expiries should be chained together, but it makes no assertions abou= t their >>>>>> data format. >>>>>> >>>>> >>>>> ILP doesn't define how anything is chained together. From the >>>>> perspective of ILP the condition and fulfillment are end-to-end data.= They >>>>> are agreed by the two endpoints who don't care how they get from Alic= e to >>>>> Bob and back. >>>>> >>>>> The design of ILP is such that it facilitates the design of lower >>>>> level protocols that can be used to carry the ILP packets across mult= iple >>>>> hops (networks) using economic incentives such that the sender pays e= nough >>>>> for the first hop to ensure that all nodes in between can extract the= fee >>>>> they want and the receiver will still get the amount they expected.. >>>>> >>>>> >>>>> >>>>>> ILP says you should send your outgoing transfer with the same >>>>>> condition as the incoming one, and a lower expiry. >>>>>> >>>>> >>>>> No it doesn't. An internetworking protocol can't prescribe that kind >>>>> of thing to lower level protocols. An incoming and outgoing transfer = could >>>>> be sent using completely different protocols and the financial agreem= ent >>>>> with the peers on those two routes could be vastly different too. >>>>> >>>>> The only service ILP requires of lower level protocols is that they >>>>> can map a response to an original request. This requirement is okay b= ecause >>>>> it is isolated to a single route/link at a time not a requirement tha= t >>>>> crosses the inter-network boundary that ILP crosses. >>>>> >>>>> >>>>>> But because ILP allows for many different types of ledgers, it >>>>>> doesn't make sense to assert how these are encoded. >>>>>> >>>>> >>>>> By putting them in the ILP packet you do the opposite. You make no >>>>> assertions about how they are encoded if they are used at lower layer= s, or >>>>> how they may be combined with other conditions or even used to derive= new >>>>> conditions. >>>>> >>>>>> >>>>>> IP doesn't tell you how to encode an ethernet packet. It doesn't eve= n >>>>>> know whether it's going over a computer or a hand-written letter car= ried by >>>>>> a pigeon. IP takes for granted that you can send data over one conne= ction >>>>>> by putting it in a lower level. >>>>>> >>>>> >>>>> Correct, but if a link layer protocol wanted to look into the IP >>>>> packet headers of a packet it wants to transfer and use some data fro= m >>>>> there in its internal logic (or even reuse data in it's own frame) th= at >>>>> would be totally fine. >>>>> >>>>> >>>>>> Even though IP tells you how to chain these connections together, it >>>>>> doesn't have to put the things it's chaining on the internetworking = level. >>>>>> >>>>> >>>>> IP doesn't tell you how to chain things together. IP simply defines >>>>> the end-to end data envelope and address space. Because of this nodes= that >>>>> implement the multiple lower layer protocols are able to push IP pack= ets >>>>> down a link and expect the node on the other side to understand the h= eaders >>>>> and route it onward on another link. >>>>> >>>>> Everything needed by the IP module to decide what to do with the >>>>> packet is in the IP packet headers. i.e. Has it exceeded a TTL? Is th= ere a >>>>> route for this destination? Is it corrupted (checksum fails)? But als= o, >>>>> everything that is needed by the endpoint (like the source address) i= s also >>>>> in there. >>>>> >>>>> There is no dependency on nodes to be good citizens and always pass >>>>> certain other data from the lower layers into the next link. That wou= ld be >>>>> breaking the layering. >>>>> >>>>> >>>>>> IP also assumes that if you get some incoming data on a connection >>>>>> you can copy it and send it out on the next connection. Because you = can >>>>>> already send data over a connection, all IP adds is the missing piec= e: a >>>>>> packet that tells you where to go. >>>>>> >>>>>> With ILP, we assume that there is a way to prepare a conditional >>>>>> transfer, expire a conditional transfer, and fulfill a conditional >>>>>> transfer. >>>>>> >>>>> >>>>> No we don't! We assume that if we deliver the packet as intended we'l= l >>>>> get back a response packet with a signature that matches the conditio= n in >>>>> the packet. So, if we have an agreement with someone that they will p= ay us >>>>> when we present that signature then we are prepared to enter a simila= r >>>>> agreement with the next peer because we expect that signature to come= all >>>>> the way back along the interledger layer route.. >>>>> >>>>> >>>>>> We also assume that if you get an incoming transfer you can create a= n >>>>>> outgoing transfer with the same condition. The abstraction we made m= eans >>>>>> that conditions and fulfillments are already carried in the lower le= vels. >>>>>> >>>>> >>>>> That is a bad assumption that comes from the broken layering. What if >>>>> my outgoing link doesn't support conditional transfers? So now where = do I >>>>> put the condition? >>>>> >>>>>> >>>>>> >>>>>> We could have assumed that no ledgers ever support conditional >>>>>> transfers, and said the only thing ILP gets from lower levels is the >>>>>> ability to send a transfer. But if we want to support the case where= any of >>>>>> them do, we have to keep the conditions and fulfillments in the laye= r where >>>>>> they're actually used. >>>>>> >>>>> >>>>> I don't follow that logic at all. If we want to support the case wher= e >>>>> any of them do then we must ensure the condition and expiry are alway= s >>>>> carried in a consistent place at the internetworking layer so that if= they >>>>> do want to use them they know where to find them. >>>>> >>>>> >>>>>> >>>>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>>>> adrian@hopebailie.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 14 August 2017 at 22:03, Evan Schwartz wrote: >>>>>>> >>>>>>>> I think this thread is going to get extremely unwieldy but here >>>>>>>> goes: >>>>>>>> >>>>>>>> > - All interledger layer messages should be ILP packets >>>>>>>> (including fulfillments) and be capable of carrying higher layer p= rotocol >>>>>>>> payloads. >>>>>>>> >>>>>>>> Interledger has higher requirements than ILP for the lowest layer, >>>>>>>> specifically because we are carrying money and not just data. One = of the >>>>>>>> requirements is being able to transmit a 32-byte fulfillment back = along the >>>>>>>> same path that carried the payment originally. If we expect this o= f the >>>>>>>> lower layer, I don't see a point in putting the fulfillment into a= n ILP >>>>>>>> packet and transmitting it as Interledger data along the same path= . All >>>>>>>> ledger-layer protocols will need to interpret the fulfillment pass= ed in >>>>>>>> their protocol, not the one passed through the Interledger layer. >>>>>>>> >>>>>>> >>>>>>> This is not correct. There is no requirement on ledger layer >>>>>>> protocols to transmit or understand the fulfillment. You are lookin= g at >>>>>>> this through the lens of existing implementations from the bottom u= p >>>>>>> instead of starting at the interledger layer. >>>>>>> >>>>>>> The primary function of the condition and fulfillment is as a signe= d >>>>>>> end-to-end receipt. If the sender agrees a condition with a receive= r and >>>>>>> then gets back the valid fulfillment they don't care what happened = in the >>>>>>> middle. The receiver has signed a receipt saying they have their mo= ney. >>>>>>> >>>>>>> The value of using a standard for the receipt and signature is that >>>>>>> each transfer along the way CAN re-use it. One the one hand you can= have a >>>>>>> transfer between two peers that have zero trust and the ledger they= use >>>>>>> supports conditional payments completely. On the other extreme you = can have >>>>>>> two peers that have a full trust and ignore the condition and fulfi= llment >>>>>>> completely. >>>>>>> >>>>>>> The ledger layer protocols carry ILP packets. Payment requests and >>>>>>> either fulfillment or error responses. If a ledger layer protocol w= ants to >>>>>>> use the condition and fulfillment for their own operations they can= extract >>>>>>> these from the ILP packets and use them. >>>>>>> >>>>>>> >>>>>>>> > - While it may make sense to split the interledger payment and >>>>>>>> interledger quoting protocols into new higher level protocols that= seems >>>>>>>> like an unnecessary abstraction. Instead the packet definitions sh= ould just >>>>>>>> have some consistency and probably a common base/header. >>>>>>>> >>>>>>>> The current protocols effectively have this header but it isn't >>>>>>>> separated out. There are two fields in the request header: type an= d >>>>>>>> destination address. There is one field in the response header: ty= pe. I >>>>>>>> don't think it makes that much of a big difference to separate the= se fields >>>>>>>> if all of the fields in that packet need to be interpreted togethe= r (for >>>>>>>> example, you can't understand a quote request if you strip off the >>>>>>>> destination address). >>>>>>>> >>>>>>> >>>>>>> I agree that we don't HAVE to explicitly separate them out but I >>>>>>> think ti would make it clearer how the stack is architected if ther= e was a >>>>>>> header that was consistent across all packets. Currently the only t= hing >>>>>>> that is consitent across all ILP packets is that they are defined i= nt he >>>>>>> same file. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> > - We should define two base ILP packet types: request and >>>>>>>> response. >>>>>>>> >>>>>>>> Unless this adds some substantive benefit or new fields I don't >>>>>>>> think it's worth breaking all of the formats we have just to rearr= ange >>>>>>>> things. >>>>>>>> >>>>>>> >>>>>>> The goal of this exercise is to tease out the best design and ignor= e >>>>>>> the cost of change until we can compare the results with the curren= t design. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>>>> nodes/hosts. >>>>>>>> >>>>>>>> A ledger is any system that tracks accounts and balances. When you >>>>>>>> use a trustline all of your messages still need to go through an a= ccounting >>>>>>>> system (such as the plugin in the JS implementation) and then on t= o the >>>>>>>> other program logic. >>>>>>>> >>>>>>> >>>>>>> As above, this is incorrect. There is no requirement for "all >>>>>>> messages to go through an accounting system". >>>>>>> >>>>>>> Since designing the first implementation of 5-bells ledger we have >>>>>>> assumed that passing the ILP packet MUST be done by the ledger beca= use that >>>>>>> is how we implemented it. But that is not true. It is perfectly val= id for >>>>>>> the passing of an ILP packet from one peer to another to be simply = an >>>>>>> exchange of data. >>>>>>> >>>>>>> The receiving peer makes a decision about whether or not to forward >>>>>>> the packet based on the current financial position they have with t= he >>>>>>> sending peer. >>>>>>> >>>>>>> It is convenient if the ledger that records the net positions of th= e >>>>>>> peers also forwards the messaging and even better if it natively su= pports >>>>>>> conditional payments and can use the condition and the fulfillment = from the >>>>>>> ILP packet for those but that's all it is, convenient. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> In that case, the plugin or whatever is doing the accounting is th= e >>>>>>>> ledger. Digital value is always tracked in ledgers, so I think it = does make >>>>>>>> sense to think of this as the base layer. The reason to abstract t= he >>>>>>>> functionality you expect from the ledger layer is precisely so you= can >>>>>>>> handle it in different ways, depending on what the underlying syst= ems >>>>>>>> provide. >>>>>>>> >>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>> >>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>>> some type of HTLA >>>>>>>> >>>>>>>> 2. There are separate plugins for messaging and for transfers >>>>>>>> and when you peer with someone you have to agree on a plugin fo= r each >>>>>>>> 3. We standardize the messaging part and say that all goes over >>>>>>>> IP and then just have more minimal plugins for the on-ledger se= ttlements >>>>>>>> >>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>> sense. >>>>>>>> >>>>>>> >>>>>>> I think you're confusing implementation details and defining of >>>>>>> interfaces with definition of a protocol stack. The only difference= s >>>>>>> between the tree examples you have above is in implementation. >>>>>>> >>>>>>> From the perspective of the Interledger Protocol the implementation >>>>>>> of the lower layers is not important, that's the whole point of lay= ering. >>>>>>> By forcing important aspects of ILP like the condition, fulfillment= and >>>>>>> expiry down into those layers you muddy the waters and we now have = to >>>>>>> standardize those protocols too. Instead we should just be defining= the >>>>>>> functions they must provide and then leave it up to implementations= to >>>>>>> provide those functions. >>>>>>> >>>>>>> I know we want to define a standard to bootstrap the system (CLP) >>>>>>> but that's misleading us into thinking it's an essential part of th= e stack. >>>>>>> It's perfectly valid for two peers to not use CLP and still be part= of the >>>>>>> Interledger. >>>>>>> >>>>>>> That said, you raise an interesting consideration about the layers >>>>>>> below ILP and actually I think it makes sense to split these. >>>>>>> >>>>>>> We keep trying to force messaging through the ledger layer and >>>>>>> actually that's the wrong place to put it if we can split the ledge= r layer >>>>>>> into a messaging layer and a ledger layer. That way we can stop try= ing to >>>>>>> think of all HLTAs as ledgers. >>>>>>> >>>>>>> A thought, why not use sub-layers as is common in other stacks: >>>>>>> >>>>>>> 1. Link layer: Layer upon which two peers that have a direct link, >>>>>>> or participate in the same payment network, communicate >>>>>>> 2. Transfer/ ledger: Layer on which financial positions between two >>>>>>> peers are recorded >>>>>>> >>>>>>> This reflects the already emerging HTLA model and many of our >>>>>>> existing plugins and ledger integrations. >>>>>>> Link Layer: XRP Paychan, Lightning >>>>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>>>> >>>>>>> This doesn't prevent us from defining a standard binary protocol >>>>>>> that defines all of the operations for both layers (like CLP) but I= see >>>>>>> value in distinguishing between these two. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> > - The protocol should differentiate between the operation of >>>>>>>> preparing a transfer on a ledger and the operation of passing an I= LP packet >>>>>>>> from one peer to another. >>>>>>>> >>>>>>>> The protocol assumes your conditional transfer is underpinned by >>>>>>>> some HTLA >>>>>>>> . >>>>>>>> It doesn't care whether that's on-ledger or not. >>>>>>>> >>>>>>> >>>>>>> What do you mean when you say "the protocol"? In my statement I am >>>>>>> referring to ILP. >>>>>>> My point above being that ILP expects ILP packets to be passed from >>>>>>> peer to peer but has no expectations about transfers. >>>>>>> >>>>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>>>> exchange ILP packets with no transfers. Clearly if a node routes a = packet >>>>>>> on and has no incoming transfer it's going to lose money but that's= a >>>>>>> consideration for that node. It doesn't affect anyone else in the c= hain. >>>>>>> >>>>>>> ILP doesn't assume anything about transfers at all, let alone >>>>>>> conditional transfers. It provides useful semantics for conditional >>>>>>> transfers to be used by two peers to transact as part of a larger I= LP >>>>>>> payment. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> > - The condition and timeout should be included in the ILP >>>>>>>> payment packet. >>>>>>>> >>>>>>>> I strongly disagree with this. We had this debate a year ago and I >>>>>>>> was on your side but was convinced that this is not a good idea. >>>>>>>> >>>>>>> >>>>>>> Yes, I recall this and I'm sorry I didn't push harder on this point= . >>>>>>> Unfortunately I think the decision to pull it out of the packet is = mostly >>>>>>> driven by how our prototypes were implemented rather than good arch= itecture. >>>>>>> >>>>>>>> >>>>>>>> The layer below ILP must be capable of doing conditional transfers >>>>>>>> based on sha256 hashlocks with 32-byte preimages. >>>>>>>> >>>>>>> >>>>>>> This is not true and I think it would be useful for us to agree on >>>>>>> this as this seems to be the argument I am coming up against most o= ften. >>>>>>> The peers participating in a transfer that is part of an ILP paymen= t may >>>>>>> wish to use conditional transfers as a way to enforce their agreeme= nt but >>>>>>> this is not a requirement of the protocol. >>>>>>> >>>>>>> The agreement between any two peers is: "I will pay you X if you ca= n >>>>>>> provide a receipt that Y was paid Z before T". >>>>>>> ILP provides a standard for expressing this agreement so that these >>>>>>> can be chained together BUT it is not a requirement that every agre= ement in >>>>>>> the chain uses the condition, and fulfillment provided at the ILP l= ayer. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> As a result, the original condition and the corresponding preimage >>>>>>>> MUST be expressed in that layer. >>>>>>>> >>>>>>> >>>>>>> As I have shown above, this is not true. >>>>>>> >>>>>>> >>>>>>>> Then the question is whether we should also include it in the >>>>>>>> packet that is forwarded. What ultimately convinced me is the foll= owing: >>>>>>>> All connectors MUST ignore the condition if it is in the packet, b= ecause >>>>>>>> they are only guaranteed their money back if they use the same con= dition >>>>>>>> from the incoming transfer they got. >>>>>>>> >>>>>>> >>>>>>> Here is where the layering is being corrupted. >>>>>>> >>>>>>> All connectors MUST inspect the condition in the ILP packet as part >>>>>>> of their decision to route the packet or not. >>>>>>> When the local transfer module of the connectors stack passes the >>>>>>> ILP packet up to the ILP module it should indicate the properties o= f the >>>>>>> incoming transfer that carried the packet. >>>>>>> This is essential firstly so that the routing logic in the ILP >>>>>>> module can record the incoming transfer identifier so it is able to= use the >>>>>>> correct response id when it passes back the fulfillment or error. >>>>>>> The other properties that the ILP module should look at are the >>>>>>> condition and expiry on the incoming transfer. >>>>>>> >>>>>>> If the incoming route uses conditional transfers and these are >>>>>>> supposed to match the condition and expiry in the ILP packet then t= he ILP >>>>>>> module should compare them and reject the packet if: >>>>>>> a) the conditions don't match OR >>>>>>> b) the expiry is too short >>>>>>> >>>>>>> We should still discuss if the expiry should be set by the sender >>>>>>> and left unchanged or used like a TTL and decremented by each node. >>>>>>> >>>>>>> >>>>>>>> Also, the receiver will need to take out the condition in order to >>>>>>>> hash the packet for PSK or IPR. >>>>>>>> >>>>>>> >>>>>>> This is completely normal. Zeroing a checksum field in a header >>>>>>> before calculating the checksum is VERY common precisely because it= 's long >>>>>>> been accepted that the right place to put that data is in the heade= rs and >>>>>>> the work of zero'ing it out to calculate the checksum (or signature= in our >>>>>>> case) is not material. >>>>>>> >>>>>>> >>>>>>>> So basically, no one wants the condition in there. It feels like i= t >>>>>>>> ought to be in there, but literally none of the parties want the e= xtra 32 >>>>>>>> bytes in there. >>>>>>>> >>>>>>> >>>>>>> "Nobody wants it there" is a terrible reason to abandon the correct >>>>>>> design. The whole purpose of a good architecture is you accept that= there >>>>>>> may be cases in future that haven't been considered now so designin= g just >>>>>>> for the known cases is a bad idea. >>>>>>> >>>>>>> Good architecture is not the same as optimization. Taking stuff out >>>>>>> (even when it feels wrong) to save a few bytes is a good sign that = it's a >>>>>>> bad idea. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The reason the timeout should not be in there is that there isn't = a >>>>>>>> single timeout for the payment. There are multiple separate timeou= ts for >>>>>>>> each of the bilateral transfers. Those must go in the individual t= ransfers >>>>>>>> and there is no sensible value to put in the Interledger packet. >>>>>>>> >>>>>>> >>>>>>> As above, this is somewhat equivalent to the TTL in an IP packet. >>>>>>> I'm open to discussing if it should be a fixed value set by the sen= der >>>>>>> where each node uses their own value but has the sender-defined val= ue as a >>>>>>> reference or it is actually decremented at each hop. >>>>>>> >>>>>>> Either way, this is part of ILP not the ledger layer just like the >>>>>>> condition and fulfillment. It may be used by the ledger layer but t= hat's >>>>>>> implementation specific. It belongs in the ILP packet. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> -- >>> Sent from a mobile device, please excuse any typos >>> >> >> > --94eb2c1cd75ee872aa055703e2c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Two connectors exchanging a transfer only care abo= ut the data that is relevant to them for that transfer. It's quite poss= ible for two connectors to perform a transfer that has no conditions or ful= fillments or a transfer that has a different condition and fulfillment (suc= h as an atomic mode transfer where the condition is a compound one that has= multiple sub-conditions).

    Yes, two = connectors could absolutely send an unconditional transfer on an underlying= ledger in order to settle an Interledger payment. But in order to benefit = from any of Interledger's guarantees (trustless connectors, retry-abili= ty, etc.), they MUST keep a conditional local transfer, at least for cleari= ng. If the local transfer cannot time out, it cannot be safely retried. If = the local transfer clears without a fulfillment, it loses the "receipt= or your money back" property. Yes, two parties in the chain could esc= hew these benefits but that is no longer a correct implementation of Interl= edger.

    If a protocol at a lower layer wants to = use that data then it must replicate it. That seems inefficient but it'= s the correct way to do it.

    What'= ;s the actual reasoning behind this, and why is it considered the correct a= pproach? If there's some IETF document that says this I'd like to s= ee it, because it intuitively feels wrong to have lower level abstractions = looking into higher levels.

    Routing requires lo= oking at the condition, expiry and amount. A connector's routing logic = shouldn't forward a packet if the expiry is too low or if the condition= is obviously corrupted.

    Those are v= alidity checks and you're right that they are performed in the connecto= r, but the destination account, destination amount, and data are enough to = figure out what the best next hop is.

    The ILP Pack= et's purpose is to describe where a payment is going. The data it carri= es is only for the purpose of making sure the receiver can identify that pa= yment. In that context, the expiry has no bearing on where it will be route= d nor on how much to route, only on whether or not an individual connector = will take the risk of forwarding it.

    The ILP p= acket just contains the end-to-end condition (always a SHA-256 hash) and th= en the local transfer can have a different condition that is derived from t= he condition in the ILP packet.

    Fair= enough; in your case you can transmit the condition twice and verify the s= tructure of the complex local condition, and in the no-condition-in-ILP ver= sion you can verify the structure of the local condition and extract the SH= A256 condition to pass on.

    I think the expiry should always be th= e expiry set by the sender. It won't be changed.=C2=A0

    That increases connector risk enormously, allowing anybody = to cause a connector to lose money by submitting a fulfillment at the last = moment. If an attacker knows enough about latency in the chain, they could = even target this attack at somebody many hops away. Staggering expiries (gi= ving you a minimum amount of time to fulfill a source transfer) is an easy = mitigation against this attack; we shouldn't take it out.
    Comparing the condition in the local transfer and the one in= the ILP packet should be part of the routing logic.

    Sure, it can be done as an extra validity check, but it= 9;s just more code and more attack surface.=C2=A0I still don't see any tangible benefit from doing the layering i= n this way, aside from your assertion that it's the correct way to do i= t. If you've read any documents that explain why this is the correct wa= y to do layering, I think I'd understand you better.
    <= span style=3D"font-size:12.8px">

    On Thu, Aug 17, 2017 at 7= :32 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote= :


    On 16 August 2017 = at 10:22, Ben Sharafian <sharafian@ripple.com> wrote:
    =
    O= K, I think in that case we're mostly disagreeing over where the conditi= on/fulfillment/expiry actually go in the data.

    That's one way to look at it but that&#= 39;s ultimately what the architecting the layering is. Deciding at which la= yer (and therefor encapsulated in what packet) certain data should be.
    <= /div>
    =C2=A0
    The reason I don't agree with you= r position is based on which parties I think should be aware of ILP.

    I don't think tha= t's the right way to look at it. The connector needs to be able to unde= rstand at least the ILP layer data AND the lower layer data. Normally the w= ay the processing stack is implemented is that there is a module for each l= ayer that processes the data from that layer and then passes the payload an= d any other important information up to the next layer.
    =C2=A0
    In order to track the balance between each ot= her accurately, the two connectors have to keep track of conditions, fulfil= lments, and expiries on each of the transfers.

    This is where I disagree with you. Two connectors = exchanging a transfer only care about the data that is relevant to them for= that transfer. It's quite possible for two connectors to perform a tra= nsfer that has no conditions or fulfillments or a transfer that has a diffe= rent condition and fulfillment (such as an atomic mode transfer where the c= ondition is a compound one that has multiple sub-conditions).
    =C2=A0
    That means the connectors' accounting logic= that handles the conditions, fulfillments, and expiries is going to be usi= ng some information inside the ILP packet and some information outside of i= t in order to perform these transfers.
    =
    It will only use info inside the packet if it uses co= nditional transfers that use that same condition. This is the most likely s= cenario but that is not a protocol requirement.
    <= div>=C2=A0

    I think it's cl= eaner to say everything required to make these local transfers should go in= one protocol, so the accounting logic of these connectors doesn't have= to deal with ILP directly.

    =
    I strongly disagree with that. That's entirely the wrong re= ason to put data into a specific layer. The data in the ILP layer is there = because it's "end-to-end" data.

    If a protoc= ol at a lower layer wants to use that data then it must replicate it. That = seems inefficient but it's the correct way to do it.

    = One could define a lower layer protocol that doesn't replicate the data= but the rules of the protocol are "Get the condition from the ILP pac= ket". In that case, that specific lower level protocol is forcing impl= ementations to understand the ILP packet format, that's an implementati= on detail.

    Another lower layer protocol might take the co= ndition from the ILP packet and re-encode it in a different form (like a ba= se64ulr string or NI: uri)
    =C2=A0
    Then th= e connectors' ILP-packet-related behavior can all be routing related. <= /div>

    Routing requires = looking at the condition, expiry and amount. A connector's routing logi= c shouldn't forward a packet if the expiry is too low or if the conditi= on is obviously corrupted.

    If the protocols were designed= correctly as I am proposing then another routing decision would be, is the= condition that was used in the incoming transfer the same as the one used = in the ILP packet?

    =C2=A0
    This would add a few benefits; two connectors could perform non-ILP condit= ional transfers between one another (which would be useful for reconciliati= on and settlement), and could also allow two connectors to use more complex= condition types (i.e. signatures for atomic mode) without forcing us to su= pport that in the ILP packet.

    You seem to have this backwards. Both of these things are sup= ported if the condition and expiry ARE in the ILP packet. Atomic mode is no= t supported in the ILP protocol it is supported in the lower layer transfer= protocol. The ILP packet just contains the end-to-end condition (always a = SHA-256 hash) and then the local transfer can have a different condition th= at is derived from the condition in the ILP packet.
    =C2=A0
    It also keeps the integrity of the ILP packet as somethin= g lower levels don't modify; the connector has to modify the expiry in = order to pass along an ILP payment (they may not modify the expiry if they&= #39;re using something like atomic mode, but then we have the issue with ad= vanced condition types not being supported in the ILP packet).
    <= /span>

    I think the expiry should always b= e the expiry set by the sender. It won't be changed.

    In the case where the ledger _does_ care about the condition and fulfillme= nt, the argument in favor of separating condition/fulfillment/expiry from t= he rest of the packet is similar. Because we don't control the features= of all ledgers, we'll need our plugins or ledger adapters to be aware = of ILP. This makes it hard to interact with any events that don't invol= ve ILP packets, and impossible to handle features that extend beyond what w= e support in the ILP packet. We could pass details about non-ILP ledger fea= tures (like a crypto condition) in the side data, but in the event of any r= edundancy we have to check the ledger-supplied info, not the info in the IL= P packet.

    Compari= ng the condition in the local transfer and the one in the ILP packet should= be part of the routing logic.
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    Basically, condition/fulfillment/exp= iry are used for accounting local transfers (even if they aren't being = "ledger" enforced) in addition to their role as every-hop informa= tion. By putting them in the ILP packet, we limit the special features that= ledgers can support and make our software abstractions harder to separate = cleanly. By putting them in the local transfer alongside the ILP packet but= not inside it, we do separate the data a little more, but we have more fre= edom in what the underlying accounting and ledger logic can do, and our sof= tware modules will have more clearly separated domains.
    <= /blockquote>

    They should be in both the local tra= nsfer AND the ILP packet if they are needed by the local transfer protocol.= This allows the flexibility you desire because the local transfer protocol= can do ANYTHING including using the condition from the ILP packet as-is, n= ot at all or enhanced for something like atomic mode.

    =C2=A0

    On Tue, Aug 15, 2017= at 10:24 AM, Adrian Hope-Bailie <adrian@hopebailie.com>= wrote:
    Exactly = =F0=9F=91=8D

    On Tue, Aug 15, 2017 at 6:52 PM= Ben Sharafian <sharafian@ripple.com> wrote:
    Ok, I think I have a better idea of what you're saying.
    It sounds like you're saying the ILP layer contains all inf= ormation that is common between every hop (destination, destination amount,= opaque data, condition, fulfillment, expiry). The lower level would then b= e used for all the transfer-local details (source amount, next connector ac= count, custom/local data).

    If the lower level want= ed to do anything related to the every-hop payment, i.e. escrow funds until= the receipt has been produced, it would look into the ILP layer for that i= nformation. If the lower level didn't do any escrow or expiries that re= quire every-hop details, it would simply function as a communication method= .

    Is that right?

    On Tue, Aug 15, 2017 at 6:35 PM, Adrian= Hope-Bailie <adrian@hopebailie.com> wrote:


    On 15 August 2017 at 16:00, Ben Sharafian <sharafian@ripple.com> wrote:
    In that case, the plugin or whatever is doing the accounting = is the ledger. Digital value is always tracked in ledgers, so I think it do= es make sense to think of this as the base layer. The reason to abstract th= e functionality you expect from the ledger layer is precisely so you can ha= ndle it in different ways, depending on what the underlying systems provide= .
    I see 3 ways to think of the layer(s) underpinning ILP:
      The "Ledger Layer" = provides both messaging capabilities and some type of=C2=A0HTLA<= /ol>
      1. There are separate plugins for messa= ging and for transfers and when you peer with someone you have to agree on = a plugin for each
      1. We standardiz= e the messaging part and say that all goes over IP and then just have more = minimal plugins for the on-ledger settlements
      Number 1 is what we = have and I think that still makes the most sense.

    I think you're confusing implementation detail= s and defining of interfaces with definition of a protocol stack. The only = differences between the tree examples you have above is in implementation.<= /span>

    I had to scroll up after read= ing this to make sure it was @adrian talking, because that seems like the o= pposite of what you were arguing for.

    I don't think so. But I think that is part of the proble= m. We are not all focused on the same thing. I am actually not very interes= ted in CLP at all. It is one of potentially many protocols that may exist b= elow the ILP layer. All we're doing by defining CLP is bootstrapping th= e network by defining a protocol for everyone to use to get started.
    In designing the ILP layer properly we should try and forget ev= erything we know about the lower layers other than what features we require= of them.

    There is a misconception that ILP requires the = lower layers to support conditional transfers, that is not true.

    All we actually need from a lower layer protocol is to transfer dat= a back and forth and provide a way to reliably map requests to responses.
    What ILP provides lower layers is a way to reward your pee= r for passing on the packet. The Internetworking layer defines a condition,= a reward that must be paid to the receiver for the fulfillment and the tim= e allowed to claim this reward.

    Because of thi= s, within lower-layer protocols that offer the basic request/response featu= res we need, we could add conditional payment semantics that use the condit= ion, expiry and fulfillment provided by ILP. This would allow a node to off= er a reward to=C2=A0 their next peer to for delivering the packet they send= them and to make the local financial transaction contingent on the end-to-= end transaction.

    But crucially, adding that semantic to t= he lower layer protocol provides nothing extra to the ILP layer. The value = is purely derived from the two peers who use that protocol and can now use = conditional payments to protect themselves from their peers.
    =C2=A0
    The proposal that you're arguing for is basically asserting that we&= #39;re going to be using CLP, because it makes the assumption that the conn= ectors (who understand ILP) are managing the HTLA logic.

    Not at all. I am asserting that it doesn&#= 39;t matter what protocol you use below the ILP layer because it shouldn= 9;t matter. All of this talk about ILP being different because money is mor= e important than data is nonsense.

    The difference between ILP = and IP that makes ILP suitable for value transfer and IP not is at the inte= rnetworking layer. ILP requires that all packets are either a request or re= sponse and that the responses follow the same path as the requests. Further= ILP defines a signature scheme that gives the sender a way to be certain t= he request was received by the receiver.

    This could be done entirely without money but then there would= be little incentive to sign the receipt or deliver the signature back to t= he original sender.

    So, if you add = money then you add economic incentives to the mix. At each hop the sender p= romises the next upstream peer a payment if they can return the receipt. Th= e net effect is that this can be used to transfer money from the sender to = the receiver by simply defining up front the amount that the receiver must = get to produce the signature.
    =C2=A0

    In the current model, the CLP/trust= line model and the direct ledger model both work without having to treat an= ything on the ILP layer differently. We're favoring on-ledger messaging= because of our implementation, yes, but we've been able to switch most= all of our plugins from on-ledger messaging to RPC-based messaging without= changing the ILP layer at all.

    With the ledger-le= vel abstraction, we were able to switch from our ledger-based mode of think= ing to the CLP/trustline based way without changing anything other than the= plugin. Your argument comes from an assumption of a CLP-style ledger proto= col with some underlying ledger, which we can't assume is always the ca= se.

    I'm not sure what any= of that proves tbh. These are all implementation concerns. They don't = change the fact that the condition, expiry and fulfillment are part of ILP = not the lower layer protocols.
    = =C2=A0

    From the per= spective of the Interledger Protocol the implementation of the lower layers= is not important, that's the whole point of layering. By forcing impor= tant aspects of ILP like the condition, fulfillment and expiry down into th= ose layers you muddy the waters and we now have to standardize those protoc= ols too. Instead we should just be defining the functions they must provide= and then leave it up to implementations to provide those functions.=

    I don't agree with this point; = the condition and fulfillment have actual meaning to the ledger layer.

    NO THEY DON'T! They hav= e meaning to SOME ledgers that implement SOME lower layer protocols, IF the= y choose to use them.

    Excuse the shouting but this is the= crux of the issue. We need to all agree that it is entirely possible for a= transfer to be done that doesn't use the condition and fulfillment and= that if this was in the middle of a 10-hop ILP payment it would have no ef= fect on the sender and receiver.
    =C2=A0
    You've said that the ledger ofte= n doesn't care about fulfillment and condition, but the ledger _layer_&= #39;s (where transfers are done) role is to take in condition and fulfillme= nt and make a transfer which satisfies its HTLA.
    <= div>
    No, the ledger's role is to keep a tab of net fina= ncial positions between two peers. It MAY use conditions and fulfillments t= hat it pulls from the ILP layer to help it do that in a way both peers agre= e on.

    Note that a "layer"= doesn't have a role. I think there is some confusion about the differe= nce between layering the protocol and abstracting functionality into differ= ent components.
    =C2=A0
    If the ledger layer has to look into the ILP packet to do so, th= at is a blatant breaking of layering.

    Not at all! The module acting at the layers below the= internetworking layer shouldn't modify anything inside the packets of = the higher layers but they can definitely inspect them and adjust their beh= avior based on what they to find.

    In fact the prevalence of th= is is the subject of a lot of debate at the IETF currently because endpoint= s are often encrypting their payloads and in some cases this makes it diffi= cult for middle-boxes to be effective at their jobs.

    <= div>
    By putting the condition, fulfillment, and expiry on the ledger la= yer, we leave it open for any ledger type to work, rather than forcing all = ledger-layer software to understand ILP.

    <= /div>
    Actually you do the opposite. You make it a requirement of= every protocol below the ILP layer to define a way to carry these data ele= ments and encode and decode them, even if they don't use them

    Ledger layer components don't have to understand ILP unless th= ey choose to re-use the condition for their own local transfer. Ledgers the= mselves never have to understand ILP.

    Remember a ledger laye= r protocol could use a completely different conditional payments scheme, li= ke atomic mode ILP, where it takes the end-to-end condition and creates a n= ew compound condition that depends on the fulfillment and some notary signa= ture.

    There will be a component in a connector's stac= k that must pass the ILP packet to the next peer. If it does this using a t= ransfer protocol that uses conditional transfers and wants to use the same = condition as the ILP packet then it must decode the packet.

    But, it will likely do something with that condition before sending the = transfer to the ledger like encoding it differently or rehashing it (lightn= ing?) so that it's in the form expected by the ledger.
    That's an implementation decision of the lower layer proto= col used between those two peers.
    =C2=A0

    I agree t= hat Interledger defines how conditions, fulfillments, and expiries should b= e chained together, but it makes no assertions about their data format.

    ILP doesn't define how= anything is chained together. From the perspective of ILP the condition an= d fulfillment are end-to-end data. They are agreed by the two endpoints who= don't care how they get from Alice to Bob and back.

    = The design of ILP is such that it facilitates the design of lower level pro= tocols that can be used to carry the ILP packets across multiple hops (netw= orks) using economic incentives such that the sender pays enough for the fi= rst hop to ensure that all nodes in between can extract the fee they want a= nd the receiver will still get the amount they expected..

    =C2=A0
    <= div>ILP says you should send your outgoing transfer with the same condition= as the incoming one, and a lower expiry.
    No it doesn't. An internetworking protocol can't= prescribe that kind of thing to lower level protocols. An incoming and out= going transfer could be sent using completely different protocols and the f= inancial agreement with the peers on those two routes could be vastly diffe= rent too.

    The only service ILP requires of lower level protocols is = that they can map a response to an original request. This requirement is ok= ay because it is isolated to a single route/link at a time not a requiremen= t that crosses the inter-network boundary that ILP crosses.
    =
    =C2=A0
    But because ILP allows for many different types of ledgers, it doesn'= t make sense to assert how these are encoded.
    =
    By putting them in the ILP packet you do the opposite= . You make no assertions about how they are encoded if they are used at low= er layers, or how they may be combined with other conditions or even used t= o derive new conditions.

    IP doesn't tell you how to enco= de an ethernet packet. It doesn't even know whether it's going over= a computer or a hand-written letter carried by a pigeon. IP takes for gran= ted that you can send data over one connection by putting it in a lower lev= el.

    Correct, but if a l= ink layer protocol wanted to look into the IP packet headers of a packet it= wants to transfer and use some data from there in its internal logic (or e= ven reuse data in it's own frame) that would be totally fine.
    =
    =C2=A0
    Even though IP tells you how to chain these connections together, i= t doesn't have to put the things it's chaining on the internetworki= ng level.

    IP doesn'= t tell you how to chain things together. IP simply defines the end-to end d= ata envelope and address space. Because of this nodes that implement the mu= ltiple lower layer protocols are able to push IP packets down a link and ex= pect the node on the other side to understand the headers and route it onwa= rd on another link.

    Everything needed by the IP module to= decide what to do with the packet is in the IP packet headers. i.e. Has it= exceeded a TTL? Is there a route for this destination? Is it corrupted (ch= ecksum fails)? But also, everything that is needed by the endpoint (like th= e source address) is also in there.

    There is no dependenc= y on nodes to be good citizens and always pass certain other data from the = lower layers into the next link. That would be breaking the layering.
    =C2=A0
    We also assume that if you get an incoming transfer you ca= n create an outgoing transfer with the same condition. The abstraction we m= ade means that conditions and fulfillments are already carried in the lower= levels.

    That is a bad a= ssumption that comes from the broken layering. What if my outgoing link doe= sn't support conditional transfers? So now where do I put the condition= ?
    =C2=A0

    We could have assumed that no ledgers ever support c= onditional transfers, and said the only thing ILP gets from lower levels is= the ability to send a transfer. But if we want to support the case where a= ny of them do, we have to keep the conditions and fulfillments in the layer= where they're actually used.

    I don't follow that logic at all. If we want to support the c= ase where any of them do then we must ensure the condition and expiry are a= lways carried in a consistent place at the internetworking layer so that if= they do want to use them they know where to find them.
    =C2=A0
    <= div class=3D"m_-291143135448144913m_7485895676561816267m_-60979969641761053= 41m_1310973367067486614m_2848463475820566235gmail-h5">

    On Tue, Aug 15, 2017 at 12:04 PM, Adri= an Hope-Bailie <adrian@hopebailie.com> wrote:


    On 14 August 2017 at 22:03, Evan Schwartz <evan@ripple.co= m> wrote:
    - = All interledger layer messages should be ILP packets (including fulfillment= s) and be capable of carrying higher layer protocol payloads.
    <= div>
    Interledger has higher requirements than ILP for = the lowest layer, specifically because we are carrying money and not just d= ata. One of the requirements is being able to transmit a 32-byte fulfillmen= t back along the same path that carried the payment originally. If we expec= t this of the lower layer, I don't see a point in putting the fulfillme= nt into an ILP packet and transmitting it as Interledger data along the sam= e path. All ledger-layer protocols will need to interpret the fulfillment p= assed in their protocol, not the one passed through the Interledger layer.<= /div>

    This is not correct. There is= no requirement on ledger layer protocols to transmit or understand the ful= fillment. You are looking at this through the lens of existing implementati= ons from the bottom up instead of starting at the interledger layer.
    The primary function of the condition an= d fulfillment is as a signed end-to-end receipt. If the sender agrees a con= dition with a receiver and then gets back the valid fulfillment they don= 9;t care what happened in the middle. The receiver has signed a receipt say= ing they have their money.

    The valu= e of using a standard for the receipt and signature is that each transfer a= long the way CAN re-use it. One the one hand you can have a transfer betwee= n two peers that have zero trust and the ledger they use supports condition= al payments completely. On the other extreme you can have two peers that ha= ve a full trust and ignore the condition and fulfillment completely.
    =C2=A0
    The ledger layer protocols ca= rry ILP packets. Payment requests and either fulfillment or error responses= . If a ledger layer protocol wants to use the condition and fulfillment for= their own operations they can extract these from the ILP packets and use t= hem.


    >=C2=A0- While it may make = sense to split the interledger payment and interledger quoting protocols in= to new higher level protocols that seems like an unnecessary abstraction. I= nstead the packet definitions should just have some consistency and probabl= y a common base/header.

    The curr= ent protocols effectively have this header but it isn't separated out. = There are two fields in the request header: type and destination address. T= here is one field in the response header: type. I don't think it makes = that much of a big difference to separate these fields if all of the fields= in that packet need to be interpreted together (for example, you can't= understand a quote request if you strip off the destination address).

    I agree that we don&#= 39;t HAVE to explicitly separate them out but I think ti would make it clea= rer how the stack is architected if there was a header that was consistent = across all packets. Currently the only thing that is consitent across all I= LP packets is that they are defined int he same file.
    = =C2=A0

    >=C2=A0= - We should define two base ILP packet types: request and response.<= /div>
    Unless this adds some substantive benefit or new fields= I don't think it's worth breaking all of the formats we have just = to rearrange things.

    The= goal of this exercise is to tease out the best design and ignore the cost = of change until we can compare the results with the current design.
    =C2=A0
    =

    >=C2=A0- ILP is not about ledgers, it is about trustlines between nodes/hosts.

    A ledger is any sy= stem that tracks accounts and balances. When you use a trustline all of you= r messages still need to go through an accounting system (such as the plugi= n in the JS implementation) and then on to the other program logic.
    <= /div>

    As above, this is incorrect. T= here is no requirement for "all messages to go through an accounting s= ystem".

    Since designing the first implementation of = 5-bells ledger we have assumed that passing the ILP packet MUST be done by = the ledger because that is how we implemented it. But that is not true. It = is perfectly valid for the passing of an ILP packet from one peer to anothe= r to be simply an exchange of data.

    The receiving peer ma= kes a decision about whether or not to forward the packet based on the curr= ent financial position they have with the sending peer.

    <= /div>
    It is convenient if the ledger that records the net positions of = the peers also forwards the messaging and even better if it natively suppor= ts conditional payments and can use the condition and the fulfillment from = the ILP packet for those but that's all it is, convenient.

    =C2=A0
    <= div>
    In that case, the plugin or whatever is doing the accounting is th= e ledger. Digital value is always tracked in ledgers, so I think it does ma= ke sense to think of this as the base layer. The reason to abstract the fun= ctionality you expect from the ledger layer is precisely so you can handle = it in different ways, depending on what the underlying systems provide.

    I see 3 ways to think of the layer(s) underpinning IL= P:
    1. The "Ledger Layer" provides= both messaging capabilities and some type of HTLA
    2. There are = separate plugins for messaging and for transfers and when you peer with som= eone you have to agree on a plugin for each
    3. We standardize the mess= aging part and say that all goes over IP and then just have more minimal pl= ugins for the on-ledger settlements
    Number 1 is what we have = and I think that still makes the most sense.
    =
    I think you're confusing implementation details and defining= of interfaces with definition of a protocol stack. The only differences be= tween the tree examples you have above is in implementation.

    From th= e perspective of the Interledger Protocol the implementation of the lower l= ayers is not important, that's the whole point of layering. By forcing = important aspects of ILP like the condition, fulfillment and expiry down in= to those layers you muddy the waters and we now have to standardize those p= rotocols too. Instead we should just be defining the functions they must pr= ovide and then leave it up to implementations to provide those functions.
    I know we want to define a standard = to bootstrap the system (CLP) but that's misleading us into thinking it= 's an essential part of the stack. It's perfectly valid for two pee= rs to not use CLP and still be part of the Interledger.

    That said, you r= aise an interesting consideration about the layers below ILP and actually I= think it makes sense to split these.

    We keep trying to f= orce messaging through the ledger layer and actually that's the wrong p= lace to put it if we can split the ledger layer into a messaging layer and = a ledger layer. That way we can stop trying to think of all HLTAs as ledger= s.

    A thought, why not use sub-layers as is common in othe= r stacks:

    1. Link layer: Layer upon which two peers that = have a direct link, or participate in the same payment network, communicate=
    2. Transfer/ ledger: Layer on which financial positions betw= een two peers are recorded

    This reflects the already emerging HTLA m= odel and many of our existing plugins and ledger integrations.
    Link Layer: XRP Paychan, Lightning
    Ledger Layer: XRP Ledger= , Bitcoin

    This doesn't prevent us from def= ining a standard binary protocol that defines all of the operations for bot= h layers (like CLP) but I see value in distinguishing between these two.
    =C2=A0

    >=C2=A0- The protocol should differentiate between the operation of prepari= ng a transfer on a ledger and the operation of passing an ILP packet from o= ne peer to another.

    The protocol assumes your conditional transfer is underpinned by some HTLA. It doesn't care whether that's on-ledger or not.

    What do you mean when you say "the prot= ocol"? In my statement I am referring to ILP.
    My point above being= that ILP expects ILP packets to be passed from peer to peer but has no exp= ectations about transfers.

    It's= perfectly legal (from an ILP perspective) for two peers to exchange ILP pa= ckets with no transfers. Clearly if a node routes a packet on and has no in= coming transfer it's going to lose money but that's a consideration= for that node. It doesn't affect anyone else in the chain.

    ILP doesn't assume anything about transfer= s at all, let alone conditional transfers. It provides useful semantics for= conditional transfers to be used by two peers to transact as part of a lar= ger ILP payment.
    =C2=A0

    = >=C2=A0- The condition and timeout s= hould be included in the ILP payment packet.

    I strongly disagree with this. We had this debate a year ago and I= was on your side but was convinced that this is not a good idea.

    Yes, I recall this and I'm so= rry I didn't push harder on this point. Unfortunately I think the decis= ion to pull it out of the packet is mostly driven by how our prototypes wer= e implemented rather than good architecture.

    The layer below= ILP must be capable of doing conditional transfers based on sha256 hashloc= ks with 32-byte preimages.

    <= div>This is not true and I think it would be useful for us to agree on this= as this seems to be the argument I am coming up against most often. The pe= ers participating in a transfer that is part of an ILP payment may wish to = use conditional transfers as a way to enforce their agreement but this is n= ot a requirement of the protocol.

    The agreement between a= ny two peers is: "I will pay you X if you can provide a receipt that Y= was paid Z before T".
    ILP provides a standard for expre= ssing this agreement so that these can be chained together BUT it is not a = requirement that every agreement in the chain uses the condition, and fulfi= llment provided at the ILP layer.

    =C2=A0
    As a result, the original condi= tion and the corresponding preimage MUST be expressed in that layer.
    =

    As I have shown above, this i= s not true.
    =C2=A0
    Then the question is whether we should also in= clude it in the packet that is forwarded. What ultimately convinced me is t= he following: All connectors MUST ignore the condition if it is in the pack= et, because they are only guaranteed their money back if they use the same = condition from the incoming transfer they got.

    Here is where the layering is= being corrupted.

    All connectors MUST inspect the condition in the I= LP packet as part of their decision to route the packet or not.
    When the local transfer module of the connectors s= tack passes the ILP packet up to the ILP module it should indicate the prop= erties of the incoming transfer that carried the packet.
    This is essential firstly so that the routing logic in th= e ILP module can record the incoming transfer identifier so it is able to u= se the correct response id when it passes back the fulfillment or error.The other properties that the ILP module should look at are the condition = and expiry on the incoming transfer.

    If the incoming route uses conditional transfers and thes= e are supposed to match the condition and expiry in the ILP packet then the= ILP module should compare them and reject the packet if:
    a) = the conditions don't match OR
    b) the expiry is too short<= br>
    We should still discuss if the expiry should be set by th= e sender and left unchanged or used like a TTL and decremented by each node= .
    =C2=A0
    Also, the receiver will need to take out the condition= in order to hash the packet for PSK or IPR.
    =
    This is completely normal. Zeroing a checksum field i= n a header before calculating the checksum is VERY common precisely because= it's long been accepted that the right place to put that data is in th= e headers and the work of zero'ing it out to calculate the checksum (or= signature in our case) is not material.
    =C2=A0
    So basically, no = one wants the condition in there. It feels like it ought to be in there, bu= t literally none of the parties want the extra 32 bytes in there.

    "Nobody wants it there"= is a terrible reason to abandon the correct design. The whole purpose of a= good architecture is you accept that there may be cases in future that hav= en't been considered now so designing just for the known cases is a bad= idea.

    Good architecture is not the same as optimization.= Taking stuff out (even when it feels wrong) to save a few bytes is a good = sign that it's a bad idea.
    =C2=A0

    The reason t= he timeout should not be in there is that there isn't a single timeout = for the payment. There are multiple separate timeouts for each of the bilat= eral transfers. Those must go in the individual transfers and there is no s= ensible value to put in the Interledger packet.
    =C2=A0
    As above, this is somewhat equivalent to the TTL = in an IP packet. I'm open to discussing if it should be a fixed value s= et by the sender where each node uses their own value but has the sender-de= fined value as a reference or it is actually decremented at each hop.
    Either way, this is part of ILP not the ledger layer just like= the condition and fulfillment. It may be used by the ledger layer but that= 's implementation specific. It belongs in the ILP packet.
    =C2= =A0




    --
    =
    Sent from a mo= bile device, please excuse any typos



    --94eb2c1cd75ee872aa055703e2c9-- From nobody Fri Aug 18 06:22:29 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744471204DA for ; Fri, 18 Aug 2017 06:22:26 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 Jc5Wp9xVezpL for ; Fri, 18 Aug 2017 06:22:20 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 EF5401323AC for ; Fri, 18 Aug 2017 06:22:01 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id n29so3598253uai.5 for ; Fri, 18 Aug 2017 06:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BXt1pjaFxd8jNwiXL9Lf4tEH3/8b0GTIHPR0daft2MI=; b=CUk8laW3hAHmMioOmRKCLbQ3L40uXHTvtH5YG5LTgeF0rNiQtdkkPp4PMqPx/WSwnv gFiGkcUF2zxa4ev2zkhN2gwaBJaOEr0weEeeOnyOph82/ZadOcnsjK+s3vKJlhM8qSQy VMe32ib0FjaHhl1qq1JMc/FYTi+JpoBrWyuPM= 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=BXt1pjaFxd8jNwiXL9Lf4tEH3/8b0GTIHPR0daft2MI=; b=Jqq4Hrts4G8SwIfgwPYR3wq7Q+XoTk3CMuAYho2taFOHIx+Oy6WIaP1rrey192cCm7 UBpkfq+leqWgXRvXSvwtcLZY3gwjRDumr8ZVu6g7aiY1obRPFoXlOtO+xFBqvQoWoxNH mTW1jh1axQ7apLrBku6pW51CS2mjNnA2JwC96DAXgtn/BJG60cT21J16M6hkRz5mrHyj nFY4zk+V0BtwBI1Dvbamgcl+kRwUEL072QKj4MsKm47WvfgIrhA5H+OgeJtKRBrvWCaw etemq4+tL6s8CKKD2qQ3tJckVxx3jNp0J2NU6K4vYlorLFG9D4649cPuQ/BKGWYuJcH+ ABwQ== X-Gm-Message-State: AHYfb5gUohCWsYpRHyLL3Y/XNhrp1hMBqj+Kbvy7+iriqSmyphiYjzRC NBgDwYmU9KsKGsIUolvCHOiiBsW4ZncP X-Received: by 10.176.9.205 with SMTP id e13mr2592686uah.164.1503062520540; Fri, 18 Aug 2017 06:22:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.62.90 with HTTP; Fri, 18 Aug 2017 06:21:59 -0700 (PDT) In-Reply-To: References: From: Adrian Hope-Bailie Date: Fri, 18 Aug 2017 14:21:59 +0100 Message-ID: To: Ben Sharafian Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="f403043ee9b09d3aff055707036d" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 13:22:26 -0000 --f403043ee9b09d3aff055707036d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 18 August 2017 at 10:38, Ben Sharafian wrote: > Two connectors exchanging a transfer only care about the data that is >> relevant to them for that transfer. It's quite possible for two connecto= rs >> to perform a transfer that has no conditions or fulfillments or a transf= er >> that has a different condition and fulfillment (such as an atomic mode >> transfer where the condition is a compound one that has multiple >> sub-conditions). > > > Yes, two connectors could absolutely send an unconditional transfer on an > underlying ledger in order to settle an Interledger payment. But in order > to benefit from any of Interledger's guarantees (trustless connectors, > retry-ability, etc.), they MUST keep a conditional local transfer, at lea= st > for clearing. If the local transfer cannot time out, it cannot be safely > retried. If the local transfer clears without a fulfillment, it loses the > "receipt or your money back" property. Yes, two parties in the chain coul= d > eschew these benefits but that is no longer a correct implementation of > Interledger. > Aha! That is where I disagree! Interledger is not implemented at the local transfer layer, it is implemented at the Interledger layer. The whole point is that it an Interledger payment can travel over payment networks that know nothing about ILP but the greatest value comes from using ones that do= . What you're describing is an implementation of a local transfer service that doesn't (or can't) take advantage of Interledger. In fact, this will be the norm for most existing payment networks that we want to add to the Interledger and this is where your work on payment channels and HTLAs comes in to play. If you have a local transfer channel that doesn't support conditions natively or supports them in a way that requires some adaption you can create an overlay network that does what's needed. Example: Bitcoin is not a suitable network to use for ILP so we use a payment channel between the peers that is underwritten by Bitcoin. > > If a protocol at a lower layer wants to use that data then it must >> replicate it. That seems inefficient but it's the correct way to do it. > > > What's the actual reasoning behind this, and why is it considered the > correct approach? If there's some IETF document that says this I'd like t= o > see it, because it intuitively feels wrong to have lower level abstractio= ns > looking into higher levels. > The data in the ILP layer is there for a specific reason. It's part of an end-to-end exchange between the sender and receiver. *Side note: It's unusual to be designing the whole stack at once so we keep being tempted to move things around but in reality we should look at the ILP layer in isolation and make sure it is complete. Alternatively we should try to test our design against a number of lower and upper layer protocols to make sure our thinking is sound.* If we assume the ILP packet is well defined with all the ILP-required data elements then when a lower layer wants to use that data it can but should do it in a way that doesn't break the ILP layer for everyone else. How that is implemented in practice will depend on the lower layer protocol. > > Routing requires looking at the condition, expiry and amount. A >> connector's routing logic shouldn't forward a packet if the expiry is to= o >> low or if the condition is obviously corrupted. > > > Those are validity checks and you're right that they are performed in the > connector, but the destination account, destination amount, and data are > enough to figure out what the best next hop is. > Unless the next hop is backwards > > The ILP Packet's purpose is to describe where a payment is going. > Not only that. For comparison, an IP packet does a lot more than just describe where a packet is going. All end-to-end concerns need to be in there too. > The data it carries is only for the purpose of making sure the receiver > can identify that payment. > No, the condition is there so the receiver can ensure it is sending back the correct fulfillment and the expiry to give the receiver some assurance that the packet is still worth processing. > In that context, the expiry has no bearing on where it will be routed nor > on how much to route, only on whether or not an individual connector will > take the risk of forwarding it. > > The ILP packet just contains the end-to-end condition (always a SHA-256 >> hash) and then the local transfer can have a different condition that is >> derived from the condition in the ILP packet. > > > Fair enough; in your case you can transmit the condition twice and verify > the structure of the complex local condition, and in the > no-condition-in-ILP version you can verify the structure of the local > condition and extract the SHA256 condition to pass on. > > I think the expiry should always be the expiry set by the sender. It won'= t >> be changed. > > > That increases connector risk enormously, allowing anybody to cause a > connector to lose money by submitting a fulfillment at the last moment. > Not at all. You're assuming that there is no expiry on the local transfer. As a receiving node I have an incoming transfer with an expiry and it carries an ILP packet that also has an expiry. My routing logic should look at both and decide a) if this is safe to route on (i.e. put some of my own capital at risk) and b) what expiry to set on the next hop. There is no incentive to change the expiry in the packet as this can only be targeted at upstream connectors and the result will simply be that the payment is declined and the upstream local transfer rolls back. > If an attacker knows enough about latency in the chain, they could even > target this attack at somebody many hops away. Staggering expiries (givin= g > you a minimum amount of time to fulfill a source transfer) is an easy > mitigation against this attack; we shouldn't take it out. > I agree. We would still have the local expiry. > > Comparing the condition in the local transfer and the one in the ILP >> packet should be part of the routing logic. > > > Sure, it can be done as an extra validity check, but it's just more code > and more attack surface. I still don't see any tangible benefit from > doing the layering in this way, aside from your assertion that it's the > correct way to do it. If you've read any documents that explain why this = is > the correct way to do layering, I think I'd understand you better. > > > On Thu, Aug 17, 2017 at 7:32 PM, Adrian Hope-Bailie > wrote: > >> >> >> On 16 August 2017 at 10:22, Ben Sharafian wrote: >> >>> OK, I think in that case we're mostly disagreeing over where the >>> condition/fulfillment/expiry actually go in the data. >>> >> >> That's one way to look at it but that's ultimately what the architecting >> the layering is. Deciding at which layer (and therefor encapsulated in w= hat >> packet) certain data should be. >> >> >>> The reason I don't agree with your position is based on which parties I >>> think should be aware of ILP. >>> >> >> I don't think that's the right way to look at it. The connector needs to >> be able to understand at least the ILP layer data AND the lower layer da= ta. >> Normally the way the processing stack is implemented is that there is a >> module for each layer that processes the data from that layer and then >> passes the payload and any other important information up to the next la= yer. >> >> >>> In order to track the balance between each other accurately, the two >>> connectors have to keep track of conditions, fulfillments, and expiries= on >>> each of the transfers. >>> >> >> This is where I disagree with you. Two connectors exchanging a transfer >> only care about the data that is relevant to them for that transfer. It'= s >> quite possible for two connectors to perform a transfer that has no >> conditions or fulfillments or a transfer that has a different condition = and >> fulfillment (such as an atomic mode transfer where the condition is a >> compound one that has multiple sub-conditions). >> >> >>> That means the connectors' accounting logic that handles the conditions= , >>> fulfillments, and expiries is going to be using some information inside= the >>> ILP packet and some information outside of it in order to perform these >>> transfers. >>> >> >> It will only use info inside the packet if it uses conditional transfers >> that use that same condition. This is the most likely scenario but that = is >> not a protocol requirement. >> >> >>> >>> I think it's cleaner to say everything required to make these local >>> transfers should go in one protocol, so the accounting logic of these >>> connectors doesn't have to deal with ILP directly. >>> >> >> I strongly disagree with that. That's entirely the wrong reason to put >> data into a specific layer. The data in the ILP layer is there because i= t's >> "end-to-end" data. >> >> If a protocol at a lower layer wants to use that data then it must >> replicate it. That seems inefficient but it's the correct way to do it. >> >> One could define a lower layer protocol that doesn't replicate the data >> but the rules of the protocol are "Get the condition from the ILP packet= ". >> In that case, that specific lower level protocol is forcing implementati= ons >> to understand the ILP packet format, that's an implementation detail. >> >> Another lower layer protocol might take the condition from the ILP packe= t >> and re-encode it in a different form (like a base64ulr string or NI: uri= ) >> >> >>> Then the connectors' ILP-packet-related behavior can all be routing >>> related. >>> >> >> Routing requires looking at the condition, expiry and amount. A >> connector's routing logic shouldn't forward a packet if the expiry is to= o >> low or if the condition is obviously corrupted. >> >> If the protocols were designed correctly as I am proposing then another >> routing decision would be, is the condition that was used in the incomin= g >> transfer the same as the one used in the ILP packet? >> >> >> >>> This would add a few benefits; two connectors could perform non-ILP >>> conditional transfers between one another (which would be useful for >>> reconciliation and settlement), and could also allow two connectors to = use >>> more complex condition types (i.e. signatures for atomic mode) without >>> forcing us to support that in the ILP packet. >>> >> >> You seem to have this backwards. Both of these things are supported if >> the condition and expiry ARE in the ILP packet. Atomic mode is not >> supported in the ILP protocol it is supported in the lower layer transfe= r >> protocol. The ILP packet just contains the end-to-end condition (always = a >> SHA-256 hash) and then the local transfer can have a different condition >> that is derived from the condition in the ILP packet. >> >> >>> It also keeps the integrity of the ILP packet as something lower levels >>> don't modify; the connector has to modify the expiry in order to pass a= long >>> an ILP payment (they may not modify the expiry if they're using somethi= ng >>> like atomic mode, but then we have the issue with advanced condition ty= pes >>> not being supported in the ILP packet). >>> >> >> I think the expiry should always be the expiry set by the sender. It >> won't be changed. >> >>> >>> In the case where the ledger _does_ care about the condition and >>> fulfillment, the argument in favor of separating >>> condition/fulfillment/expiry from the rest of the packet is similar. >>> Because we don't control the features of all ledgers, we'll need our >>> plugins or ledger adapters to be aware of ILP. This makes it hard to >>> interact with any events that don't involve ILP packets, and impossible= to >>> handle features that extend beyond what we support in the ILP packet. W= e >>> could pass details about non-ILP ledger features (like a crypto conditi= on) >>> in the side data, but in the event of any redundancy we have to check t= he >>> ledger-supplied info, not the info in the ILP packet. >>> >> >> Comparing the condition in the local transfer and the one in the ILP >> packet should be part of the routing logic. >> >> >>> >>> Basically, condition/fulfillment/expiry are used for accounting local >>> transfers (even if they aren't being "ledger" enforced) in addition to >>> their role as every-hop information. By putting them in the ILP packet,= we >>> limit the special features that ledgers can support and make our softwa= re >>> abstractions harder to separate cleanly. By putting them in the local >>> transfer alongside the ILP packet but not inside it, we do separate the >>> data a little more, but we have more freedom in what the underlying >>> accounting and ledger logic can do, and our software modules will have = more >>> clearly separated domains. >>> >> >> They should be in both the local transfer AND the ILP packet if they are >> needed by the local transfer protocol. This allows the flexibility you >> desire because the local transfer protocol can do ANYTHING including usi= ng >> the condition from the ILP packet as-is, not at all or enhanced for >> something like atomic mode. >> >> >> >>> >>> On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie < >>> adrian@hopebailie.com> wrote: >>> >>>> Exactly =F0=9F=91=8D >>>> >>>> On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian >>>> wrote: >>>> >>>>> Ok, I think I have a better idea of what you're saying. >>>>> >>>>> It sounds like you're saying the ILP layer contains all information >>>>> that is common between every hop (destination, destination amount, op= aque >>>>> data, condition, fulfillment, expiry). The lower level would then be = used >>>>> for all the transfer-local details (source amount, next connector acc= ount, >>>>> custom/local data). >>>>> >>>>> If the lower level wanted to do anything related to the every-hop >>>>> payment, i.e. escrow funds until the receipt has been produced, it wo= uld >>>>> look into the ILP layer for that information. If the lower level didn= 't do >>>>> any escrow or expiries that require every-hop details, it would simpl= y >>>>> function as a communication method. >>>>> >>>>> Is that right? >>>>> >>>>> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >>>>> adrian@hopebailie.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 15 August 2017 at 16:00, Ben Sharafian >>>>>> wrote: >>>>>> >>>>>>> In that case, the plugin or whatever is doing the accounting is the >>>>>>>>>> ledger. Digital value is always tracked in ledgers, so I think i= t does make >>>>>>>>>> sense to think of this as the base layer. The reason to abstract= the >>>>>>>>>> functionality you expect from the ledger layer is precisely so y= ou can >>>>>>>>>> handle it in different ways, depending on what the underlying sy= stems >>>>>>>>>> provide. >>>>>>>>> >>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>> >>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>>>> some type of HTLA >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. There are separate plugins for messaging and for transfers >>>>>>>>> and when you peer with someone you have to agree on a plugin f= or each >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. We standardize the messaging part and say that all goes >>>>>>>>> over IP and then just have more minimal plugins for the on-led= ger >>>>>>>>> settlements >>>>>>>>> >>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>> sense. >>>>>>>> >>>>>>>> >>>>>>> I think you're confusing implementation details and defining of >>>>>>>> interfaces with definition of a protocol stack. The only differenc= es >>>>>>>> between the tree examples you have above is in implementation. >>>>>>> >>>>>>> >>>>>>> I had to scroll up after reading this to make sure it was @adrian >>>>>>> talking, because that seems like the opposite of what you were argu= ing for. >>>>>>> >>>>>> >>>>>> I don't think so. But I think that is part of the problem. We are no= t >>>>>> all focused on the same thing. I am actually not very interested in = CLP at >>>>>> all. It is one of potentially many protocols that may exist below th= e ILP >>>>>> layer. All we're doing by defining CLP is bootstrapping the network = by >>>>>> defining a protocol for everyone to use to get started. >>>>>> >>>>>> In designing the ILP layer properly we should try and forget >>>>>> everything we know about the lower layers other than what features w= e >>>>>> require of them. >>>>>> >>>>>> There is a misconception that ILP requires the lower layers to >>>>>> support conditional transfers, that is not true. >>>>>> >>>>>> All we actually need from a lower layer protocol is to transfer data >>>>>> back and forth and provide a way to reliably map requests to respons= es. >>>>>> >>>>>> What ILP provides lower layers is a way to reward your peer for >>>>>> passing on the packet. The Internetworking layer defines a condition= , a >>>>>> reward that must be paid to the receiver for the fulfillment and the= time >>>>>> allowed to claim this reward. >>>>>> >>>>>> Because of this, within lower-layer protocols that offer the basic >>>>>> request/response features we need, we could add conditional payment >>>>>> semantics that use the condition, expiry and fulfillment provided by= ILP. >>>>>> This would allow a node to offer a reward to their next peer to for >>>>>> delivering the packet they send them and to make the local financial >>>>>> transaction contingent on the end-to-end transaction. >>>>>> >>>>>> But crucially, adding that semantic to the lower layer protocol >>>>>> provides nothing extra to the ILP layer. The value is purely derived= from >>>>>> the two peers who use that protocol and can now use conditional paym= ents to >>>>>> protect themselves from their peers. >>>>>> >>>>>> >>>>>>> The proposal that you're arguing for is basically asserting that >>>>>>> we're going to be using CLP, because it makes the assumption that t= he >>>>>>> connectors (who understand ILP) are managing the HTLA logic. >>>>>>> >>>>>> >>>>>> Not at all. I am asserting that it doesn't matter what protocol you >>>>>> use below the ILP layer because it shouldn't matter. All of this tal= k about >>>>>> ILP being different because money is more important than data is non= sense. >>>>>> >>>>>> The difference between ILP and IP that makes ILP suitable for value >>>>>> transfer and IP not is at the internetworking layer. ILP requires th= at all >>>>>> packets are either a request or response and that the responses foll= ow the >>>>>> same path as the requests. Further ILP defines a signature scheme th= at >>>>>> gives the sender a way to be certain the request was received by the >>>>>> receiver. >>>>>> >>>>>> *This could be done entirely without money* but then there would be >>>>>> little incentive to sign the receipt or deliver the signature back t= o the >>>>>> original sender. >>>>>> >>>>>> So, if you add money then you add economic incentives to the mix. At >>>>>> each hop the sender promises the next upstream peer a payment if the= y can >>>>>> return the receipt. The net effect is that this can be used to trans= fer >>>>>> money from the sender to the receiver by simply defining up front th= e >>>>>> amount that the receiver must get to produce the signature. >>>>>> >>>>>> >>>>>>> >>>>>>> In the current model, the CLP/trustline model and the direct ledger >>>>>>> model both work without having to treat anything on the ILP layer >>>>>>> differently. We're favoring on-ledger messaging because of our >>>>>>> implementation, yes, but we've been able to switch most all of our = plugins >>>>>>> from on-ledger messaging to RPC-based messaging without changing th= e ILP >>>>>>> layer at all. >>>>>>> >>>>>>> With the ledger-level abstraction, we were able to switch from our >>>>>>> ledger-based mode of thinking to the CLP/trustline based way withou= t >>>>>>> changing anything other than the plugin. Your argument comes from a= n >>>>>>> assumption of a CLP-style ledger protocol with some underlying ledg= er, >>>>>>> which we can't assume is always the case. >>>>>>> >>>>>> >>>>>> I'm not sure what any of that proves tbh. These are all >>>>>> implementation concerns. They don't change the fact that the conditi= on, >>>>>> expiry and fulfillment are part of ILP not the lower layer protocols= . >>>>>> >>>>>>> >>>>>>> >>>>>>> From the perspective of the Interledger Protocol the implementation >>>>>>>> of the lower layers is not important, that's the whole point of la= yering. >>>>>>>> By forcing important aspects of ILP like the condition, fulfillmen= t and >>>>>>>> expiry down into those layers you muddy the waters and we now have= to >>>>>>>> standardize those protocols too. Instead we should just be definin= g the >>>>>>>> functions they must provide and then leave it up to implementation= s to >>>>>>>> provide those functions. >>>>>>> >>>>>>> >>>>>>> I don't agree with this point; the condition and fulfillment have >>>>>>> actual meaning to the ledger layer. >>>>>>> >>>>>> >>>>>> NO THEY DON'T! They have meaning to SOME ledgers that implement SOME >>>>>> lower layer protocols, IF they choose to use them. >>>>>> >>>>>> Excuse the shouting but this is the crux of the issue. We need to al= l >>>>>> agree that it is entirely possible for a transfer to be done that do= esn't >>>>>> use the condition and fulfillment and that if this was in the middle= of a >>>>>> 10-hop ILP payment it would have no effect on the sender and receive= r. >>>>>> >>>>>>> >>>>>>> You've said that the ledger often doesn't care about fulfillment an= d >>>>>>> condition, but the ledger _layer_'s (where transfers are done) role= is to >>>>>>> take in condition and fulfillment and make a transfer which satisfi= es its >>>>>>> HTLA. >>>>>>> >>>>>> >>>>>> No, the ledger's role is to keep a tab of net financial positions >>>>>> between two peers. It MAY use conditions and fulfillments that it pu= lls >>>>>> from the ILP layer to help it do that in a way both peers agree on. >>>>>> >>>>>> Note that a "layer" doesn't have a role. I think there is some >>>>>> confusion about the difference between layering the protocol and >>>>>> abstracting functionality into different components. >>>>>> >>>>>> >>>>>>> If the ledger layer has to look into the ILP packet to do so, that >>>>>>> is a blatant breaking of layering. >>>>>>> >>>>>> >>>>>> Not at all! The module acting at the layers *below* the >>>>>> internetworking layer shouldn't modify anything inside the packets o= f the >>>>>> higher layers but they can definitely inspect them and adjust their >>>>>> behavior based on what they to find. >>>>>> >>>>>> In fact the prevalence of this is the subject of a lot of debate at >>>>>> the IETF currently because endpoints are often encrypting their payl= oads >>>>>> and in some cases this makes it difficult for middle-boxes to be eff= ective >>>>>> at their jobs. >>>>>> >>>>>> By putting the condition, fulfillment, and expiry on the ledger >>>>>>> layer, we leave it open for any ledger type to work, rather than fo= rcing >>>>>>> all ledger-layer software to understand ILP. >>>>>>> >>>>>> >>>>>> Actually you do the opposite. You make it a requirement of every >>>>>> protocol below the ILP layer to define a way to carry these data ele= ments >>>>>> and encode and decode them, even if they don't use them >>>>>> >>>>>> Ledger layer components don't have to understand ILP unless they >>>>>> choose to re-use the condition for their own local transfer. Ledgers >>>>>> themselves *never* have to understand ILP. >>>>>> >>>>>> Remember a ledger layer protocol could use a completely different >>>>>> conditional payments scheme, like atomic mode ILP, where it takes th= e >>>>>> end-to-end condition and creates a new compound condition that depen= ds on >>>>>> the fulfillment and some notary signature. >>>>>> >>>>>> There will be a component in a connector's stack that must pass the >>>>>> ILP packet to the next peer. If it does this using a transfer protoc= ol that >>>>>> uses conditional transfers and wants to use the same condition as th= e ILP >>>>>> packet then it must decode the packet. >>>>>> >>>>>> But, it will likely do something with that condition before sending >>>>>> the transfer to the ledger like encoding it differently or rehashing= it >>>>>> (lightning?) so that it's in the form expected by the ledger. >>>>>> >>>>>> That's an implementation decision of the lower layer protocol used >>>>>> between those two peers. >>>>>> >>>>>> >>>>>>> >>>>>>> I agree that Interledger defines how conditions, fulfillments, and >>>>>>> expiries should be chained together, but it makes no assertions abo= ut their >>>>>>> data format. >>>>>>> >>>>>> >>>>>> ILP doesn't define how anything is chained together. From the >>>>>> perspective of ILP the condition and fulfillment are end-to-end data= . They >>>>>> are agreed by the two endpoints who don't care how they get from Ali= ce to >>>>>> Bob and back. >>>>>> >>>>>> The design of ILP is such that it facilitates the design of lower >>>>>> level protocols that can be used to carry the ILP packets across mul= tiple >>>>>> hops (networks) using economic incentives such that the sender pays = enough >>>>>> for the first hop to ensure that all nodes in between can extract th= e fee >>>>>> they want and the receiver will still get the amount they expected.. >>>>>> >>>>>> >>>>>> >>>>>>> ILP says you should send your outgoing transfer with the same >>>>>>> condition as the incoming one, and a lower expiry. >>>>>>> >>>>>> >>>>>> No it doesn't. An internetworking protocol can't prescribe that kind >>>>>> of thing to lower level protocols. An incoming and outgoing transfer= could >>>>>> be sent using completely different protocols and the financial agree= ment >>>>>> with the peers on those two routes could be vastly different too. >>>>>> >>>>>> The only service ILP requires of lower level protocols is that they >>>>>> can map a response to an original request. This requirement is okay = because >>>>>> it is isolated to a single route/link at a time not a requirement th= at >>>>>> crosses the inter-network boundary that ILP crosses. >>>>>> >>>>>> >>>>>>> But because ILP allows for many different types of ledgers, it >>>>>>> doesn't make sense to assert how these are encoded. >>>>>>> >>>>>> >>>>>> By putting them in the ILP packet you do the opposite. You make no >>>>>> assertions about how they are encoded if they are used at lower laye= rs, or >>>>>> how they may be combined with other conditions or even used to deriv= e new >>>>>> conditions. >>>>>> >>>>>>> >>>>>>> IP doesn't tell you how to encode an ethernet packet. It doesn't >>>>>>> even know whether it's going over a computer or a hand-written lett= er >>>>>>> carried by a pigeon. IP takes for granted that you can send data ov= er one >>>>>>> connection by putting it in a lower level. >>>>>>> >>>>>> >>>>>> Correct, but if a link layer protocol wanted to look into the IP >>>>>> packet headers of a packet it wants to transfer and use some data fr= om >>>>>> there in its internal logic (or even reuse data in it's own frame) t= hat >>>>>> would be totally fine. >>>>>> >>>>>> >>>>>>> Even though IP tells you how to chain these connections together, i= t >>>>>>> doesn't have to put the things it's chaining on the internetworking= level. >>>>>>> >>>>>> >>>>>> IP doesn't tell you how to chain things together. IP simply defines >>>>>> the end-to end data envelope and address space. Because of this node= s that >>>>>> implement the multiple lower layer protocols are able to push IP pac= kets >>>>>> down a link and expect the node on the other side to understand the = headers >>>>>> and route it onward on another link. >>>>>> >>>>>> Everything needed by the IP module to decide what to do with the >>>>>> packet is in the IP packet headers. i.e. Has it exceeded a TTL? Is t= here a >>>>>> route for this destination? Is it corrupted (checksum fails)? But al= so, >>>>>> everything that is needed by the endpoint (like the source address) = is also >>>>>> in there. >>>>>> >>>>>> There is no dependency on nodes to be good citizens and always pass >>>>>> certain other data from the lower layers into the next link. That wo= uld be >>>>>> breaking the layering. >>>>>> >>>>>> >>>>>>> IP also assumes that if you get some incoming data on a connection >>>>>>> you can copy it and send it out on the next connection. Because you= can >>>>>>> already send data over a connection, all IP adds is the missing pie= ce: a >>>>>>> packet that tells you where to go. >>>>>>> >>>>>>> With ILP, we assume that there is a way to prepare a conditional >>>>>>> transfer, expire a conditional transfer, and fulfill a conditional >>>>>>> transfer. >>>>>>> >>>>>> >>>>>> No we don't! We assume that if we deliver the packet as intended >>>>>> we'll get back a response packet with a signature that matches the >>>>>> condition in the packet. So, if we have an agreement with someone th= at they >>>>>> will pay us when we present that signature then we are prepared to e= nter a >>>>>> similar agreement with the next peer because we expect that signatur= e to >>>>>> come all the way back along the interledger layer route.. >>>>>> >>>>>> >>>>>>> We also assume that if you get an incoming transfer you can create >>>>>>> an outgoing transfer with the same condition. The abstraction we ma= de means >>>>>>> that conditions and fulfillments are already carried in the lower l= evels. >>>>>>> >>>>>> >>>>>> That is a bad assumption that comes from the broken layering. What i= f >>>>>> my outgoing link doesn't support conditional transfers? So now where= do I >>>>>> put the condition? >>>>>> >>>>>>> >>>>>>> >>>>>>> We could have assumed that no ledgers ever support conditional >>>>>>> transfers, and said the only thing ILP gets from lower levels is th= e >>>>>>> ability to send a transfer. But if we want to support the case wher= e any of >>>>>>> them do, we have to keep the conditions and fulfillments in the lay= er where >>>>>>> they're actually used. >>>>>>> >>>>>> >>>>>> I don't follow that logic at all. If we want to support the case >>>>>> where any of them do then we must ensure the condition and expiry ar= e >>>>>> always carried in a consistent place at the internetworking layer so= that >>>>>> if they do want to use them they know where to find them. >>>>>> >>>>>> >>>>>>> >>>>>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>>>>> adrian@hopebailie.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 14 August 2017 at 22:03, Evan Schwartz wrote: >>>>>>>> >>>>>>>>> I think this thread is going to get extremely unwieldy but here >>>>>>>>> goes: >>>>>>>>> >>>>>>>>> > - All interledger layer messages should be ILP packets >>>>>>>>> (including fulfillments) and be capable of carrying higher layer = protocol >>>>>>>>> payloads. >>>>>>>>> >>>>>>>>> Interledger has higher requirements than ILP for the lowest layer= , >>>>>>>>> specifically because we are carrying money and not just data. One= of the >>>>>>>>> requirements is being able to transmit a 32-byte fulfillment back= along the >>>>>>>>> same path that carried the payment originally. If we expect this = of the >>>>>>>>> lower layer, I don't see a point in putting the fulfillment into = an ILP >>>>>>>>> packet and transmitting it as Interledger data along the same pat= h. All >>>>>>>>> ledger-layer protocols will need to interpret the fulfillment pas= sed in >>>>>>>>> their protocol, not the one passed through the Interledger layer. >>>>>>>>> >>>>>>>> >>>>>>>> This is not correct. There is no requirement on ledger layer >>>>>>>> protocols to transmit or understand the fulfillment. You are looki= ng at >>>>>>>> this through the lens of existing implementations from the bottom = up >>>>>>>> instead of starting at the interledger layer. >>>>>>>> >>>>>>>> The primary function of the condition and fulfillment is as a >>>>>>>> signed end-to-end receipt. If the sender agrees a condition with a= receiver >>>>>>>> and then gets back the valid fulfillment they don't care what happ= ened in >>>>>>>> the middle. The receiver has signed a receipt saying they have the= ir money. >>>>>>>> >>>>>>>> The value of using a standard for the receipt and signature is tha= t >>>>>>>> each transfer along the way CAN re-use it. One the one hand you ca= n have a >>>>>>>> transfer between two peers that have zero trust and the ledger the= y use >>>>>>>> supports conditional payments completely. On the other extreme you= can have >>>>>>>> two peers that have a full trust and ignore the condition and fulf= illment >>>>>>>> completely. >>>>>>>> >>>>>>>> The ledger layer protocols carry ILP packets. Payment requests and >>>>>>>> either fulfillment or error responses. If a ledger layer protocol = wants to >>>>>>>> use the condition and fulfillment for their own operations they ca= n extract >>>>>>>> these from the ILP packets and use them. >>>>>>>> >>>>>>>> >>>>>>>>> > - While it may make sense to split the interledger payment and >>>>>>>>> interledger quoting protocols into new higher level protocols tha= t seems >>>>>>>>> like an unnecessary abstraction. Instead the packet definitions s= hould just >>>>>>>>> have some consistency and probably a common base/header. >>>>>>>>> >>>>>>>>> The current protocols effectively have this header but it isn't >>>>>>>>> separated out. There are two fields in the request header: type a= nd >>>>>>>>> destination address. There is one field in the response header: t= ype. I >>>>>>>>> don't think it makes that much of a big difference to separate th= ese fields >>>>>>>>> if all of the fields in that packet need to be interpreted togeth= er (for >>>>>>>>> example, you can't understand a quote request if you strip off th= e >>>>>>>>> destination address). >>>>>>>>> >>>>>>>> >>>>>>>> I agree that we don't HAVE to explicitly separate them out but I >>>>>>>> think ti would make it clearer how the stack is architected if the= re was a >>>>>>>> header that was consistent across all packets. Currently the only = thing >>>>>>>> that is consitent across all ILP packets is that they are defined = int he >>>>>>>> same file. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> > - We should define two base ILP packet types: request and >>>>>>>>> response. >>>>>>>>> >>>>>>>>> Unless this adds some substantive benefit or new fields I don't >>>>>>>>> think it's worth breaking all of the formats we have just to rear= range >>>>>>>>> things. >>>>>>>>> >>>>>>>> >>>>>>>> The goal of this exercise is to tease out the best design and >>>>>>>> ignore the cost of change until we can compare the results with th= e current >>>>>>>> design. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>>>>> nodes/hosts. >>>>>>>>> >>>>>>>>> A ledger is any system that tracks accounts and balances. When yo= u >>>>>>>>> use a trustline all of your messages still need to go through an = accounting >>>>>>>>> system (such as the plugin in the JS implementation) and then on = to the >>>>>>>>> other program logic. >>>>>>>>> >>>>>>>> >>>>>>>> As above, this is incorrect. There is no requirement for "all >>>>>>>> messages to go through an accounting system". >>>>>>>> >>>>>>>> Since designing the first implementation of 5-bells ledger we have >>>>>>>> assumed that passing the ILP packet MUST be done by the ledger bec= ause that >>>>>>>> is how we implemented it. But that is not true. It is perfectly va= lid for >>>>>>>> the passing of an ILP packet from one peer to another to be simply= an >>>>>>>> exchange of data. >>>>>>>> >>>>>>>> The receiving peer makes a decision about whether or not to forwar= d >>>>>>>> the packet based on the current financial position they have with = the >>>>>>>> sending peer. >>>>>>>> >>>>>>>> It is convenient if the ledger that records the net positions of >>>>>>>> the peers also forwards the messaging and even better if it native= ly >>>>>>>> supports conditional payments and can use the condition and the fu= lfillment >>>>>>>> from the ILP packet for those but that's all it is, convenient. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In that case, the plugin or whatever is doing the accounting is >>>>>>>>> the ledger. Digital value is always tracked in ledgers, so I thin= k it does >>>>>>>>> make sense to think of this as the base layer. The reason to abst= ract the >>>>>>>>> functionality you expect from the ledger layer is precisely so yo= u can >>>>>>>>> handle it in different ways, depending on what the underlying sys= tems >>>>>>>>> provide. >>>>>>>>> >>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>> >>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>>>> some type of HTLA >>>>>>>>> >>>>>>>>> 2. There are separate plugins for messaging and for transfers >>>>>>>>> and when you peer with someone you have to agree on a plugin f= or each >>>>>>>>> 3. We standardize the messaging part and say that all goes >>>>>>>>> over IP and then just have more minimal plugins for the on-led= ger >>>>>>>>> settlements >>>>>>>>> >>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>> sense. >>>>>>>>> >>>>>>>> >>>>>>>> I think you're confusing implementation details and defining of >>>>>>>> interfaces with definition of a protocol stack. The only differenc= es >>>>>>>> between the tree examples you have above is in implementation. >>>>>>>> >>>>>>>> From the perspective of the Interledger Protocol the implementatio= n >>>>>>>> of the lower layers is not important, that's the whole point of la= yering. >>>>>>>> By forcing important aspects of ILP like the condition, fulfillmen= t and >>>>>>>> expiry down into those layers you muddy the waters and we now have= to >>>>>>>> standardize those protocols too. Instead we should just be definin= g the >>>>>>>> functions they must provide and then leave it up to implementation= s to >>>>>>>> provide those functions. >>>>>>>> >>>>>>>> I know we want to define a standard to bootstrap the system (CLP) >>>>>>>> but that's misleading us into thinking it's an essential part of t= he stack. >>>>>>>> It's perfectly valid for two peers to not use CLP and still be par= t of the >>>>>>>> Interledger. >>>>>>>> >>>>>>>> That said, you raise an interesting consideration about the layers >>>>>>>> below ILP and actually I think it makes sense to split these. >>>>>>>> >>>>>>>> We keep trying to force messaging through the ledger layer and >>>>>>>> actually that's the wrong place to put it if we can split the ledg= er layer >>>>>>>> into a messaging layer and a ledger layer. That way we can stop tr= ying to >>>>>>>> think of all HLTAs as ledgers. >>>>>>>> >>>>>>>> A thought, why not use sub-layers as is common in other stacks: >>>>>>>> >>>>>>>> 1. Link layer: Layer upon which two peers that have a direct link, >>>>>>>> or participate in the same payment network, communicate >>>>>>>> 2. Transfer/ ledger: Layer on which financial positions between tw= o >>>>>>>> peers are recorded >>>>>>>> >>>>>>>> This reflects the already emerging HTLA model and many of our >>>>>>>> existing plugins and ledger integrations. >>>>>>>> Link Layer: XRP Paychan, Lightning >>>>>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>>>>> >>>>>>>> This doesn't prevent us from defining a standard binary protocol >>>>>>>> that defines all of the operations for both layers (like CLP) but = I see >>>>>>>> value in distinguishing between these two. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> > - The protocol should differentiate between the operation of >>>>>>>>> preparing a transfer on a ledger and the operation of passing an = ILP packet >>>>>>>>> from one peer to another. >>>>>>>>> >>>>>>>>> The protocol assumes your conditional transfer is underpinned by >>>>>>>>> some HTLA >>>>>>>>> . >>>>>>>>> It doesn't care whether that's on-ledger or not. >>>>>>>>> >>>>>>>> >>>>>>>> What do you mean when you say "the protocol"? In my statement I am >>>>>>>> referring to ILP. >>>>>>>> My point above being that ILP expects ILP packets to be passed fro= m >>>>>>>> peer to peer but has no expectations about transfers. >>>>>>>> >>>>>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>>>>> exchange ILP packets with no transfers. Clearly if a node routes a= packet >>>>>>>> on and has no incoming transfer it's going to lose money but that'= s a >>>>>>>> consideration for that node. It doesn't affect anyone else in the = chain. >>>>>>>> >>>>>>>> ILP doesn't assume anything about transfers at all, let alone >>>>>>>> conditional transfers. It provides useful semantics for conditiona= l >>>>>>>> transfers to be used by two peers to transact as part of a larger = ILP >>>>>>>> payment. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> > - The condition and timeout should be included in the ILP >>>>>>>>> payment packet. >>>>>>>>> >>>>>>>>> I strongly disagree with this. We had this debate a year ago and = I >>>>>>>>> was on your side but was convinced that this is not a good idea. >>>>>>>>> >>>>>>>> >>>>>>>> Yes, I recall this and I'm sorry I didn't push harder on this >>>>>>>> point. Unfortunately I think the decision to pull it out of the pa= cket is >>>>>>>> mostly driven by how our prototypes were implemented rather than g= ood >>>>>>>> architecture. >>>>>>>> >>>>>>>>> >>>>>>>>> The layer below ILP must be capable of doing conditional transfer= s >>>>>>>>> based on sha256 hashlocks with 32-byte preimages. >>>>>>>>> >>>>>>>> >>>>>>>> This is not true and I think it would be useful for us to agree on >>>>>>>> this as this seems to be the argument I am coming up against most = often. >>>>>>>> The peers participating in a transfer that is part of an ILP payme= nt may >>>>>>>> wish to use conditional transfers as a way to enforce their agreem= ent but >>>>>>>> this is not a requirement of the protocol. >>>>>>>> >>>>>>>> The agreement between any two peers is: "I will pay you X if you >>>>>>>> can provide a receipt that Y was paid Z before T". >>>>>>>> ILP provides a standard for expressing this agreement so that thes= e >>>>>>>> can be chained together BUT it is not a requirement that every agr= eement in >>>>>>>> the chain uses the condition, and fulfillment provided at the ILP = layer. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> As a result, the original condition and the corresponding preimag= e >>>>>>>>> MUST be expressed in that layer. >>>>>>>>> >>>>>>>> >>>>>>>> As I have shown above, this is not true. >>>>>>>> >>>>>>>> >>>>>>>>> Then the question is whether we should also include it in the >>>>>>>>> packet that is forwarded. What ultimately convinced me is the fol= lowing: >>>>>>>>> All connectors MUST ignore the condition if it is in the packet, = because >>>>>>>>> they are only guaranteed their money back if they use the same co= ndition >>>>>>>>> from the incoming transfer they got. >>>>>>>>> >>>>>>>> >>>>>>>> Here is where the layering is being corrupted. >>>>>>>> >>>>>>>> All connectors MUST inspect the condition in the ILP packet as par= t >>>>>>>> of their decision to route the packet or not. >>>>>>>> When the local transfer module of the connectors stack passes the >>>>>>>> ILP packet up to the ILP module it should indicate the properties = of the >>>>>>>> incoming transfer that carried the packet. >>>>>>>> This is essential firstly so that the routing logic in the ILP >>>>>>>> module can record the incoming transfer identifier so it is able t= o use the >>>>>>>> correct response id when it passes back the fulfillment or error. >>>>>>>> The other properties that the ILP module should look at are the >>>>>>>> condition and expiry on the incoming transfer. >>>>>>>> >>>>>>>> If the incoming route uses conditional transfers and these are >>>>>>>> supposed to match the condition and expiry in the ILP packet then = the ILP >>>>>>>> module should compare them and reject the packet if: >>>>>>>> a) the conditions don't match OR >>>>>>>> b) the expiry is too short >>>>>>>> >>>>>>>> We should still discuss if the expiry should be set by the sender >>>>>>>> and left unchanged or used like a TTL and decremented by each node= . >>>>>>>> >>>>>>>> >>>>>>>>> Also, the receiver will need to take out the condition in order t= o >>>>>>>>> hash the packet for PSK or IPR. >>>>>>>>> >>>>>>>> >>>>>>>> This is completely normal. Zeroing a checksum field in a header >>>>>>>> before calculating the checksum is VERY common precisely because i= t's long >>>>>>>> been accepted that the right place to put that data is in the head= ers and >>>>>>>> the work of zero'ing it out to calculate the checksum (or signatur= e in our >>>>>>>> case) is not material. >>>>>>>> >>>>>>>> >>>>>>>>> So basically, no one wants the condition in there. It feels like >>>>>>>>> it ought to be in there, but literally none of the parties want t= he extra >>>>>>>>> 32 bytes in there. >>>>>>>>> >>>>>>>> >>>>>>>> "Nobody wants it there" is a terrible reason to abandon the correc= t >>>>>>>> design. The whole purpose of a good architecture is you accept tha= t there >>>>>>>> may be cases in future that haven't been considered now so designi= ng just >>>>>>>> for the known cases is a bad idea. >>>>>>>> >>>>>>>> Good architecture is not the same as optimization. Taking stuff ou= t >>>>>>>> (even when it feels wrong) to save a few bytes is a good sign that= it's a >>>>>>>> bad idea. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> The reason the timeout should not be in there is that there isn't >>>>>>>>> a single timeout for the payment. There are multiple separate tim= eouts for >>>>>>>>> each of the bilateral transfers. Those must go in the individual = transfers >>>>>>>>> and there is no sensible value to put in the Interledger packet. >>>>>>>>> >>>>>>>> >>>>>>>> As above, this is somewhat equivalent to the TTL in an IP packet. >>>>>>>> I'm open to discussing if it should be a fixed value set by the se= nder >>>>>>>> where each node uses their own value but has the sender-defined va= lue as a >>>>>>>> reference or it is actually decremented at each hop. >>>>>>>> >>>>>>>> Either way, this is part of ILP not the ledger layer just like the >>>>>>>> condition and fulfillment. It may be used by the ledger layer but = that's >>>>>>>> implementation specific. It belongs in the ILP packet. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> -- >>>> Sent from a mobile device, please excuse any typos >>>> >>> >>> >> > --f403043ee9b09d3aff055707036d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On 18 August 2017 at 10:38, Ben Sharafian <sharafian@ripple.com= > wrote:
    Two connectors exchanging a transfer only care about = the data that is relevant to them for that transfer. It's quite possibl= e for two connectors to perform a transfer that has no conditions or fulfil= lments or a transfer that has a different condition and fulfillment (such a= s an atomic mode transfer where the condition is a compound one that has mu= ltiple sub-conditions).

    Yes, = two connectors could absolutely send an unconditional transfer on an underl= ying ledger in order to settle an Interledger payment. But in order to bene= fit from any of Interledger's guarantees (trustless connectors, retry-a= bility, etc.), they MUST keep a conditional local transfer, at least for cl= earing. If the local transfer cannot time out, it cannot be safely retried.= If the local transfer clears without a fulfillment, it loses the "rec= eipt or your money back" property. Yes, two parties in the chain could= eschew these benefits but that is no longer a correct implementation of In= terledger.

    Aha! That is where I= disagree! Interledger is not implemented at the local transfer layer, it i= s implemented at the Interledger layer. The whole point is that it an Inter= ledger payment can travel over payment networks that know nothing about ILP= but the greatest value comes from using ones that do.

    What you'= re describing is an implementation of a local transfer service that doesn&#= 39;t (or can't) take advantage of Interledger. In fact, this will be th= e norm for most existing payment networks that we want to add to the Interl= edger and this is where your work on payment channels and HTLAs comes in to= play.

    If you have a local transfer channel that doesn't suppor= t conditions natively or supports them in a way that requires some adaption= you can create an overlay network that does what's needed. Example: Bi= tcoin is not a suitable network to use for ILP so we use a payment channel = between the peers that is underwritten by Bitcoin.
    =C2=A0
    If a protocol at a lower layer wants to use that data then i= t must replicate it. That seems inefficient but it's the correct way to= do it.

    What's the actual= reasoning behind this, and why is it considered the correct approach? If t= here's some IETF document that says this I'd like to see it, becaus= e it intuitively feels wrong to have lower level abstractions looking into = higher levels.

    The data in the = ILP layer is there for a specific reason. It's part of an end-to-end ex= change between the sender and receiver.

    Side note: It's unusu= al to be designing the whole stack at once so we keep being tempted to move= things around but in reality we should look at the ILP layer in isolation = and make sure it is complete. Alternatively we should try to test our desig= n against a number of lower and upper layer protocols to make sure our thin= king is sound.

    If we assume the ILP packet is well defined with = all the ILP-required data elements then when a lower layer wants to use tha= t data it can but should do it in a way that doesn't break the ILP laye= r for everyone else. How that is implemented in practice will depend on the= lower layer protocol.
    =C2=A0

    Routing requires lookin= g at the condition, expiry and amount. A connector's routing logic shou= ldn't forward a packet if the expiry is too low or if the condition is = obviously corrupted.

    Those ar= e validity checks and you're right that they are performed in the conne= ctor, but the destination account, destination amount, and data are enough = to figure out what the best next hop is.

    <= /div>
    Unless the next hop is backwards
    =C2=A0

    The ILP Packe= t's purpose is to describe where a payment is going.

    Not only that. For comparison, an IP packet does= a lot more than just describe where a packet is going. All end-to-end conc= erns need to be in there too.
    =C2=A0
    The data it carries is only for the pur= pose of making sure the receiver can identify that payment.

    No, the condition is there so the receiver ca= n ensure it is sending back the correct fulfillment and the expiry to give = the receiver some assurance that the packet is still worth processing.
    <= /div>
    =C2=A0
    = In that context, the expiry has no bearing on where it will be routed nor o= n how much to route, only on whether or not an individual connector will ta= ke the risk of forwarding it.

    = The ILP packet just contains the end-to-end condition (always a SHA-256 has= h) and then the local transfer can have a different condition that is deriv= ed from the condition in the ILP packet.

    =
    Fair enough; in your case you can transmit the condition twice = and verify the structure of the complex local condition, and in the no-cond= ition-in-ILP version you can verify the structure of the local condition an= d extract the SHA256 condition to pass on.

    I think the expiry should always be the expiry set by the = sender. It won't be changed.=C2=A0

    That increases connector risk enormously, allowing anybody to cause a co= nnector to lose money by submitting a fulfillment at the last moment.

    Not at all. You're = assuming that there is no expiry on the local transfer. As a receiving node= I have an incoming transfer with an expiry and it carries an ILP packet th= at also has an expiry.

    My routing logic should look at bo= th and decide a) if this is safe to route on (i.e. put some of my own capit= al at risk) and b) what expiry to set on the next hop.

    Th= ere is no incentive to change the expiry in the packet as this can only be = targeted at upstream connectors and the result will simply be that the paym= ent is declined and the upstream local transfer rolls back.
    = =C2=A0
    If an attacker knows enoug= h about latency in the chain, they could even target this attack at somebod= y many hops away. Staggering expiries (giving you a minimum amount of time = to fulfill a source transfer) is an easy mitigation against this attack; we= shouldn't take it out.

    I agree. We would still have the local expiry.
    =C2= =A0

    Comparing the condition in the local transfer and the one in the ILP = packet should be part of the routing logic.

    Sure, it can be done as an extra validity check, but it'= s just more code and more attack surface.=C2=A0I still don't see any tangible benefit from doing the layering in = this way, aside from your assertion that it's the correct way to do it.= If you've read any documents that explain why this is the correct way = to do layering, I think I'd understand you better.


    On Thu, Aug 17, 2017 at 7:32 PM, Adrian Hope-Bailie <adr= ian@hopebailie.com> wrote:
    =


    On 16 August 2017 at 10:22, Ben Sharafian <<= a href=3D"mailto:sharafian@ripple.com" target=3D"_blank">sharafian@ripple.c= om> wrote:
    OK, = I think in that case we're mostly disagreeing over where the condition/= fulfillment/expiry actually go in the data.

    That's one way to look at it but that'= s ultimately what the architecting the layering is. Deciding at which layer= (and therefor encapsulated in what packet) certain data should be.
    =C2=A0
    The rea= son I don't agree with your position is based on which parties I think = should be aware of ILP.

    I don't think that's the right way to look at it. The conn= ector needs to be able to understand at least the ILP layer data AND the lo= wer layer data. Normally the way the processing stack is implemented is tha= t there is a module for each layer that processes the data from that layer = and then passes the payload and any other important information up to the n= ext layer.
    =C2=A0
    <= span class=3D"m_-4592474860300132566m_-291143135448144913im m_-459247486030= 0132566m_-291143135448144913HOEnZb">
    In order to track the balance between each other accurate= ly, the two connectors have to keep track of conditions, fulfillments, and = expiries on each of the transfers.

    This is where I disagree with you. Two connectors exchanging a= transfer only care about the data that is relevant to them for that transf= er. It's quite possible for two connectors to perform a transfer that h= as no conditions or fulfillments or a transfer that has a different conditi= on and fulfillment (such as an atomic mode transfer where the condition is = a compound one that has multiple sub-conditions).
    =C2= =A0
    That means the connector= s' accounting logic that handles the conditions, fulfillments, and expi= ries is going to be using some information inside the ILP packet and some i= nformation outside of it in order to perform these transfers.

    It will only use info inside t= he packet if it uses conditional transfers that use that same condition. Th= is is the most likely scenario but that is not a protocol requirement.
    <= /div>
    =C2=A0

    <= /div>
    I think it's cleaner to say everyt= hing required to make these local transfers should go in one protocol, so t= he accounting logic of these connectors doesn't have to deal with ILP d= irectly.

    I stron= gly disagree with that. That's entirely the wrong reason to put data in= to a specific layer. The data in the ILP layer is there because it's &q= uot;end-to-end" data.

    If a protocol at a lower layer= wants to use that data then it must replicate it. That seems inefficient b= ut it's the correct way to do it.

    One could define a = lower layer protocol that doesn't replicate the data but the rules of t= he protocol are "Get the condition from the ILP packet". In that = case, that specific lower level protocol is forcing implementations to unde= rstand the ILP packet format, that's an implementation detail.

    <= /div>
    Another lower layer protocol might take the condition from the IL= P packet and re-encode it in a different form (like a base64ulr string or N= I: uri)
    =C2=A0
    Then the connectors' ILP-packet-related behavior can all be rout= ing related.

    Rou= ting requires looking at the condition, expiry and amount. A connector'= s routing logic shouldn't forward a packet if the expiry is too low or = if the condition is obviously corrupted.

    If the protocols= were designed correctly as I am proposing then another routing decision wo= uld be, is the condition that was used in the incoming transfer the same as= the one used in the ILP packet?

    =C2=A0=
    <= div dir=3D"ltr">
    This would add a few benefi= ts; two connectors could perform non-ILP conditional transfers between one = another (which would be useful for reconciliation and settlement), and coul= d also allow two connectors to use more complex condition types (i.e. signa= tures for atomic mode) without forcing us to support that in the ILP packet= .

    You seem to ha= ve this backwards. Both of these things are supported if the condition and = expiry ARE in the ILP packet. Atomic mode is not supported in the ILP proto= col it is supported in the lower layer transfer protocol. The ILP packet ju= st contains the end-to-end condition (always a SHA-256 hash) and then the l= ocal transfer can have a different condition that is derived from the condi= tion in the ILP packet.
    =C2=A0
    It also keeps the integrity of the ILP packet as s= omething lower levels don't modify; the connector has to modify the exp= iry in order to pass along an ILP payment (they may not modify the expiry i= f they're using something like atomic mode, but then we have the issue = with advanced condition types not being supported in the ILP packet).
    =

    I think the expiry should a= lways be the expiry set by the sender. It won't be changed.
    <= div class=3D"gmail_quote">
    =
    In the case where the ledger _doe= s_ care about the condition and fulfillment, the argument in favor of separ= ating condition/fulfillment/expiry from the rest of the packet is similar. = Because we don't control the features of all ledgers, we'll need ou= r plugins or ledger adapters to be aware of ILP. This makes it hard to inte= ract with any events that don't involve ILP packets, and impossible to = handle features that extend beyond what we support in the ILP packet. We co= uld pass details about non-ILP ledger features (like a crypto condition) in= the side data, but in the event of any redundancy we have to check the led= ger-supplied info, not the info in the ILP packet.

    Comparing the condition in the local tran= sfer and the one in the ILP packet should be part of the routing logic.
    =
    =C2=A0

    =
    Basically, condition/fulfillment/expi= ry are used for accounting local transfers (even if they aren't being &= quot;ledger" enforced) in addition to their role as every-hop informat= ion. By putting them in the ILP packet, we limit the special features that = ledgers can support and make our software abstractions harder to separate c= leanly. By putting them in the local transfer alongside the ILP packet but = not inside it, we do separate the data a little more, but we have more free= dom in what the underlying accounting and ledger logic can do, and our soft= ware modules will have more clearly separated domains.

    They should be in both the local tran= sfer AND the ILP packet if they are needed by the local transfer protocol. = This allows the flexibility you desire because the local transfer protocol = can do ANYTHING including using the condition from the ILP packet as-is, no= t at all or enhanced for something like atomic mode.

    =C2=A0
    <= div class=3D"m_-4592474860300132566m_-291143135448144913h5">

    On Tue, Aug 15, 2017 at 10:24 AM= , Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    Exactly =F0=9F=91=8D

    On Tue, Aug 15, 2017 at= 6:52 PM Ben Sharafian <sharafian@ripple.com> wrote:
    Ok, I think I have a better idea of what you're sayi= ng.

    It sounds like you're saying the ILP layer conta= ins all information that is common between every hop (destination, destinat= ion amount, opaque data, condition, fulfillment, expiry). The lower level w= ould then be used for all the transfer-local details (source amount, next c= onnector account, custom/local data).

    If the lower= level wanted to do anything related to the every-hop payment, i.e. escrow = funds until the receipt has been produced, it would look into the ILP layer= for that information. If the lower level didn't do any escrow or expir= ies that require every-hop details, it would simply function as a communica= tion method.

    Is that right?

    On Tue, Aug 15, 2017 at 6:3= 5 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    On 15 August 2017 at 16:00, Ben Sharafian <sharafian@ripple.com= > wrote:
    In th= at case, the plugin or whatever is doing the accounting is the ledger. Digi= tal value is always tracked in ledgers, so I think it does make sense to th= ink of this as the base layer. The reason to abstract the functionality you= expect from the ledger layer is precisely so you can handle it in differen= t ways, depending on what the underlying systems provide.
    I see= 3 ways to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messa= ging capabilities and some type of=C2=A0HTLA
    1. There are separate plugins for messaging and for tran= sfers and when you peer with someone you have to agree on a plugin for each=
    1. We standardize the messaging p= art and say that all goes over IP and then just have more minimal plugins f= or the on-ledger settlements
    Number 1 is what we have and I think = that still makes the most sense.

    =
    I think you're confusing implementation details and defining of= interfaces with definition of a protocol stack. The only differences betwe= en the tree examples you have above is in implementation.

    I had to scroll up after reading this to make = sure it was @adrian talking, because that seems like the opposite of what y= ou were arguing for.

    I = don't think so. But I think that is part of the problem. We are not all= focused on the same thing. I am actually not very interested in CLP at all= . It is one of potentially many protocols that may exist below the ILP laye= r. All we're doing by defining CLP is bootstrapping the network by defi= ning a protocol for everyone to use to get started.

    In de= signing the ILP layer properly we should try and forget everything we know = about the lower layers other than what features we require of them.

    =
    There is a misconception that ILP requires the lower layers to s= upport conditional transfers, that is not true.

    All we ac= tually need from a lower layer protocol is to transfer data back and forth = and provide a way to reliably map requests to responses.

    = What ILP provides lower layers is a way to reward your peer for passing on = the packet. The Internetworking layer defines a condition, a reward that mu= st be paid to the receiver for the fulfillment and the time allowed to clai= m this reward.

    Because of this, within lower-l= ayer protocols that offer the basic request/response features we need, we c= ould add conditional payment semantics that use the condition, expiry and f= ulfillment provided by ILP. This would allow a node to offer a reward to=C2= =A0 their next peer to for delivering the packet they send them and to make= the local financial transaction contingent on the end-to-end transaction.<= br>
    But crucially, adding that semantic to the lower layer pr= otocol provides nothing extra to the ILP layer. The value is purely derived= from the two peers who use that protocol and can now use conditional payme= nts to protect themselves from their peers.
    =C2=A0
    The proposal t= hat you're arguing for is basically asserting that we're going to b= e using CLP, because it makes the assumption that the connectors (who under= stand ILP) are managing the HTLA logic.

    Not at all. I am asserting that it doesn't matter what = protocol you use below the ILP layer because it shouldn't matter. All o= f this talk about ILP being different because money is more important than = data is nonsense.

    The difference between ILP and IP that makes= ILP suitable for value transfer and IP not is at the internetworking layer= . ILP requires that all packets are either a request or response and that t= he responses follow the same path as the requests. Further ILP defines a si= gnature scheme that gives the sender a way to be certain the request was re= ceived by the receiver.

    This cou= ld be done entirely without money but then there would be little incent= ive to sign the receipt or deliver the signature back to the original sende= r.

    So, if you add money then you ad= d economic incentives to the mix. At each hop the sender promises the next = upstream peer a payment if they can return the receipt. The net effect is t= hat this can be used to transfer money from the sender to the receiver by s= imply defining up front the amount that the receiver must get to produce th= e signature.
    =C2=A0

    In the current model, the CLP/trustline model and th= e direct ledger model both work without having to treat anything on the ILP= layer differently. We're favoring on-ledger messaging because of our i= mplementation, yes, but we've been able to switch most all of our plugi= ns from on-ledger messaging to RPC-based messaging without changing the ILP= layer at all.

    With the ledger-level abstraction, = we were able to switch from our ledger-based mode of thinking to the CLP/tr= ustline based way without changing anything other than the plugin. Your arg= ument comes from an assumption of a CLP-style ledger protocol with some und= erlying ledger, which we can't assume is always the case.

    I'm not sure what any of that proves t= bh. These are all implementation concerns. They don't change the fact t= hat the condition, expiry and fulfillment are part of ILP not the lower lay= er protocols.
    =C2=A0

    From the= perspective of the Interledger Protocol the implementation of the lower la= yers is not important, that's the whole point of layering. By forcing i= mportant aspects of ILP like the condition, fulfillment and expiry down int= o those layers you muddy the waters and we now have to standardize those pr= otocols too. Instead we should just be defining the functions they must pro= vide and then leave it up to implementations to provide those functions.

    I don't agree with this poi= nt; the condition and fulfillment have actual meaning to the ledger layer. =

    NO THEY DON'T! They= have meaning to SOME ledgers that implement SOME lower layer protocols, IF= they choose to use them.

    Excuse the shouting but this is= the crux of the issue. We need to all agree that it is entirely possible f= or a transfer to be done that doesn't use the condition and fulfillment= and that if this was in the middle of a 10-hop ILP payment it would have n= o effect on the sender and receiver.
    =C2=A0
    You've said that the ledger = often doesn't care about fulfillment and condition, but the ledger _lay= er_'s (where transfers are done) role is to take in condition and fulfi= llment and make a transfer which satisfies its HTLA.

    No, the ledger's role is to keep a tab of net = financial positions between two peers. It MAY use conditions and fulfillmen= ts that it pulls from the ILP layer to help it do that in a way both peers = agree on.

    Note that a "layer&q= uot; doesn't have a role. I think there is some confusion about the dif= ference between layering the protocol and abstracting functionality into di= fferent components.
    =C2=A0
    If the ledger layer has to look into the ILP packet to do so= , that is a blatant breaking of layering.
    Not at all! The module acting at the layers below= the internetworking layer shouldn't modify anything inside the packets= of the higher layers but they can definitely inspect them and adjust their= behavior based on what they to find.

    In fact the prevalence o= f this is the subject of a lot of debate at the IETF currently because endp= oints are often encrypting their payloads and in some cases this makes it d= ifficult for middle-boxes to be effective at their jobs.

    By putting the condition, fulfillment, and expiry on the ledge= r layer, we leave it open for any ledger type to work, rather than forcing = all ledger-layer software to understand ILP.
    <= br>
    Actually you do the opposite. You make it a requiremen= t of every protocol below the ILP layer to define a way to carry these data= elements and encode and decode them, even if they don't use them
    Ledger layer components don't have to understand ILP unles= s they choose to re-use the condition for their own local transfer. Ledgers= themselves never have to understand ILP.

    Remember a ledger = layer protocol could use a completely different conditional payments scheme= , like atomic mode ILP, where it takes the end-to-end condition and creates= a new compound condition that depends on the fulfillment and some notary s= ignature.

    There will be a component in a connector's = stack that must pass the ILP packet to the next peer. If it does this using= a transfer protocol that uses conditional transfers and wants to use the s= ame condition as the ILP packet then it must decode the packet.

    But, it will likely do something with that condition before sending = the transfer to the ledger like encoding it differently or rehashing it (li= ghtning?) so that it's in the form expected by the ledger.

    That's an implementation decision of the lower layer p= rotocol used between those two peers.
    =C2=A0

    I agr= ee that Interledger defines how conditions, fulfillments, and expiries shou= ld be chained together, but it makes no assertions about their data format.=

    ILP doesn't define= how anything is chained together. From the perspective of ILP the conditio= n and fulfillment are end-to-end data. They are agreed by the two endpoints= who don't care how they get from Alice to Bob and back.

    <= div>The design of ILP is such that it facilitates the design of lower level= protocols that can be used to carry the ILP packets across multiple hops (= networks) using economic incentives such that the sender pays enough for th= e first hop to ensure that all nodes in between can extract the fee they wa= nt and the receiver will still get the amount they expected..

    =
    =C2=A0
    ILP says you should send your outgoing transfer with the same condi= tion as the incoming one, and a lower expiry.

    No it doesn't. An internetworking protocol can&#= 39;t prescribe that kind of thing to lower level protocols. An incoming and= outgoing transfer could be sent using completely different protocols and t= he financial agreement with the peers on those two routes could be vastly d= ifferent too.

    The only service ILP requires of lower level protocols= is that they can map a response to an original request. This requirement i= s okay because it is isolated to a single route/link at a time not a requir= ement that crosses the inter-network boundary that ILP crosses.
    =C2=A0
    But because ILP allows for many different types of ledgers, it doesn&= #39;t make sense to assert how these are encoded.
    <= div>
    By putting them in the ILP packet you do the oppo= site. You make no assertions about how they are encoded if they are used at= lower layers, or how they may be combined with other conditions or even us= ed to derive new conditions.

    IP doesn't tell you how to = encode an ethernet packet. It doesn't even know whether it's going = over a computer or a hand-written letter carried by a pigeon. IP takes for = granted that you can send data over one connection by putting it in a lower= level.

    Correct, but if= a link layer protocol wanted to look into the IP packet headers of a packe= t it wants to transfer and use some data from there in its internal logic (= or even reuse data in it's own frame) that would be totally fine.
    =C2=A0
    IP also assumes that if you get some incoming data on a con= nection you can copy it and send it out on the next connection. Because you= can already send data over a connection, all IP adds is the missing piece:= a packet that tells you where to go.

    With ILP, we= assume that there is a way to prepare a conditional transfer, expire a con= ditional transfer, and fulfill a conditional transfer.

    No we don't! We assume that if we deliv= er the packet as intended we'll get back a response packet with a signa= ture that matches the condition in the packet. So, if we have an agreement = with someone that they will pay us when we present that signature then we a= re prepared to enter a similar agreement with the next peer because we expe= ct that signature to come all the way back along the interledger layer rout= e..
    =C2=A0
    We also assume that if you get an incoming transfer yo= u can create an outgoing transfer with the same condition. The abstraction = we made means that conditions and fulfillments are already carried in the l= ower levels.

    That is a b= ad assumption that comes from the broken layering. What if my outgoing link= doesn't support conditional transfers? So now where do I put the condi= tion?
    =C2=A0
    =C2=A0

    On Tue, Aug 15, 2017 at 12:04 PM, Adrian Ho= pe-Bailie <adrian@hopebailie.com> wrote:


    On 14 August 2017 at 22:03, Evan Schwartz <= ;evan@ripple.com&g= t; wrote:
    = I think this thread is going to get extremely unwieldy but here goes:=

    >=C2=A0- All int= erledger layer messages should be ILP packets (including fulfillments) and = be capable of carrying higher layer protocol payloads.
    Interledger has higher requirements than ILP for the low= est layer, specifically because we are carrying money and not just data. On= e of the requirements is being able to transmit a 32-byte fulfillment back = along the same path that carried the payment originally. If we expect this = of the lower layer, I don't see a point in putting the fulfillment into= an ILP packet and transmitting it as Interledger data along the same path.= All ledger-layer protocols will need to interpret the fulfillment passed i= n their protocol, not the one passed through the Interledger layer.

    This is not correct. There is no req= uirement on ledger layer protocols to transmit or understand the fulfillmen= t. You are looking at this through the lens of existing implementations fro= m the bottom up instead of starting at the interledger layer.

    The primary function of the condition and fulfi= llment is as a signed end-to-end receipt. If the sender agrees a condition = with a receiver and then gets back the valid fulfillment they don't car= e what happened in the middle. The receiver has signed a receipt saying the= y have their money.

    The value of us= ing a standard for the receipt and signature is that each transfer along th= e way CAN re-use it. One the one hand you can have a transfer between two p= eers that have zero trust and the ledger they use supports conditional paym= ents completely. On the other extreme you can have two peers that have a fu= ll trust and ignore the condition and fulfillment completely.
    =C2= =A0
    The ledger layer protocols carry IL= P packets. Payment requests and either fulfillment or error responses. If a= ledger layer protocol wants to use the condition and fulfillment for their= own operations they can extract these from the ILP packets and use them.


    >=C2=A0- While it may make sense = to split the interledger payment and interledger quoting protocols into new= higher level protocols that seems like an unnecessary abstraction. Instead= the packet definitions should just have some consistency and probably a co= mmon base/header.

    =
    The current pr= otocols effectively have this header but it isn't separated out. There = are two fields in the request header: type and destination address. There i= s one field in the response header: type. I don't think it makes that m= uch of a big difference to separate these fields if all of the fields in th= at packet need to be interpreted together (for example, you can't under= stand a quote request if you strip off the destination address).

    I agree that we don't H= AVE to explicitly separate them out but I think ti would make it clearer ho= w the stack is architected if there was a header that was consistent across= all packets. Currently the only thing that is consitent across all ILP pac= kets is that they are defined int he same file.
    =C2=A0<= /div>

    >=C2=A0- We sh= ould define two base ILP packet types: request and response.
    Unless this adds some substantive benefi= t or new fields I don't think it's worth breaking all of the format= s we have just to rearrange things.

    =
    The goal of this exercise is to tease out the best design and i= gnore the cost of change until we can compare the results with the current = design.
    =C2=A0

    >=C2=A0- ILP is not about ledgers, it is about trustlines between= nodes/hosts.

    A l= edger is any system that tracks accounts and balances. When you use a trust= line all of your messages still need to go through an accounting system (su= ch as the plugin in the JS implementation) and then on to the other program= logic.

    As above, this = is incorrect. There is no requirement for "all messages to go through = an accounting system".

    Since designing the first imp= lementation of 5-bells ledger we have assumed that passing the ILP packet M= UST be done by the ledger because that is how we implemented it. But that i= s not true. It is perfectly valid for the passing of an ILP packet from one= peer to another to be simply an exchange of data.

    The re= ceiving peer makes a decision about whether or not to forward the packet ba= sed on the current financial position they have with the sending peer.
    <= /div>

    It is convenient if the ledger that records the ne= t positions of the peers also forwards the messaging and even better if it = natively supports conditional payments and can use the condition and the fu= lfillment from the ILP packet for those but that's all it is, convenien= t.

    =C2=A0
    In that case, the plugin or whatever is doing the a= ccounting is the ledger. Digital value is always tracked in ledgers, so I t= hink it does make sense to think of this as the base layer. The reason to a= bstract the functionality you expect from the ledger layer is precisely so = you can handle it in different ways, depending on what the underlying syste= ms provide.

    I see 3 ways to think of the layer(s) = underpinning ILP:
    1. The "Ledger Layer= " provides both messaging capabilities and some type of HTLA
    2. There are separate plugins for messaging and for transfers and when yo= u peer with someone you have to agree on a plugin for each
    3. We stand= ardize the messaging part and say that all goes over IP and then just have = more minimal plugins for the on-ledger settlements
    Number 1 i= s what we have and I think that still makes the most sense.

    I think you're confusing implementation detai= ls and defining of interfaces with definition of a protocol stack. The only= differences between the tree examples you have above is in implementation.=

    From the perspective of the Interledger Protocol the implementation= of the lower layers is not important, that's the whole point of layeri= ng. By forcing important aspects of ILP like the condition, fulfillment and= expiry down into those layers you muddy the waters and we now have to stan= dardize those protocols too. Instead we should just be defining the functio= ns they must provide and then leave it up to implementations to provide tho= se functions.

    I know we want to def= ine a standard to bootstrap the system (CLP) but that's misleading us i= nto thinking it's an essential part of the stack. It's perfectly va= lid for two peers to not use CLP and still be part of the Interledger.
    <= /div>

    T= hat said, you raise an interesting consideration about the layers below ILP= and actually I think it makes sense to split these.

    We k= eep trying to force messaging through the ledger layer and actually that= 9;s the wrong place to put it if we can split the ledger layer into a messa= ging layer and a ledger layer. That way we can stop trying to think of all = HLTAs as ledgers.

    A thought, why not use sub-layers as is= common in other stacks:

    1. Link layer: Layer upon which = two peers that have a direct link, or participate in the same payment netwo= rk, communicate
    2. Transfer/ ledger: Layer on which financial= positions between two peers are recorded

    This reflects the already = emerging HTLA model and many of our existing plugins and ledger integration= s.
    Link Layer: XRP Paychan, Lightning
    Ledger La= yer: XRP Ledger, Bitcoin

    This doesn't prev= ent us from defining a standard binary protocol that defines all of the ope= rations for both layers (like CLP) but I see value in distinguishing betwee= n these two.
    =C2=A0

    >=C2=A0- The protocol should differentiate between the opera= tion of preparing a transfer on a ledger and the operation of passing an IL= P packet from one peer to another.

    The protocol assumes your conditional transfer is underpi= nned by some HTLA. It doesn't care whether that's on-ledger or not.<= /div>

    What do you mean when you say= "the protocol"? In my statement I am referring to ILP.
    My po= int above being that ILP expects ILP packets to be passed from peer to peer= but has no expectations about transfers.

    It's perfectly legal (from an ILP perspective) for two peers to = exchange ILP packets with no transfers. Clearly if a node routes a packet o= n and has no incoming transfer it's going to lose money but that's = a consideration for that node. It doesn't affect anyone else in the cha= in.

    ILP doesn't assume anything= about transfers at all, let alone conditional transfers. It provides usefu= l semantics for conditional transfers to be used by two peers to transact a= s part of a larger ILP payment.
    =C2=A0
    =
    >=C2=A0- The conditio= n and timeout should be included in the ILP payment packet.

    I strongly disagree with this. We had this debate a= year ago and I was on your side but was convinced that this is not a good = idea.

    Yes, I recall this= and I'm sorry I didn't push harder on this point. Unfortunately I = think the decision to pull it out of the packet is mostly driven by how our= prototypes were implemented rather than good architecture.
    =

    = The layer below ILP must be capable of doing conditional transfers based on= sha256 hashlocks with 32-byte preimages.
    This is not true and I think it would be useful for us t= o agree on this as this seems to be the argument I am coming up against mos= t often. The peers participating in a transfer that is part of an ILP payme= nt may wish to use conditional transfers as a way to enforce their agreemen= t but this is not a requirement of the protocol.

    The agre= ement between any two peers is: "I will pay you X if you can provide a= receipt that Y was paid Z before T".
    ILP provides a sta= ndard for expressing this agreement so that these can be chained together B= UT it is not a requirement that every agreement in the chain uses the condi= tion, and fulfillment provided at the ILP layer.

    =C2=A0<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
    As a result, the= original condition and the corresponding preimage MUST be expressed in tha= t layer.

    As I have show= n above, this is not true.
    =C2=A0
    Then the question is whether we= should also include it in the packet that is forwarded. What ultimately co= nvinced me is the following: All connectors MUST ignore the condition if it= is in the packet, because they are only guaranteed their money back if the= y use the same condition from the incoming transfer they got.
    <= /blockquote>

    Here is where = the layering is being corrupted.

    All connectors MUST inspect the con= dition in the ILP packet as part of their decision to route the packet or n= ot.
    When the local transfer module of t= he connectors stack passes the ILP packet up to the ILP module it should in= dicate the properties of the incoming transfer that carried the packet.
    =
    This is essential firstly so that the rout= ing logic in the ILP module can record the incoming transfer identifier so = it is able to use the correct response id when it passes back the fulfillme= nt or error.
    The other properties that the ILP module should look at are= the condition and expiry on the incoming transfer.

    If the incoming route uses conditional tra= nsfers and these are supposed to match the condition and expiry in the ILP = packet then the ILP module should compare them and reject the packet if:
    a) the conditions don't match OR
    b) the expir= y is too short

    We should still discuss if the expiry shou= ld be set by the sender and left unchanged or used like a TTL and decrement= ed by each node.
    =C2=A0
    Also, the receiver will need to take out = the condition in order to hash the packet for PSK or IPR.

    This is completely normal. Zeroing a che= cksum field in a header before calculating the checksum is VERY common prec= isely because it's long been accepted that the right place to put that = data is in the headers and the work of zero'ing it out to calculate the= checksum (or signature in our case) is not material.
    = =C2=A0
    So = basically, no one wants the condition in there. It feels like it ought to b= e in there, but literally none of the parties want the extra 32 bytes in th= ere.

    "Nobody wants = it there" is a terrible reason to abandon the correct design. The whol= e purpose of a good architecture is you accept that there may be cases in f= uture that haven't been considered now so designing just for the known = cases is a bad idea.

    Good architecture is not the same as= optimization. Taking stuff out (even when it feels wrong) to save a few by= tes is a good sign that it's a bad idea.
    =C2=A0

    The reason the timeout should not be in there is that there isn't a s= ingle timeout for the payment. There are multiple separate timeouts for eac= h of the bilateral transfers. Those must go in the individual transfers and= there is no sensible value to put in the Interledger packet.
    =C2=A0
    As above, this is somewhat equivale= nt to the TTL in an IP packet. I'm open to discussing if it should be a= fixed value set by the sender where each node uses their own value but has= the sender-defined value as a reference or it is actually decremented at e= ach hop.

    Either way, this is part of ILP not the ledger l= ayer just like the condition and fulfillment. It may be used by the ledger = layer but that's implementation specific. It belongs in the ILP packet.=
    =C2=A0





    --
    Sent from a mobile device, please excuse any = typos




    --f403043ee9b09d3aff055707036d-- From nobody Fri Aug 18 07:09:43 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2896D13218E for ; Fri, 18 Aug 2017 07:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ripple.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 X2g4MUfQ1Bst for ; Fri, 18 Aug 2017 07:09:34 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 94644120721 for ; Fri, 18 Aug 2017 07:09:33 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id l19so828044wmi.1 for ; Fri, 18 Aug 2017 07:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h9cMTskaglfRa2ETUc4NR9ha9m/bDCHDy7aKDtJ6tzY=; b=CcCsrzIkhg2Ik4F2owgnYsXuOqRS4ZOadWP7H4HFWU9H4Vrl/JwmosOGrTHyh8YTia v2OzzGlf2JtfRMHMUtj2BAPdcXxNuoNCRw+fBBBww2rF5FXxQFEMoKmoAwx+FLsGp6C7 ohPn19rJP2BSEzW0LFs0BPYeHQNBfjPbLg87U= 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=h9cMTskaglfRa2ETUc4NR9ha9m/bDCHDy7aKDtJ6tzY=; b=mH3Sa1UbWf2H11pUVRyJ5Zhy0s02jwH0rSu+I3b4X1DYKk91O2V0RyRiOEAwwAvLPP nr+2k3Fwez0vvWB9sg1dula79VQyB7h+A6ZplXvcZXdTa9AXvv7fj1YTIjgNT3Q3szyM 6lbJ9y5JgElAZpSrXSHmpVYYg6mmzSM7OsDxav/DB1PPAKpLHAGFHIXDgJozfyqp8Caf tQy7Qqfs/Eh7yFq6nXO9GmXmw8BMdZmSnkKvjNm5aOjhSp/sQguQhLiRpKG51Mwy1Sar zLYhG3hDEPXMjW69TWau8RhD5a5kdRv93EVv6fIuNdeq0wWnoHIvvLCAiuaQ9vxOZft1 /SkA== X-Gm-Message-State: AHYfb5gY/EefYWrscB9t88qEn1EeSqSKsIQYJMjwzeRR479Xeiw78NVG WdfuNqtI8oX7J4M+EjasH7EjVxbmlwvx X-Received: by 10.28.194.138 with SMTP id s132mr1822021wmf.29.1503065371695; Fri, 18 Aug 2017 07:09:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.60.135 with HTTP; Fri, 18 Aug 2017 07:09:30 -0700 (PDT) In-Reply-To: References: From: Ben Sharafian Date: Fri, 18 Aug 2017 16:09:30 +0200 Message-ID: To: Adrian Hope-Bailie Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1148d5b28e078f055707adb9" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 14:09:41 -0000 --001a1148d5b28e078f055707adb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > What you're describing is an implementation of a local transfer service > that doesn't (or can't) take advantage of Interledger. In fact, this will > be the norm for most existing payment networks that we want to add to the > Interledger and this is where your work on payment channels and HTLAs com= es > in to play. > > If you have a local transfer channel that doesn't support conditions > natively or supports them in a way that requires some adaption you can > create an overlay network that does what's needed. Example: Bitcoin is no= t > a suitable network to use for ILP so we use a payment channel between the > peers that is underwritten by Bitcoin. Exactly, when I say you need a to handle the condition and fulfillment via a clearing layer, this "overlay network" is what I'm referring to. The whole point of an HTLA is that from ILP's point of view it's just a lower-level protocol that can commit conditional transfers and fulfill them. ILP doesn't care how the ledger/HTLA works under the hood, whether it's a clearing/overlay layer or a "real" ledger. You're equating this "overlay network," which is a type of ledger, with the ILP layer. If there is an overlay network that handles the condition and fulfillment, that means you _are_ using a ledger, because the overlay network _is_ a ledger. The ILP layer is a layer above this. If we assume the ILP packet is well defined with all the ILP-required data > elements then when a lower layer wants to use that data it can but should > do it in a way that doesn't break the ILP layer for everyone else. How th= at > is implemented in practice will depend on the lower layer protocol. That's one way to see it, but what I'm wondering is why that's a better model than saying there's a clearly defined interface that the ledger-layer exposes, and then building the ILP layer on top of that. Unless the next hop is backwards There's no reason to send a backwards hop. If you don't want to forward a payment you reject it. Not at all. You're assuming that there is no expiry on the local transfer. > As a receiving node I have an incoming transfer with an expiry and it > carries an ILP packet that also has an expiry. If that's what you're talking about, the ILP packet already has an expiry. It's implemented in the PSK details so the receiver knows whether the packet it issued is still valid. But that's an application layer concern, because it's only the receiver who looks at the ILP packet's expiry. The connectors only need to know the expiries of the local transfers. On Fri, Aug 18, 2017 at 3:21 PM, Adrian Hope-Bailie wrote: > > > On 18 August 2017 at 10:38, Ben Sharafian wrote: > >> Two connectors exchanging a transfer only care about the data that is >>> relevant to them for that transfer. It's quite possible for two connect= ors >>> to perform a transfer that has no conditions or fulfillments or a trans= fer >>> that has a different condition and fulfillment (such as an atomic mode >>> transfer where the condition is a compound one that has multiple >>> sub-conditions). >> >> >> Yes, two connectors could absolutely send an unconditional transfer on a= n >> underlying ledger in order to settle an Interledger payment. But in orde= r >> to benefit from any of Interledger's guarantees (trustless connectors, >> retry-ability, etc.), they MUST keep a conditional local transfer, at le= ast >> for clearing. If the local transfer cannot time out, it cannot be safely >> retried. If the local transfer clears without a fulfillment, it loses th= e >> "receipt or your money back" property. Yes, two parties in the chain cou= ld >> eschew these benefits but that is no longer a correct implementation of >> Interledger. >> > > Aha! That is where I disagree! Interledger is not implemented at the loca= l > transfer layer, it is implemented at the Interledger layer. The whole poi= nt > is that it an Interledger payment can travel over payment networks that > know nothing about ILP but the greatest value comes from using ones that = do. > > What you're describing is an implementation of a local transfer service > that doesn't (or can't) take advantage of Interledger. In fact, this will > be the norm for most existing payment networks that we want to add to the > Interledger and this is where your work on payment channels and HTLAs com= es > in to play. > > If you have a local transfer channel that doesn't support conditions > natively or supports them in a way that requires some adaption you can > create an overlay network that does what's needed. Example: Bitcoin is no= t > a suitable network to use for ILP so we use a payment channel between the > peers that is underwritten by Bitcoin. > > >> >> If a protocol at a lower layer wants to use that data then it must >>> replicate it. That seems inefficient but it's the correct way to do it. >> >> >> What's the actual reasoning behind this, and why is it considered the >> correct approach? If there's some IETF document that says this I'd like = to >> see it, because it intuitively feels wrong to have lower level abstracti= ons >> looking into higher levels. >> > > The data in the ILP layer is there for a specific reason. It's part of an > end-to-end exchange between the sender and receiver. > > > *Side note: It's unusual to be designing the whole stack at once so we > keep being tempted to move things around but in reality we should look at > the ILP layer in isolation and make sure it is complete. Alternatively we > should try to test our design against a number of lower and upper layer > protocols to make sure our thinking is sound.* > If we assume the ILP packet is well defined with all the ILP-required dat= a > elements then when a lower layer wants to use that data it can but should > do it in a way that doesn't break the ILP layer for everyone else. How th= at > is implemented in practice will depend on the lower layer protocol. > > >> >> Routing requires looking at the condition, expiry and amount. A >>> connector's routing logic shouldn't forward a packet if the expiry is t= oo >>> low or if the condition is obviously corrupted. >> >> >> Those are validity checks and you're right that they are performed in th= e >> connector, but the destination account, destination amount, and data are >> enough to figure out what the best next hop is. >> > > Unless the next hop is backwards > > >> >> The ILP Packet's purpose is to describe where a payment is going. >> > > Not only that. For comparison, an IP packet does a lot more than just > describe where a packet is going. All end-to-end concerns need to be in > there too. > > >> The data it carries is only for the purpose of making sure the receiver >> can identify that payment. >> > > No, the condition is there so the receiver can ensure it is sending back > the correct fulfillment and the expiry to give the receiver some assuranc= e > that the packet is still worth processing. > > >> In that context, the expiry has no bearing on where it will be routed no= r >> on how much to route, only on whether or not an individual connector wil= l >> take the risk of forwarding it. >> >> The ILP packet just contains the end-to-end condition (always a SHA-256 >>> hash) and then the local transfer can have a different condition that i= s >>> derived from the condition in the ILP packet. >> >> >> Fair enough; in your case you can transmit the condition twice and verif= y >> the structure of the complex local condition, and in the >> no-condition-in-ILP version you can verify the structure of the local >> condition and extract the SHA256 condition to pass on. >> >> I think the expiry should always be the expiry set by the sender. It >>> won't be changed. >> >> >> That increases connector risk enormously, allowing anybody to cause a >> connector to lose money by submitting a fulfillment at the last moment. >> > > Not at all. You're assuming that there is no expiry on the local transfer= . > As a receiving node I have an incoming transfer with an expiry and it > carries an ILP packet that also has an expiry. > > My routing logic should look at both and decide a) if this is safe to > route on (i.e. put some of my own capital at risk) and b) what expiry to > set on the next hop. > > There is no incentive to change the expiry in the packet as this can only > be targeted at upstream connectors and the result will simply be that the > payment is declined and the upstream local transfer rolls back. > > >> If an attacker knows enough about latency in the chain, they could even >> target this attack at somebody many hops away. Staggering expiries (givi= ng >> you a minimum amount of time to fulfill a source transfer) is an easy >> mitigation against this attack; we shouldn't take it out. >> > > I agree. We would still have the local expiry. > > >> >> Comparing the condition in the local transfer and the one in the ILP >>> packet should be part of the routing logic. >> >> >> Sure, it can be done as an extra validity check, but it's just more code >> and more attack surface. I still don't see any tangible benefit from >> doing the layering in this way, aside from your assertion that it's the >> correct way to do it. If you've read any documents that explain why this= is >> the correct way to do layering, I think I'd understand you better. >> >> >> On Thu, Aug 17, 2017 at 7:32 PM, Adrian Hope-Bailie < >> adrian@hopebailie.com> wrote: >> >>> >>> >>> On 16 August 2017 at 10:22, Ben Sharafian wrote: >>> >>>> OK, I think in that case we're mostly disagreeing over where the >>>> condition/fulfillment/expiry actually go in the data. >>>> >>> >>> That's one way to look at it but that's ultimately what the architectin= g >>> the layering is. Deciding at which layer (and therefor encapsulated in = what >>> packet) certain data should be. >>> >>> >>>> The reason I don't agree with your position is based on which parties = I >>>> think should be aware of ILP. >>>> >>> >>> I don't think that's the right way to look at it. The connector needs t= o >>> be able to understand at least the ILP layer data AND the lower layer d= ata. >>> Normally the way the processing stack is implemented is that there is a >>> module for each layer that processes the data from that layer and then >>> passes the payload and any other important information up to the next l= ayer. >>> >>> >>>> In order to track the balance between each other accurately, the two >>>> connectors have to keep track of conditions, fulfillments, and expirie= s on >>>> each of the transfers. >>>> >>> >>> This is where I disagree with you. Two connectors exchanging a transfer >>> only care about the data that is relevant to them for that transfer. It= 's >>> quite possible for two connectors to perform a transfer that has no >>> conditions or fulfillments or a transfer that has a different condition= and >>> fulfillment (such as an atomic mode transfer where the condition is a >>> compound one that has multiple sub-conditions). >>> >>> >>>> That means the connectors' accounting logic that handles the >>>> conditions, fulfillments, and expiries is going to be using some >>>> information inside the ILP packet and some information outside of it i= n >>>> order to perform these transfers. >>>> >>> >>> It will only use info inside the packet if it uses conditional transfer= s >>> that use that same condition. This is the most likely scenario but that= is >>> not a protocol requirement. >>> >>> >>>> >>>> I think it's cleaner to say everything required to make these local >>>> transfers should go in one protocol, so the accounting logic of these >>>> connectors doesn't have to deal with ILP directly. >>>> >>> >>> I strongly disagree with that. That's entirely the wrong reason to put >>> data into a specific layer. The data in the ILP layer is there because = it's >>> "end-to-end" data. >>> >>> If a protocol at a lower layer wants to use that data then it must >>> replicate it. That seems inefficient but it's the correct way to do it. >>> >>> One could define a lower layer protocol that doesn't replicate the data >>> but the rules of the protocol are "Get the condition from the ILP packe= t". >>> In that case, that specific lower level protocol is forcing implementat= ions >>> to understand the ILP packet format, that's an implementation detail. >>> >>> Another lower layer protocol might take the condition from the ILP >>> packet and re-encode it in a different form (like a base64ulr string or= NI: >>> uri) >>> >>> >>>> Then the connectors' ILP-packet-related behavior can all be routing >>>> related. >>>> >>> >>> Routing requires looking at the condition, expiry and amount. A >>> connector's routing logic shouldn't forward a packet if the expiry is t= oo >>> low or if the condition is obviously corrupted. >>> >>> If the protocols were designed correctly as I am proposing then another >>> routing decision would be, is the condition that was used in the incomi= ng >>> transfer the same as the one used in the ILP packet? >>> >>> >>> >>>> This would add a few benefits; two connectors could perform non-ILP >>>> conditional transfers between one another (which would be useful for >>>> reconciliation and settlement), and could also allow two connectors to= use >>>> more complex condition types (i.e. signatures for atomic mode) without >>>> forcing us to support that in the ILP packet. >>>> >>> >>> You seem to have this backwards. Both of these things are supported if >>> the condition and expiry ARE in the ILP packet. Atomic mode is not >>> supported in the ILP protocol it is supported in the lower layer transf= er >>> protocol. The ILP packet just contains the end-to-end condition (always= a >>> SHA-256 hash) and then the local transfer can have a different conditio= n >>> that is derived from the condition in the ILP packet. >>> >>> >>>> It also keeps the integrity of the ILP packet as something lower level= s >>>> don't modify; the connector has to modify the expiry in order to pass = along >>>> an ILP payment (they may not modify the expiry if they're using someth= ing >>>> like atomic mode, but then we have the issue with advanced condition t= ypes >>>> not being supported in the ILP packet). >>>> >>> >>> I think the expiry should always be the expiry set by the sender. It >>> won't be changed. >>> >>>> >>>> In the case where the ledger _does_ care about the condition and >>>> fulfillment, the argument in favor of separating >>>> condition/fulfillment/expiry from the rest of the packet is similar. >>>> Because we don't control the features of all ledgers, we'll need our >>>> plugins or ledger adapters to be aware of ILP. This makes it hard to >>>> interact with any events that don't involve ILP packets, and impossibl= e to >>>> handle features that extend beyond what we support in the ILP packet. = We >>>> could pass details about non-ILP ledger features (like a crypto condit= ion) >>>> in the side data, but in the event of any redundancy we have to check = the >>>> ledger-supplied info, not the info in the ILP packet. >>>> >>> >>> Comparing the condition in the local transfer and the one in the ILP >>> packet should be part of the routing logic. >>> >>> >>>> >>>> Basically, condition/fulfillment/expiry are used for accounting local >>>> transfers (even if they aren't being "ledger" enforced) in addition to >>>> their role as every-hop information. By putting them in the ILP packet= , we >>>> limit the special features that ledgers can support and make our softw= are >>>> abstractions harder to separate cleanly. By putting them in the local >>>> transfer alongside the ILP packet but not inside it, we do separate th= e >>>> data a little more, but we have more freedom in what the underlying >>>> accounting and ledger logic can do, and our software modules will have= more >>>> clearly separated domains. >>>> >>> >>> They should be in both the local transfer AND the ILP packet if they ar= e >>> needed by the local transfer protocol. This allows the flexibility you >>> desire because the local transfer protocol can do ANYTHING including us= ing >>> the condition from the ILP packet as-is, not at all or enhanced for >>> something like atomic mode. >>> >>> >>> >>>> >>>> On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie < >>>> adrian@hopebailie.com> wrote: >>>> >>>>> Exactly =F0=9F=91=8D >>>>> >>>>> On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian >>>>> wrote: >>>>> >>>>>> Ok, I think I have a better idea of what you're saying. >>>>>> >>>>>> It sounds like you're saying the ILP layer contains all information >>>>>> that is common between every hop (destination, destination amount, o= paque >>>>>> data, condition, fulfillment, expiry). The lower level would then be= used >>>>>> for all the transfer-local details (source amount, next connector ac= count, >>>>>> custom/local data). >>>>>> >>>>>> If the lower level wanted to do anything related to the every-hop >>>>>> payment, i.e. escrow funds until the receipt has been produced, it w= ould >>>>>> look into the ILP layer for that information. If the lower level did= n't do >>>>>> any escrow or expiries that require every-hop details, it would simp= ly >>>>>> function as a communication method. >>>>>> >>>>>> Is that right? >>>>>> >>>>>> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >>>>>> adrian@hopebailie.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 15 August 2017 at 16:00, Ben Sharafian >>>>>>> wrote: >>>>>>> >>>>>>>> In that case, the plugin or whatever is doing the accounting is th= e >>>>>>>>>>> ledger. Digital value is always tracked in ledgers, so I think = it does make >>>>>>>>>>> sense to think of this as the base layer. The reason to abstrac= t the >>>>>>>>>>> functionality you expect from the ledger layer is precisely so = you can >>>>>>>>>>> handle it in different ways, depending on what the underlying s= ystems >>>>>>>>>>> provide. >>>>>>>>>> >>>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>>> >>>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities >>>>>>>>>> and some type of HTLA >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. There are separate plugins for messaging and for transfers >>>>>>>>>> and when you peer with someone you have to agree on a plugin = for each >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. We standardize the messaging part and say that all goes >>>>>>>>>> over IP and then just have more minimal plugins for the on-le= dger >>>>>>>>>> settlements >>>>>>>>>> >>>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>>> sense. >>>>>>>>> >>>>>>>>> >>>>>>>> I think you're confusing implementation details and defining of >>>>>>>>> interfaces with definition of a protocol stack. The only differen= ces >>>>>>>>> between the tree examples you have above is in implementation. >>>>>>>> >>>>>>>> >>>>>>>> I had to scroll up after reading this to make sure it was @adrian >>>>>>>> talking, because that seems like the opposite of what you were arg= uing for. >>>>>>>> >>>>>>> >>>>>>> I don't think so. But I think that is part of the problem. We are >>>>>>> not all focused on the same thing. I am actually not very intereste= d in CLP >>>>>>> at all. It is one of potentially many protocols that may exist belo= w the >>>>>>> ILP layer. All we're doing by defining CLP is bootstrapping the net= work by >>>>>>> defining a protocol for everyone to use to get started. >>>>>>> >>>>>>> In designing the ILP layer properly we should try and forget >>>>>>> everything we know about the lower layers other than what features = we >>>>>>> require of them. >>>>>>> >>>>>>> There is a misconception that ILP requires the lower layers to >>>>>>> support conditional transfers, that is not true. >>>>>>> >>>>>>> All we actually need from a lower layer protocol is to transfer dat= a >>>>>>> back and forth and provide a way to reliably map requests to respon= ses. >>>>>>> >>>>>>> What ILP provides lower layers is a way to reward your peer for >>>>>>> passing on the packet. The Internetworking layer defines a conditio= n, a >>>>>>> reward that must be paid to the receiver for the fulfillment and th= e time >>>>>>> allowed to claim this reward. >>>>>>> >>>>>>> Because of this, within lower-layer protocols that offer the basic >>>>>>> request/response features we need, we could add conditional payment >>>>>>> semantics that use the condition, expiry and fulfillment provided b= y ILP. >>>>>>> This would allow a node to offer a reward to their next peer to fo= r >>>>>>> delivering the packet they send them and to make the local financia= l >>>>>>> transaction contingent on the end-to-end transaction. >>>>>>> >>>>>>> But crucially, adding that semantic to the lower layer protocol >>>>>>> provides nothing extra to the ILP layer. The value is purely derive= d from >>>>>>> the two peers who use that protocol and can now use conditional pay= ments to >>>>>>> protect themselves from their peers. >>>>>>> >>>>>>> >>>>>>>> The proposal that you're arguing for is basically asserting that >>>>>>>> we're going to be using CLP, because it makes the assumption that = the >>>>>>>> connectors (who understand ILP) are managing the HTLA logic. >>>>>>>> >>>>>>> >>>>>>> Not at all. I am asserting that it doesn't matter what protocol you >>>>>>> use below the ILP layer because it shouldn't matter. All of this ta= lk about >>>>>>> ILP being different because money is more important than data is no= nsense. >>>>>>> >>>>>>> The difference between ILP and IP that makes ILP suitable for value >>>>>>> transfer and IP not is at the internetworking layer. ILP requires t= hat all >>>>>>> packets are either a request or response and that the responses fol= low the >>>>>>> same path as the requests. Further ILP defines a signature scheme t= hat >>>>>>> gives the sender a way to be certain the request was received by th= e >>>>>>> receiver. >>>>>>> >>>>>>> *This could be done entirely without money* but then there would be >>>>>>> little incentive to sign the receipt or deliver the signature back = to the >>>>>>> original sender. >>>>>>> >>>>>>> So, if you add money then you add economic incentives to the mix. A= t >>>>>>> each hop the sender promises the next upstream peer a payment if th= ey can >>>>>>> return the receipt. The net effect is that this can be used to tran= sfer >>>>>>> money from the sender to the receiver by simply defining up front t= he >>>>>>> amount that the receiver must get to produce the signature. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> In the current model, the CLP/trustline model and the direct ledge= r >>>>>>>> model both work without having to treat anything on the ILP layer >>>>>>>> differently. We're favoring on-ledger messaging because of our >>>>>>>> implementation, yes, but we've been able to switch most all of our= plugins >>>>>>>> from on-ledger messaging to RPC-based messaging without changing t= he ILP >>>>>>>> layer at all. >>>>>>>> >>>>>>>> With the ledger-level abstraction, we were able to switch from our >>>>>>>> ledger-based mode of thinking to the CLP/trustline based way witho= ut >>>>>>>> changing anything other than the plugin. Your argument comes from = an >>>>>>>> assumption of a CLP-style ledger protocol with some underlying led= ger, >>>>>>>> which we can't assume is always the case. >>>>>>>> >>>>>>> >>>>>>> I'm not sure what any of that proves tbh. These are all >>>>>>> implementation concerns. They don't change the fact that the condit= ion, >>>>>>> expiry and fulfillment are part of ILP not the lower layer protocol= s. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> From the perspective of the Interledger Protocol the implementatio= n >>>>>>>>> of the lower layers is not important, that's the whole point of l= ayering. >>>>>>>>> By forcing important aspects of ILP like the condition, fulfillme= nt and >>>>>>>>> expiry down into those layers you muddy the waters and we now hav= e to >>>>>>>>> standardize those protocols too. Instead we should just be defini= ng the >>>>>>>>> functions they must provide and then leave it up to implementatio= ns to >>>>>>>>> provide those functions. >>>>>>>> >>>>>>>> >>>>>>>> I don't agree with this point; the condition and fulfillment have >>>>>>>> actual meaning to the ledger layer. >>>>>>>> >>>>>>> >>>>>>> NO THEY DON'T! They have meaning to SOME ledgers that implement SOM= E >>>>>>> lower layer protocols, IF they choose to use them. >>>>>>> >>>>>>> Excuse the shouting but this is the crux of the issue. We need to >>>>>>> all agree that it is entirely possible for a transfer to be done th= at >>>>>>> doesn't use the condition and fulfillment and that if this was in t= he >>>>>>> middle of a 10-hop ILP payment it would have no effect on the sende= r and >>>>>>> receiver. >>>>>>> >>>>>>>> >>>>>>>> You've said that the ledger often doesn't care about fulfillment >>>>>>>> and condition, but the ledger _layer_'s (where transfers are done)= role is >>>>>>>> to take in condition and fulfillment and make a transfer which sat= isfies >>>>>>>> its HTLA. >>>>>>>> >>>>>>> >>>>>>> No, the ledger's role is to keep a tab of net financial positions >>>>>>> between two peers. It MAY use conditions and fulfillments that it p= ulls >>>>>>> from the ILP layer to help it do that in a way both peers agree on. >>>>>>> >>>>>>> Note that a "layer" doesn't have a role. I think there is some >>>>>>> confusion about the difference between layering the protocol and >>>>>>> abstracting functionality into different components. >>>>>>> >>>>>>> >>>>>>>> If the ledger layer has to look into the ILP packet to do so, that >>>>>>>> is a blatant breaking of layering. >>>>>>>> >>>>>>> >>>>>>> Not at all! The module acting at the layers *below* the >>>>>>> internetworking layer shouldn't modify anything inside the packets = of the >>>>>>> higher layers but they can definitely inspect them and adjust their >>>>>>> behavior based on what they to find. >>>>>>> >>>>>>> In fact the prevalence of this is the subject of a lot of debate at >>>>>>> the IETF currently because endpoints are often encrypting their pay= loads >>>>>>> and in some cases this makes it difficult for middle-boxes to be ef= fective >>>>>>> at their jobs. >>>>>>> >>>>>>> By putting the condition, fulfillment, and expiry on the ledger >>>>>>>> layer, we leave it open for any ledger type to work, rather than f= orcing >>>>>>>> all ledger-layer software to understand ILP. >>>>>>>> >>>>>>> >>>>>>> Actually you do the opposite. You make it a requirement of every >>>>>>> protocol below the ILP layer to define a way to carry these data el= ements >>>>>>> and encode and decode them, even if they don't use them >>>>>>> >>>>>>> Ledger layer components don't have to understand ILP unless they >>>>>>> choose to re-use the condition for their own local transfer. Ledger= s >>>>>>> themselves *never* have to understand ILP. >>>>>>> >>>>>>> Remember a ledger layer protocol could use a completely different >>>>>>> conditional payments scheme, like atomic mode ILP, where it takes t= he >>>>>>> end-to-end condition and creates a new compound condition that depe= nds on >>>>>>> the fulfillment and some notary signature. >>>>>>> >>>>>>> There will be a component in a connector's stack that must pass the >>>>>>> ILP packet to the next peer. If it does this using a transfer proto= col that >>>>>>> uses conditional transfers and wants to use the same condition as t= he ILP >>>>>>> packet then it must decode the packet. >>>>>>> >>>>>>> But, it will likely do something with that condition before sending >>>>>>> the transfer to the ledger like encoding it differently or rehashin= g it >>>>>>> (lightning?) so that it's in the form expected by the ledger. >>>>>>> >>>>>>> That's an implementation decision of the lower layer protocol used >>>>>>> between those two peers. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I agree that Interledger defines how conditions, fulfillments, and >>>>>>>> expiries should be chained together, but it makes no assertions ab= out their >>>>>>>> data format. >>>>>>>> >>>>>>> >>>>>>> ILP doesn't define how anything is chained together. From the >>>>>>> perspective of ILP the condition and fulfillment are end-to-end dat= a. They >>>>>>> are agreed by the two endpoints who don't care how they get from Al= ice to >>>>>>> Bob and back. >>>>>>> >>>>>>> The design of ILP is such that it facilitates the design of lower >>>>>>> level protocols that can be used to carry the ILP packets across mu= ltiple >>>>>>> hops (networks) using economic incentives such that the sender pays= enough >>>>>>> for the first hop to ensure that all nodes in between can extract t= he fee >>>>>>> they want and the receiver will still get the amount they expected.= . >>>>>>> >>>>>>> >>>>>>> >>>>>>>> ILP says you should send your outgoing transfer with the same >>>>>>>> condition as the incoming one, and a lower expiry. >>>>>>>> >>>>>>> >>>>>>> No it doesn't. An internetworking protocol can't prescribe that kin= d >>>>>>> of thing to lower level protocols. An incoming and outgoing transfe= r could >>>>>>> be sent using completely different protocols and the financial agre= ement >>>>>>> with the peers on those two routes could be vastly different too. >>>>>>> >>>>>>> The only service ILP requires of lower level protocols is that they >>>>>>> can map a response to an original request. This requirement is okay= because >>>>>>> it is isolated to a single route/link at a time not a requirement t= hat >>>>>>> crosses the inter-network boundary that ILP crosses. >>>>>>> >>>>>>> >>>>>>>> But because ILP allows for many different types of ledgers, it >>>>>>>> doesn't make sense to assert how these are encoded. >>>>>>>> >>>>>>> >>>>>>> By putting them in the ILP packet you do the opposite. You make no >>>>>>> assertions about how they are encoded if they are used at lower lay= ers, or >>>>>>> how they may be combined with other conditions or even used to deri= ve new >>>>>>> conditions. >>>>>>> >>>>>>>> >>>>>>>> IP doesn't tell you how to encode an ethernet packet. It doesn't >>>>>>>> even know whether it's going over a computer or a hand-written let= ter >>>>>>>> carried by a pigeon. IP takes for granted that you can send data o= ver one >>>>>>>> connection by putting it in a lower level. >>>>>>>> >>>>>>> >>>>>>> Correct, but if a link layer protocol wanted to look into the IP >>>>>>> packet headers of a packet it wants to transfer and use some data f= rom >>>>>>> there in its internal logic (or even reuse data in it's own frame) = that >>>>>>> would be totally fine. >>>>>>> >>>>>>> >>>>>>>> Even though IP tells you how to chain these connections together, >>>>>>>> it doesn't have to put the things it's chaining on the internetwor= king >>>>>>>> level. >>>>>>>> >>>>>>> >>>>>>> IP doesn't tell you how to chain things together. IP simply defines >>>>>>> the end-to end data envelope and address space. Because of this nod= es that >>>>>>> implement the multiple lower layer protocols are able to push IP pa= ckets >>>>>>> down a link and expect the node on the other side to understand the= headers >>>>>>> and route it onward on another link. >>>>>>> >>>>>>> Everything needed by the IP module to decide what to do with the >>>>>>> packet is in the IP packet headers. i.e. Has it exceeded a TTL? Is = there a >>>>>>> route for this destination? Is it corrupted (checksum fails)? But a= lso, >>>>>>> everything that is needed by the endpoint (like the source address)= is also >>>>>>> in there. >>>>>>> >>>>>>> There is no dependency on nodes to be good citizens and always pass >>>>>>> certain other data from the lower layers into the next link. That w= ould be >>>>>>> breaking the layering. >>>>>>> >>>>>>> >>>>>>>> IP also assumes that if you get some incoming data on a connection >>>>>>>> you can copy it and send it out on the next connection. Because yo= u can >>>>>>>> already send data over a connection, all IP adds is the missing pi= ece: a >>>>>>>> packet that tells you where to go. >>>>>>>> >>>>>>>> With ILP, we assume that there is a way to prepare a conditional >>>>>>>> transfer, expire a conditional transfer, and fulfill a conditional >>>>>>>> transfer. >>>>>>>> >>>>>>> >>>>>>> No we don't! We assume that if we deliver the packet as intended >>>>>>> we'll get back a response packet with a signature that matches the >>>>>>> condition in the packet. So, if we have an agreement with someone t= hat they >>>>>>> will pay us when we present that signature then we are prepared to = enter a >>>>>>> similar agreement with the next peer because we expect that signatu= re to >>>>>>> come all the way back along the interledger layer route.. >>>>>>> >>>>>>> >>>>>>>> We also assume that if you get an incoming transfer you can create >>>>>>>> an outgoing transfer with the same condition. The abstraction we m= ade means >>>>>>>> that conditions and fulfillments are already carried in the lower = levels. >>>>>>>> >>>>>>> >>>>>>> That is a bad assumption that comes from the broken layering. What >>>>>>> if my outgoing link doesn't support conditional transfers? So now w= here do >>>>>>> I put the condition? >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We could have assumed that no ledgers ever support conditional >>>>>>>> transfers, and said the only thing ILP gets from lower levels is t= he >>>>>>>> ability to send a transfer. But if we want to support the case whe= re any of >>>>>>>> them do, we have to keep the conditions and fulfillments in the la= yer where >>>>>>>> they're actually used. >>>>>>>> >>>>>>> >>>>>>> I don't follow that logic at all. If we want to support the case >>>>>>> where any of them do then we must ensure the condition and expiry a= re >>>>>>> always carried in a consistent place at the internetworking layer s= o that >>>>>>> if they do want to use them they know where to find them. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>>>>>> adrian@hopebailie.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 14 August 2017 at 22:03, Evan Schwartz wrote= : >>>>>>>>> >>>>>>>>>> I think this thread is going to get extremely unwieldy but here >>>>>>>>>> goes: >>>>>>>>>> >>>>>>>>>> > - All interledger layer messages should be ILP packets >>>>>>>>>> (including fulfillments) and be capable of carrying higher layer= protocol >>>>>>>>>> payloads. >>>>>>>>>> >>>>>>>>>> Interledger has higher requirements than ILP for the lowest >>>>>>>>>> layer, specifically because we are carrying money and not just d= ata. One of >>>>>>>>>> the requirements is being able to transmit a 32-byte fulfillment= back along >>>>>>>>>> the same path that carried the payment originally. If we expect = this of the >>>>>>>>>> lower layer, I don't see a point in putting the fulfillment into= an ILP >>>>>>>>>> packet and transmitting it as Interledger data along the same pa= th. All >>>>>>>>>> ledger-layer protocols will need to interpret the fulfillment pa= ssed in >>>>>>>>>> their protocol, not the one passed through the Interledger layer= . >>>>>>>>>> >>>>>>>>> >>>>>>>>> This is not correct. There is no requirement on ledger layer >>>>>>>>> protocols to transmit or understand the fulfillment. You are look= ing at >>>>>>>>> this through the lens of existing implementations from the bottom= up >>>>>>>>> instead of starting at the interledger layer. >>>>>>>>> >>>>>>>>> The primary function of the condition and fulfillment is as a >>>>>>>>> signed end-to-end receipt. If the sender agrees a condition with = a receiver >>>>>>>>> and then gets back the valid fulfillment they don't care what hap= pened in >>>>>>>>> the middle. The receiver has signed a receipt saying they have th= eir money. >>>>>>>>> >>>>>>>>> The value of using a standard for the receipt and signature is >>>>>>>>> that each transfer along the way CAN re-use it. One the one hand = you can >>>>>>>>> have a transfer between two peers that have zero trust and the le= dger they >>>>>>>>> use supports conditional payments completely. On the other extrem= e you can >>>>>>>>> have two peers that have a full trust and ignore the condition an= d >>>>>>>>> fulfillment completely. >>>>>>>>> >>>>>>>>> The ledger layer protocols carry ILP packets. Payment requests an= d >>>>>>>>> either fulfillment or error responses. If a ledger layer protocol= wants to >>>>>>>>> use the condition and fulfillment for their own operations they c= an extract >>>>>>>>> these from the ILP packets and use them. >>>>>>>>> >>>>>>>>> >>>>>>>>>> > - While it may make sense to split the interledger payment and >>>>>>>>>> interledger quoting protocols into new higher level protocols th= at seems >>>>>>>>>> like an unnecessary abstraction. Instead the packet definitions = should just >>>>>>>>>> have some consistency and probably a common base/header. >>>>>>>>>> >>>>>>>>>> The current protocols effectively have this header but it isn't >>>>>>>>>> separated out. There are two fields in the request header: type = and >>>>>>>>>> destination address. There is one field in the response header: = type. I >>>>>>>>>> don't think it makes that much of a big difference to separate t= hese fields >>>>>>>>>> if all of the fields in that packet need to be interpreted toget= her (for >>>>>>>>>> example, you can't understand a quote request if you strip off t= he >>>>>>>>>> destination address). >>>>>>>>>> >>>>>>>>> >>>>>>>>> I agree that we don't HAVE to explicitly separate them out but I >>>>>>>>> think ti would make it clearer how the stack is architected if th= ere was a >>>>>>>>> header that was consistent across all packets. Currently the only= thing >>>>>>>>> that is consitent across all ILP packets is that they are defined= int he >>>>>>>>> same file. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > - We should define two base ILP packet types: request and >>>>>>>>>> response. >>>>>>>>>> >>>>>>>>>> Unless this adds some substantive benefit or new fields I don't >>>>>>>>>> think it's worth breaking all of the formats we have just to rea= rrange >>>>>>>>>> things. >>>>>>>>>> >>>>>>>>> >>>>>>>>> The goal of this exercise is to tease out the best design and >>>>>>>>> ignore the cost of change until we can compare the results with t= he current >>>>>>>>> design. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>>>>>> nodes/hosts. >>>>>>>>>> >>>>>>>>>> A ledger is any system that tracks accounts and balances. When >>>>>>>>>> you use a trustline all of your messages still need to go throug= h an >>>>>>>>>> accounting system (such as the plugin in the JS implementation) = and then on >>>>>>>>>> to the other program logic. >>>>>>>>>> >>>>>>>>> >>>>>>>>> As above, this is incorrect. There is no requirement for "all >>>>>>>>> messages to go through an accounting system". >>>>>>>>> >>>>>>>>> Since designing the first implementation of 5-bells ledger we hav= e >>>>>>>>> assumed that passing the ILP packet MUST be done by the ledger be= cause that >>>>>>>>> is how we implemented it. But that is not true. It is perfectly v= alid for >>>>>>>>> the passing of an ILP packet from one peer to another to be simpl= y an >>>>>>>>> exchange of data. >>>>>>>>> >>>>>>>>> The receiving peer makes a decision about whether or not to >>>>>>>>> forward the packet based on the current financial position they h= ave with >>>>>>>>> the sending peer. >>>>>>>>> >>>>>>>>> It is convenient if the ledger that records the net positions of >>>>>>>>> the peers also forwards the messaging and even better if it nativ= ely >>>>>>>>> supports conditional payments and can use the condition and the f= ulfillment >>>>>>>>> from the ILP packet for those but that's all it is, convenient. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> In that case, the plugin or whatever is doing the accounting is >>>>>>>>>> the ledger. Digital value is always tracked in ledgers, so I thi= nk it does >>>>>>>>>> make sense to think of this as the base layer. The reason to abs= tract the >>>>>>>>>> functionality you expect from the ledger layer is precisely so y= ou can >>>>>>>>>> handle it in different ways, depending on what the underlying sy= stems >>>>>>>>>> provide. >>>>>>>>>> >>>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>>> >>>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities >>>>>>>>>> and some type of HTLA >>>>>>>>>> >>>>>>>>>> 2. There are separate plugins for messaging and for transfers >>>>>>>>>> and when you peer with someone you have to agree on a plugin = for each >>>>>>>>>> 3. We standardize the messaging part and say that all goes >>>>>>>>>> over IP and then just have more minimal plugins for the on-le= dger >>>>>>>>>> settlements >>>>>>>>>> >>>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>>> sense. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think you're confusing implementation details and defining of >>>>>>>>> interfaces with definition of a protocol stack. The only differen= ces >>>>>>>>> between the tree examples you have above is in implementation. >>>>>>>>> >>>>>>>>> From the perspective of the Interledger Protocol the >>>>>>>>> implementation of the lower layers is not important, that's the w= hole point >>>>>>>>> of layering. By forcing important aspects of ILP like the conditi= on, >>>>>>>>> fulfillment and expiry down into those layers you muddy the water= s and we >>>>>>>>> now have to standardize those protocols too. Instead we should ju= st be >>>>>>>>> defining the functions they must provide and then leave it up to >>>>>>>>> implementations to provide those functions. >>>>>>>>> >>>>>>>>> I know we want to define a standard to bootstrap the system (CLP) >>>>>>>>> but that's misleading us into thinking it's an essential part of = the stack. >>>>>>>>> It's perfectly valid for two peers to not use CLP and still be pa= rt of the >>>>>>>>> Interledger. >>>>>>>>> >>>>>>>>> That said, you raise an interesting consideration about the layer= s >>>>>>>>> below ILP and actually I think it makes sense to split these. >>>>>>>>> >>>>>>>>> We keep trying to force messaging through the ledger layer and >>>>>>>>> actually that's the wrong place to put it if we can split the led= ger layer >>>>>>>>> into a messaging layer and a ledger layer. That way we can stop t= rying to >>>>>>>>> think of all HLTAs as ledgers. >>>>>>>>> >>>>>>>>> A thought, why not use sub-layers as is common in other stacks: >>>>>>>>> >>>>>>>>> 1. Link layer: Layer upon which two peers that have a direct link= , >>>>>>>>> or participate in the same payment network, communicate >>>>>>>>> 2. Transfer/ ledger: Layer on which financial positions between >>>>>>>>> two peers are recorded >>>>>>>>> >>>>>>>>> This reflects the already emerging HTLA model and many of our >>>>>>>>> existing plugins and ledger integrations. >>>>>>>>> Link Layer: XRP Paychan, Lightning >>>>>>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>>>>>> >>>>>>>>> This doesn't prevent us from defining a standard binary protocol >>>>>>>>> that defines all of the operations for both layers (like CLP) but= I see >>>>>>>>> value in distinguishing between these two. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > - The protocol should differentiate between the operation of >>>>>>>>>> preparing a transfer on a ledger and the operation of passing an= ILP packet >>>>>>>>>> from one peer to another. >>>>>>>>>> >>>>>>>>>> The protocol assumes your conditional transfer is underpinned by >>>>>>>>>> some HTLA >>>>>>>>>> . >>>>>>>>>> It doesn't care whether that's on-ledger or not. >>>>>>>>>> >>>>>>>>> >>>>>>>>> What do you mean when you say "the protocol"? In my statement I a= m >>>>>>>>> referring to ILP. >>>>>>>>> My point above being that ILP expects ILP packets to be passed >>>>>>>>> from peer to peer but has no expectations about transfers. >>>>>>>>> >>>>>>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>>>>>> exchange ILP packets with no transfers. Clearly if a node routes = a packet >>>>>>>>> on and has no incoming transfer it's going to lose money but that= 's a >>>>>>>>> consideration for that node. It doesn't affect anyone else in the= chain. >>>>>>>>> >>>>>>>>> ILP doesn't assume anything about transfers at all, let alone >>>>>>>>> conditional transfers. It provides useful semantics for condition= al >>>>>>>>> transfers to be used by two peers to transact as part of a larger= ILP >>>>>>>>> payment. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> > - The condition and timeout should be included in the ILP >>>>>>>>>> payment packet. >>>>>>>>>> >>>>>>>>>> I strongly disagree with this. We had this debate a year ago and >>>>>>>>>> I was on your side but was convinced that this is not a good ide= a. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, I recall this and I'm sorry I didn't push harder on this >>>>>>>>> point. Unfortunately I think the decision to pull it out of the p= acket is >>>>>>>>> mostly driven by how our prototypes were implemented rather than = good >>>>>>>>> architecture. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The layer below ILP must be capable of doing conditional >>>>>>>>>> transfers based on sha256 hashlocks with 32-byte preimages. >>>>>>>>>> >>>>>>>>> >>>>>>>>> This is not true and I think it would be useful for us to agree o= n >>>>>>>>> this as this seems to be the argument I am coming up against most= often. >>>>>>>>> The peers participating in a transfer that is part of an ILP paym= ent may >>>>>>>>> wish to use conditional transfers as a way to enforce their agree= ment but >>>>>>>>> this is not a requirement of the protocol. >>>>>>>>> >>>>>>>>> The agreement between any two peers is: "I will pay you X if you >>>>>>>>> can provide a receipt that Y was paid Z before T". >>>>>>>>> ILP provides a standard for expressing this agreement so that >>>>>>>>> these can be chained together BUT it is not a requirement that ev= ery >>>>>>>>> agreement in the chain uses the condition, and fulfillment provid= ed at the >>>>>>>>> ILP layer. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> As a result, the original condition and the corresponding >>>>>>>>>> preimage MUST be expressed in that layer. >>>>>>>>>> >>>>>>>>> >>>>>>>>> As I have shown above, this is not true. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Then the question is whether we should also include it in the >>>>>>>>>> packet that is forwarded. What ultimately convinced me is the fo= llowing: >>>>>>>>>> All connectors MUST ignore the condition if it is in the packet,= because >>>>>>>>>> they are only guaranteed their money back if they use the same c= ondition >>>>>>>>>> from the incoming transfer they got. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Here is where the layering is being corrupted. >>>>>>>>> >>>>>>>>> All connectors MUST inspect the condition in the ILP packet as >>>>>>>>> part of their decision to route the packet or not. >>>>>>>>> When the local transfer module of the connectors stack passes the >>>>>>>>> ILP packet up to the ILP module it should indicate the properties= of the >>>>>>>>> incoming transfer that carried the packet. >>>>>>>>> This is essential firstly so that the routing logic in the ILP >>>>>>>>> module can record the incoming transfer identifier so it is able = to use the >>>>>>>>> correct response id when it passes back the fulfillment or error. >>>>>>>>> The other properties that the ILP module should look at are the >>>>>>>>> condition and expiry on the incoming transfer. >>>>>>>>> >>>>>>>>> If the incoming route uses conditional transfers and these are >>>>>>>>> supposed to match the condition and expiry in the ILP packet then= the ILP >>>>>>>>> module should compare them and reject the packet if: >>>>>>>>> a) the conditions don't match OR >>>>>>>>> b) the expiry is too short >>>>>>>>> >>>>>>>>> We should still discuss if the expiry should be set by the sender >>>>>>>>> and left unchanged or used like a TTL and decremented by each nod= e. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Also, the receiver will need to take out the condition in order >>>>>>>>>> to hash the packet for PSK or IPR. >>>>>>>>>> >>>>>>>>> >>>>>>>>> This is completely normal. Zeroing a checksum field in a header >>>>>>>>> before calculating the checksum is VERY common precisely because = it's long >>>>>>>>> been accepted that the right place to put that data is in the hea= ders and >>>>>>>>> the work of zero'ing it out to calculate the checksum (or signatu= re in our >>>>>>>>> case) is not material. >>>>>>>>> >>>>>>>>> >>>>>>>>>> So basically, no one wants the condition in there. It feels like >>>>>>>>>> it ought to be in there, but literally none of the parties want = the extra >>>>>>>>>> 32 bytes in there. >>>>>>>>>> >>>>>>>>> >>>>>>>>> "Nobody wants it there" is a terrible reason to abandon the >>>>>>>>> correct design. The whole purpose of a good architecture is you a= ccept that >>>>>>>>> there may be cases in future that haven't been considered now so = designing >>>>>>>>> just for the known cases is a bad idea. >>>>>>>>> >>>>>>>>> Good architecture is not the same as optimization. Taking stuff >>>>>>>>> out (even when it feels wrong) to save a few bytes is a good sign= that it's >>>>>>>>> a bad idea. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> The reason the timeout should not be in there is that there isn'= t >>>>>>>>>> a single timeout for the payment. There are multiple separate ti= meouts for >>>>>>>>>> each of the bilateral transfers. Those must go in the individual= transfers >>>>>>>>>> and there is no sensible value to put in the Interledger packet. >>>>>>>>>> >>>>>>>>> >>>>>>>>> As above, this is somewhat equivalent to the TTL in an IP packet. >>>>>>>>> I'm open to discussing if it should be a fixed value set by the s= ender >>>>>>>>> where each node uses their own value but has the sender-defined v= alue as a >>>>>>>>> reference or it is actually decremented at each hop. >>>>>>>>> >>>>>>>>> Either way, this is part of ILP not the ledger layer just like th= e >>>>>>>>> condition and fulfillment. It may be used by the ledger layer but= that's >>>>>>>>> implementation specific. It belongs in the ILP packet. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> -- >>>>> Sent from a mobile device, please excuse any typos >>>>> >>>> >>>> >>> >> > --001a1148d5b28e078f055707adb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    What you're describing is an implementation of= a local transfer service that doesn't (or can't) take advantage of= Interledger. In fact, this will be the norm for most existing payment netw= orks that we want to add to the Interledger and this is where your work on = payment channels and HTLAs comes in to play.=C2=A0
    = =C2=A0

    If you have a local tran= sfer channel that doesn't support conditions natively or supports them = in a way that requires some adaption you can create an overlay network that= does what's needed. Example: Bitcoin is not a suitable network to use = for ILP so we use a payment channel between the peers that is underwritten = by Bitcoin.

    Exactly, when I say you = need a to handle the condition and fulfillment via a clearing layer, this &= quot;overlay network" is what I'm referring to. The whole point of= an HTLA is that from ILP's point of view it's just a lower-level p= rotocol that can commit conditional transfers and fulfill them. ILP doesn&#= 39;t care how the ledger/HTLA works under the hood, whether it's a clea= ring/overlay layer or a "real" ledger.

    Y= ou're equating this "overlay network," which is a type of led= ger, with the ILP layer. If there is an overlay network that handles the co= ndition and fulfillment, that means you _are_ using a ledger, because the o= verlay network _is_ a ledger. The ILP layer is a layer above this.

    If we assume the ILP packet is well defined with all = the ILP-required data elements then when a lower layer wants to use that da= ta it can but should do it in a way that doesn't break the ILP layer fo= r everyone else. How that is implemented in practice will depend on the low= er layer protocol.

    That's one wa= y to see it, but what I'm wondering is why that's a better model th= an saying there's a clearly defined interface that the ledger-layer exp= oses, and then building the ILP layer on top of that.

    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Unless the next hop is backwards

    <= div>There's no reason to send a backwards hop. If you don't want to= forward a payment you reject it.

    Not at all. Y= ou're assuming that there is no expiry on the local transfer. As a rece= iving node I have an incoming transfer with an expiry and it carries an ILP= packet that also has an expiry.

    If = that's what you're talking about, the ILP packet already has an exp= iry. It's implemented in the PSK details so the receiver knows whether = the packet it issued is still valid. But that's an application layer co= ncern, because it's only the receiver who looks at the ILP packet's= expiry. The connectors only need to know the expiries of the local transfe= rs.


    On Fri, Aug 18, 2017 at 3:21 PM, Adrian Hope-Ba= ilie <adrian@hopebailie.com> wrote:


    On 18 August 2017 at 10:38, Ben Sharafi= an <sharafian@ripple.com> wrote:
    Two connectors exchanging a transf= er only care about the data that is relevant to them for that transfer. It&= #39;s quite possible for two connectors to perform a transfer that has no c= onditions or fulfillments or a transfer that has a different condition and = fulfillment (such as an atomic mode transfer where the condition is a compo= und one that has multiple sub-conditions).

    Yes, two connectors could absolutely send an unconditional tr= ansfer on an underlying ledger in order to settle an Interledger payment. B= ut in order to benefit from any of Interledger's guarantees (trustless = connectors, retry-ability, etc.), they MUST keep a conditional local transf= er, at least for clearing. If the local transfer cannot time out, it cannot= be safely retried. If the local transfer clears without a fulfillment, it = loses the "receipt or your money back" property. Yes, two parties= in the chain could eschew these benefits but that is no longer a correct i= mplementation of Interledger.

    Aha! That is where I disagree! Interledger is not implemented at the = local transfer layer, it is implemented at the Interledger layer. The whole= point is that it an Interledger payment can travel over payment networks t= hat know nothing about ILP but the greatest value comes from using ones tha= t do.

    What you're describing is an implementation of a local tra= nsfer service that doesn't (or can't) take advantage of Interledger= . In fact, this will be the norm for most existing payment networks that we= want to add to the Interledger and this is where your work on payment chan= nels and HTLAs comes in to play.

    If you have a local transfer chann= el that doesn't support conditions natively or supports them in a way t= hat requires some adaption you can create an overlay network that does what= 's needed. Example: Bitcoin is not a suitable network to use for ILP so= we use a payment channel between the peers that is underwritten by Bitcoin= .
    =C2=A0

    If a protocol at a lower lay= er wants to use that data then it must replicate it. That seems inefficient= but it's the correct way to do it.

    <= /span>
    What's the actual reasoning behind this, and why is it consi= dered the correct approach? If there's some IETF document that says thi= s I'd like to see it, because it intuitively feels wrong to have lower = level abstractions looking into higher levels.

    The data in the ILP layer is there for a specific re= ason. It's part of an end-to-end exchange between the sender and receiv= er.

    Side note: It's unusual to be designing the whole stack a= t once so we keep being tempted to move things around but in reality we sho= uld look at the ILP layer in isolation and make sure it is complete. Altern= atively we should try to test our design against a number of lower and uppe= r layer protocols to make sure our thinking is sound.

    If we assu= me the ILP packet is well defined with all the ILP-required data elements t= hen when a lower layer wants to use that data it can but should do it in a = way that doesn't break the ILP layer for everyone else. How that is imp= lemented in practice will depend on the lower layer protocol.
    =C2=A0
    <= div>
    Routing requires looking at the condition, expiry and= amount. A connector's routing logic shouldn't forward a packet if = the expiry is too low or if the condition is obviously corrupted.

    Those are validity checks and you'= re right that they are performed in the connector, but the destination acco= unt, destination amount, and data are enough to figure out what the best ne= xt hop is.

    Unless the ne= xt hop is backwards
    =C2=A0

    The ILP Packet'= s purpose is to describe where a payment is going.

    Not only that. For comparison, an IP packet doe= s a lot more than just describe where a packet is going. All end-to-end con= cerns need to be in there too.
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    The data it carries is = only for the purpose of making sure the receiver can identify that payment.=

    No, the condition is t= here so the receiver can ensure it is sending back the correct fulfillment = and the expiry to give the receiver some assurance that the packet is still= worth processing.
    =C2=A0
    In that context, the expiry has no = bearing on where it will be routed nor on how much to route, only on whethe= r or not an individual connector will take the risk of forwarding it.
    =

    The ILP packet just contains the end-to-end co= ndition (always a SHA-256 hash) and then the local transfer can have a diff= erent condition that is derived from the condition in the ILP packet.

    Fair enough; in your case you can = transmit the condition twice and verify the structure of the complex local = condition, and in the no-condition-in-ILP version you can verify the struct= ure of the local condition and extract the SHA256 condition to pass on.

    I think the expiry = should always be the expiry set by the sender. It won't be changed.=C2= =A0

    That increases connector risk en= ormously, allowing anybody to cause a connector to lose money by submitting= a fulfillment at the last moment.

    Not at all. You're assuming that there is no ex= piry on the local transfer. As a receiving node I have an incoming transfer= with an expiry and it carries an ILP packet that also has an expiry.
    My routing logic should look at both and decide a) if this is = safe to route on (i.e. put some of my own capital at risk) and b) what expi= ry to set on the next hop.

    There is no incentive to chang= e the expiry in the packet as this can only be targeted at upstream connect= ors and the result will simply be that the payment is declined and the upst= ream local transfer rolls back.
    =C2=A0
    =
    If an attacker knows enough about late= ncy in the chain, they could even target this attack at somebody many hops = away. Staggering expiries (giving you a minimum amount of time to fulfill a= source transfer) is an easy mitigation against this attack; we shouldn'= ;t take it out.

    <= div>I agree. We would still have the local expiry.
    =C2=A0

    Comparing the condition in the local transfer and the one in the= ILP packet should be part of the routing logic.
    Sure, it can be done as an extra validity check, but it= 's just more code and more attack surface.=C2=A0I still don't see any tangible benefit from doing the layerin= g in this way, aside from your assertion that it's the correct way to d= o it. If you've read any documents that explain why this is the correct= way to do layering, I think I'd understand you better.


    On Thu, Aug 17,= 2017 at 7:32 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    On 16 August 2017 a= t 10:22, Ben Sharafian <sharafian@ripple.com> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    OK, I think in that case we're mostly disagreeing over where t= he condition/fulfillment/expiry actually go in the data.

    That's one way to look at it = but that's ultimately what the architecting the layering is. Deciding a= t which layer (and therefor encapsulated in what packet) certain data shoul= d be.
    =C2=A0
    The reason I don't agre= e with your position is based on which parties I think should be aware of I= LP.

    I don't= think that's the right way to look at it. The connector needs to be ab= le to understand at least the ILP layer data AND the lower layer data. Norm= ally the way the processing stack is implemented is that there is a module = for each layer that processes the data from that layer and then passes the = payload and any other important information up to the next layer.
    =
    =C2=A0
    = In order to track the balance betwe= en each other accurately, the two connectors have to keep track of conditio= ns, fulfillments, and expiries on each of the transfers.

    This is where I disagree with you. Two c= onnectors exchanging a transfer only care about the data that is relevant t= o them for that transfer. It's quite possible for two connectors to per= form a transfer that has no conditions or fulfillments or a transfer that h= as a different condition and fulfillment (such as an atomic mode transfer w= here the condition is a compound one that has multiple sub-conditions).
    =
    =C2=A0
    That means the connectors' accoun= ting logic that handles the conditions, fulfillments, and expiries is going= to be using some information inside the ILP packet and some information ou= tside of it in order to perform these transfers.

    It will only use info inside the packet if = it uses conditional transfers that use that same condition. This is the mos= t likely scenario but that is not a protocol requirement.
    =C2=A0

    I think i= t's cleaner to say everything required to make these local transfers sh= ould go in one protocol, so the accounting logic of these connectors doesn&= #39;t have to deal with ILP directly.
    =
    I strongly disagree with that. That's entirely th= e wrong reason to put data into a specific layer. The data in the ILP layer= is there because it's "end-to-end" data.

    I= f a protocol at a lower layer wants to use that data then it must replicate= it. That seems inefficient but it's the correct way to do it.

    <= /div>
    One could define a lower layer protocol that doesn't replicat= e the data but the rules of the protocol are "Get the condition from t= he ILP packet". In that case, that specific lower level protocol is fo= rcing implementations to understand the ILP packet format, that's an im= plementation detail.

    Another lower layer protocol might t= ake the condition from the ILP packet and re-encode it in a different form = (like a base64ulr string or NI: uri)
    =C2=A0
    Then the connectors' ILP-packet-related behavior can all be routing = related.

    Routing= requires looking at the condition, expiry and amount. A connector's ro= uting logic shouldn't forward a packet if the expiry is too low or if t= he condition is obviously corrupted.

    If the protocols wer= e designed correctly as I am proposing then another routing decision would = be, is the condition that was used in the incoming transfer the same as the= one used in the ILP packet?

    =C2=A0
    This would add a few benefits; two connectors could perform non-= ILP conditional transfers between one another (which would be useful for re= conciliation and settlement), and could also allow two connectors to use mo= re complex condition types (i.e. signatures for atomic mode) without forcin= g us to support that in the ILP packet.

    You seem to have this backwards. Both of these thin= gs are supported if the condition and expiry ARE in the ILP packet. Atomic = mode is not supported in the ILP protocol it is supported in the lower laye= r transfer protocol. The ILP packet just contains the end-to-end condition = (always a SHA-256 hash) and then the local transfer can have a different co= ndition that is derived from the condition in the ILP packet.
    =C2=A0
    It also keeps the integrity of the ILP packet a= s something lower levels don't modify; the connector has to modify the = expiry in order to pass along an ILP payment (they may not modify the expir= y if they're using something like atomic mode, but then we have the iss= ue with advanced condition types not being supported in the ILP packet).

    I think the expiry shoul= d always be the expiry set by the sender. It won't be changed.

    In the case where the ledger _does_ care about the condition an= d fulfillment, the argument in favor of separating condition/fulfillment/ex= piry from the rest of the packet is similar. Because we don't control t= he features of all ledgers, we'll need our plugins or ledger adapters t= o be aware of ILP. This makes it hard to interact with any events that don&= #39;t involve ILP packets, and impossible to handle features that extend be= yond what we support in the ILP packet. We could pass details about non-ILP= ledger features (like a crypto condition) in the side data, but in the eve= nt of any redundancy we have to check the ledger-supplied info, not the inf= o in the ILP packet.

    <= div>Comparing the condition in the local transfer and the one in the ILP pa= cket should be part of the routing logic.
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

    Basically, condition/fulf= illment/expiry are used for accounting local transfers (even if they aren&#= 39;t being "ledger" enforced) in addition to their role as every-= hop information. By putting them in the ILP packet, we limit the special fe= atures that ledgers can support and make our software abstractions harder t= o separate cleanly. By putting them in the local transfer alongside the ILP= packet but not inside it, we do separate the data a little more, but we ha= ve more freedom in what the underlying accounting and ledger logic can do, = and our software modules will have more clearly separated domains.

    They should be in both th= e local transfer AND the ILP packet if they are needed by the local transfe= r protocol. This allows the flexibility you desire because the local transf= er protocol can do ANYTHING including using the condition from the ILP pack= et as-is, not at all or enhanced for something like atomic mode.
    <= div>

    = =C2=A0

    On Tue, Aug 15, 2017 at 10:24 A= M, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
    =
    Exactly =F0=9F=91=8D<= /div>

    O= n Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian <sharafian@ripple.com> wrote:
    Ok, I think I have a better idea of w= hat you're saying.

    It sounds like you're saying = the ILP layer contains all information that is common between every hop (de= stination, destination amount, opaque data, condition, fulfillment, expiry)= . The lower level would then be used for all the transfer-local details (so= urce amount, next connector account, custom/local data).

    If the lower level wanted to do anything related to the every-hop pa= yment, i.e. escrow funds until the receipt has been produced, it would look= into the ILP layer for that information. If the lower level didn't do = any escrow or expiries that require every-hop details, it would simply func= tion as a communication method.

    Is that right?

    On Tue, A= ug 15, 2017 at 6:35 PM, Adrian Hope-Bailie <adrian@hopebailie.com> w= rote:


    On 15 August 2017 at 16:00, Ben Shara= fian <sh= arafian@ripple.com> wrote:
    In that case, the pl= ugin or whatever is doing the accounting is the ledger. Digital value is al= ways tracked in ledgers, so I think it does make sense to think of this as = the base layer. The reason to abstract the functionality you expect from th= e ledger layer is precisely so you can handle it in different ways, dependi= ng on what the underlying systems provide.
    I see 3 ways to thin= k of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messaging capabiliti= es and some type of=C2=A0HTLA
    1. There are separate plugins for messaging and for transfers and when yo= u peer with someone you have to agree on a plugin for each
      We standardize the messaging part and say that = all goes over IP and then just have more minimal plugins for the on-ledger = settlements
    Number 1 is what we have and I think that still makes = the most sense.

    I think y= ou're confusing implementation details and defining of interfaces with = definition of a protocol stack. The only differences between the tree examp= les you have above is in implementation.

    =
    I had to scroll up after reading this to make sure it was @adri= an talking, because that seems like the opposite of what you were arguing f= or.

    I don't think s= o. But I think that is part of the problem. We are not all focused on the s= ame thing. I am actually not very interested in CLP at all. It is one of po= tentially many protocols that may exist below the ILP layer. All we're = doing by defining CLP is bootstrapping the network by defining a protocol f= or everyone to use to get started.

    In designing the ILP l= ayer properly we should try and forget everything we know about the lower l= ayers other than what features we require of them.

    There = is a misconception that ILP requires the lower layers to support conditiona= l transfers, that is not true.

    All we actually need from = a lower layer protocol is to transfer data back and forth and provide a way= to reliably map requests to responses.

    What ILP provides= lower layers is a way to reward your peer for passing on the packet. The I= nternetworking layer defines a condition, a reward that must be paid to the= receiver for the fulfillment and the time allowed to claim this reward.

    Because of this, within lower-layer protocols th= at offer the basic request/response features we need, we could add conditio= nal payment semantics that use the condition, expiry and fulfillment provid= ed by ILP. This would allow a node to offer a reward to=C2=A0 their next pe= er to for delivering the packet they send them and to make the local financ= ial transaction contingent on the end-to-end transaction.

    But crucially, adding that semantic to the lower layer protocol provides n= othing extra to the ILP layer. The value is purely derived from the two pee= rs who use that protocol and can now use conditional payments to protect th= emselves from their peers.
    =C2=A0
    The proposal that you're ar= guing for is basically asserting that we're going to be using CLP, beca= use it makes the assumption that the connectors (who understand ILP) are ma= naging the HTLA logic.

    N= ot at all. I am asserting that it doesn't matter what protocol you use = below the ILP layer because it shouldn't matter. All of this talk about= ILP being different because money is more important than data is nonsense.=

    The difference between ILP and IP that makes ILP suitable for= value transfer and IP not is at the internetworking layer. ILP requires th= at all packets are either a request or response and that the responses foll= ow the same path as the requests. Further ILP defines a signature scheme th= at gives the sender a way to be certain the request was received by the rec= eiver.

    This could be done entire= ly without money but then there would be little incentive to sign the r= eceipt or deliver the signature back to the original sender.

    <= div class=3D"gmail_quote">So, if you add money then you add economic incent= ives to the mix. At each hop the sender promises the next upstream peer a p= ayment if they can return the receipt. The net effect is that this can be u= sed to transfer money from the sender to the receiver by simply defining up= front the amount that the receiver must get to produce the signature.
    <= /div>
    =C2=A0
    =

    In the current model, the CLP/trustline model and the direct ledger m= odel both work without having to treat anything on the ILP layer differentl= y. We're favoring on-ledger messaging because of our implementation, ye= s, but we've been able to switch most all of our plugins from on-ledger= messaging to RPC-based messaging without changing the ILP layer at all.

    With the ledger-level abstraction, we were able to s= witch from our ledger-based mode of thinking to the CLP/trustline based way= without changing anything other than the plugin. Your argument comes from = an assumption of a CLP-style ledger protocol with some underlying ledger, w= hich we can't assume is always the case.
    <= br>
    I'm not sure what any of that proves tbh. These are all= implementation concerns. They don't change the fact that the condition= , expiry and fulfillment are part of ILP not the lower layer protocols.
    =C2=A0

    From= the perspective of the Interledger Protocol the implementation of the lowe= r layers is not important, that's the whole point of layering. By forci= ng important aspects of ILP like the condition, fulfillment and expiry down= into those layers you muddy the waters and we now have to standardize thos= e protocols too. Instead we should just be defining the functions they must= provide and then leave it up to implementations to provide those functions= .

    I don't agree with this= point; the condition and fulfillment have actual meaning to the ledger lay= er.

    NO THEY DON'T! = They have meaning to SOME ledgers that implement SOME lower layer protocols= , IF they choose to use them.

    Excuse the shouting but thi= s is the crux of the issue. We need to all agree that it is entirely possib= le for a transfer to be done that doesn't use the condition and fulfill= ment and that if this was in the middle of a 10-hop ILP payment it would ha= ve no effect on the sender and receiver.
    =C2=A0
    You've said that the led= ger often doesn't care about fulfillment and condition, but the ledger = _layer_'s (where transfers are done) role is to take in condition and f= ulfillment and make a transfer which satisfies its HTLA.

    No, the ledger's role is to keep a tab of = net financial positions between two peers. It MAY use conditions and fulfil= lments that it pulls from the ILP layer to help it do that in a way both pe= ers agree on.

    Note that a "lay= er" doesn't have a role. I think there is some confusion about the= difference between layering the protocol and abstracting functionality int= o different components.
    =C2=A0
    If the ledger layer has to look into the ILP packet to= do so, that is a blatant breaking of layering.

    Not at all! The module acting at the layers bel= ow the internetworking layer shouldn't modify anything inside the p= ackets of the higher layers but they can definitely inspect them and adjust= their behavior based on what they to find.

    In fact the preval= ence of this is the subject of a lot of debate at the IETF currently becaus= e endpoints are often encrypting their payloads and in some cases this make= s it difficult for middle-boxes to be effective at their jobs.
    By putting the condition, fulfillment, and expiry on t= he ledger layer, we leave it open for any ledger type to work, rather than = forcing all ledger-layer software to understand ILP.

    Actually you do the opposite. You make it a re= quirement of every protocol below the ILP layer to define a way to carry th= ese data elements and encode and decode them, even if they don't use th= em

    Ledger layer components don't have to understand I= LP unless they choose to re-use the condition for their own local transfer.= Ledgers themselves never have to understand ILP.

    Remember a= ledger layer protocol could use a completely different conditional payment= s scheme, like atomic mode ILP, where it takes the end-to-end condition and= creates a new compound condition that depends on the fulfillment and some = notary signature.

    There will be a component in a connecto= r's stack that must pass the ILP packet to the next peer. If it does th= is using a transfer protocol that uses conditional transfers and wants to u= se the same condition as the ILP packet then it must decode the packet.
    =
    But, it will likely do something with that condition before = sending the transfer to the ledger like encoding it differently or rehashin= g it (lightning?) so that it's in the form expected by the ledger.
    <= /div>

    That's an implementation decision of the lower= layer protocol used between those two peers.
    =C2=A0

    I agree that Interledger defines how conditions, fulfillments, and expir= ies should be chained together, but it makes no assertions about their data= format.

    ILP doesn'= t define how anything is chained together. From the perspective of ILP the = condition and fulfillment are end-to-end data. They are agreed by the two e= ndpoints who don't care how they get from Alice to Bob and back.
    The design of ILP is such that it facilitates the design of low= er level protocols that can be used to carry the ILP packets across multipl= e hops (networks) using economic incentives such that the sender pays enoug= h for the first hop to ensure that all nodes in between can extract the fee= they want and the receiver will still get the amount they expected..
    =C2=A0
    ILP says you should send your outgoing transfer with the sa= me condition as the incoming one, and a lower expiry.

    No it doesn't. An internetworking protoc= ol can't prescribe that kind of thing to lower level protocols. An inco= ming and outgoing transfer could be sent using completely different protoco= ls and the financial agreement with the peers on those two routes could be = vastly different too.

    The only service ILP requires of lower level p= rotocols is that they can map a response to an original request. This requi= rement is okay because it is isolated to a single route/link at a time not = a requirement that crosses the inter-network boundary that ILP crosses.
    =
    =C2=A0
    But because ILP allows for many different types of ledgers, i= t doesn't make sense to assert how these are encoded.

    By putting them in the ILP packet you do = the opposite. You make no assertions about how they are encoded if they are= used at lower layers, or how they may be combined with other conditions or= even used to derive new conditions.

    IP doesn't tell you= how to encode an ethernet packet. It doesn't even know whether it'= s going over a computer or a hand-written letter carried by a pigeon. IP ta= kes for granted that you can send data over one connection by putting it in= a lower level.

    Correct= , but if a link layer protocol wanted to look into the IP packet headers of= a packet it wants to transfer and use some data from there in its internal= logic (or even reuse data in it's own frame) that would be totally fin= e.
    =C2=A0
    Even though IP tells you how to chain these connection= s together, it doesn't have to put the things it's chaining on the = internetworking level.

    = IP doesn't tell you how to chain things together. IP simply defines the= end-to end data envelope and address space. Because of this nodes that imp= lement the multiple lower layer protocols are able to push IP packets down = a link and expect the node on the other side to understand the headers and = route it onward on another link.

    Everything needed by the= IP module to decide what to do with the packet is in the IP packet headers= . i.e. Has it exceeded a TTL? Is there a route for this destination? Is it = corrupted (checksum fails)? But also, everything that is needed by the endp= oint (like the source address) is also in there.

    There is= no dependency on nodes to be good citizens and always pass certain other d= ata from the lower layers into the next link. That would be breaking the la= yering.
    =C2=A0
    IP also assumes that if you get some incoming data= on a connection you can copy it and send it out on the next connection. Be= cause you can already send data over a connection, all IP adds is the missi= ng piece: a packet that tells you where to go.

    Wit= h ILP, we assume that there is a way to prepare a conditional transfer, exp= ire a conditional transfer, and fulfill a conditional transfer.

    No we don't! We assume that if= we deliver the packet as intended we'll get back a response packet wit= h a signature that matches the condition in the packet. So, if we have an a= greement with someone that they will pay us when we present that signature = then we are prepared to enter a similar agreement with the next peer becaus= e we expect that signature to come all the way back along the interledger l= ayer route..
    =C2=A0
    We also assume that if you get an incoming tr= ansfer you can create an outgoing transfer with the same condition. The abs= traction we made means that conditions and fulfillments are already carried= in the lower levels.

    Th= at is a bad assumption that comes from the broken layering. What if my outg= oing link doesn't support conditional transfers? So now where do I put = the condition?
    =C2=A0

    We could have assumed that no ledgers e= ver support conditional transfers, and said the only thing ILP gets from lo= wer levels is the ability to send a transfer. But if we want to support the= case where any of them do, we have to keep the conditions and fulfillments= in the layer where they're actually used.

    I don't follow that logic at all. If we want to = support the case where any of them do then we must ensure the condition and= expiry are always carried in a consistent place at the internetworking lay= er so that if they do want to use them they know where to find them.
    =C2=A0
    On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-= Bailie <adrian@hopebailie.com> wrote:


    On 14 August 2017 at 22:03, Evan Schwartz <= evan@ripple.com>= ; wrote:
    I= think this thread is going to get extremely unwieldy but here goes:<= div>
    >=C2=A0- All inte= rledger layer messages should be ILP packets (including fulfillments) and b= e capable of carrying higher layer protocol payloads.

    =
    Interledger has higher requirements than ILP for the lowe= st layer, specifically because we are carrying money and not just data. One= of the requirements is being able to transmit a 32-byte fulfillment back a= long the same path that carried the payment originally. If we expect this o= f the lower layer, I don't see a point in putting the fulfillment into = an ILP packet and transmitting it as Interledger data along the same path. = All ledger-layer protocols will need to interpret the fulfillment passed in= their protocol, not the one passed through the Interledger layer.

    This is not correct. There is no requ= irement on ledger layer protocols to transmit or understand the fulfillment= . You are looking at this through the lens of existing implementations from= the bottom up instead of starting at the interledger layer.

    =
    The primary function of the condition and fulfil= lment is as a signed end-to-end receipt. If the sender agrees a condition w= ith a receiver and then gets back the valid fulfillment they don't care= what happened in the middle. The receiver has signed a receipt saying they= have their money.

    The value of usi= ng a standard for the receipt and signature is that each transfer along the= way CAN re-use it. One the one hand you can have a transfer between two pe= ers that have zero trust and the ledger they use supports conditional payme= nts completely. On the other extreme you can have two peers that have a ful= l trust and ignore the condition and fulfillment completely.
    =C2= =A0
    The ledger layer protocols carry IL= P packets. Payment requests and either fulfillment or error responses. If a= ledger layer protocol wants to use the condition and fulfillment for their= own operations they can extract these from the ILP packets and use them.


    >=C2=A0- While it may make sense = to split the interledger payment and interledger quoting protocols into new= higher level protocols that seems like an unnecessary abstraction. Instead= the packet definitions should just have some consistency and probably a co= mmon base/header.

    =
    The current pr= otocols effectively have this header but it isn't separated out. There = are two fields in the request header: type and destination address. There i= s one field in the response header: type. I don't think it makes that m= uch of a big difference to separate these fields if all of the fields in th= at packet need to be interpreted together (for example, you can't under= stand a quote request if you strip off the destination address).

    I agree that we don't H= AVE to explicitly separate them out but I think ti would make it clearer ho= w the stack is architected if there was a header that was consistent across= all packets. Currently the only thing that is consitent across all ILP pac= kets is that they are defined int he same file.
    =C2=A0<= /div>

    >=C2=A0- We sh= ould define two base ILP packet types: request and response.
    Unless this adds so= me substantive benefit or new fields I don't think it's worth break= ing all of the formats we have just to rearrange things.

    The goal of this exercise is to tease out = the best design and ignore the cost of change until we can compare the resu= lts with the current design.
    =C2=A0

    >=C2= =A0- ILP is not about ledgers, it is ab= out trustlines between nodes/hosts.

    A ledger is any system that tracks accounts and balances= . When you use a trustline all of your messages still need to go through an= accounting system (such as the plugin in the JS implementation) and then o= n to the other program logic.

    As above, this is incorrect. There is no requirement for "all m= essages to go through an accounting system".

    Since d= esigning the first implementation of 5-bells ledger we have assumed that pa= ssing the ILP packet MUST be done by the ledger because that is how we impl= emented it. But that is not true. It is perfectly valid for the passing of = an ILP packet from one peer to another to be simply an exchange of data.
    The receiving peer makes a decision about whether or not to= forward the packet based on the current financial position they have with = the sending peer.

    It is convenient if the ledg= er that records the net positions of the peers also forwards the messaging = and even better if it natively supports conditional payments and can use th= e condition and the fulfillment from the ILP packet for those but that'= s all it is, convenient.

    =C2=A0
    In that case, the plugin or w= hatever is doing the accounting is the ledger. Digital value is always trac= ked in ledgers, so I think it does make sense to think of this as the base = layer. The reason to abstract the functionality you expect from the ledger = layer is precisely so you can handle it in different ways, depending on wha= t the underlying systems provide.

    I see 3 ways to = think of the layer(s) underpinning ILP:
    1. = The "Ledger Layer" provides both messaging capabilities and some = type of HTLA
    2. There are separate plugins for messaging and for= transfers and when you peer with someone you have to agree on a plugin for= each
    3. We standardize the messaging part and say that all goes over = IP and then just have more minimal plugins for the on-ledger settlements
    Number 1 is what we have and I think that still makes the most = sense.

    I think you're confusin= g implementation details and defining of interfaces with definition of a pr= otocol stack. The only differences between the tree examples you have above= is in implementation.

    From the perspective of the Interledger Proto= col the implementation of the lower layers is not important, that's the= whole point of layering. By forcing important aspects of ILP like the cond= ition, fulfillment and expiry down into those layers you muddy the waters a= nd we now have to standardize those protocols too. Instead we should just b= e defining the functions they must provide and then leave it up to implemen= tations to provide those functions.

    I know we want to define a standard to bootstrap the system (CLP) but that= 's misleading us into thinking it's an essential part of the stack.= It's perfectly valid for two peers to not use CLP and still be part of= the Interledger.

    That said, you raise an interesting consideration abo= ut the layers below ILP and actually I think it makes sense to split these.=

    We keep trying to force messaging through the ledger lay= er and actually that's the wrong place to put it if we can split the le= dger layer into a messaging layer and a ledger layer. That way we can stop = trying to think of all HLTAs as ledgers.

    A thought, why n= ot use sub-layers as is common in other stacks:

    1. Link l= ayer: Layer upon which two peers that have a direct link, or participate in= the same payment network, communicate
    2. Transfer/ ledger: L= ayer on which financial positions between two peers are recorded

    Thi= s reflects the already emerging HTLA model and many of our existing plugins= and ledger integrations.
    Link Layer: XRP Paychan, Lightning<= br>
    Ledger Layer: XRP Ledger, Bitcoin

    This doesn't prevent us from defining a standard binary protocol that= defines all of the operations for both layers (like CLP) but I see value i= n distinguishing between these two.
    =C2=A0

    &= gt;=C2=A0- The protocol should differen= tiate between the operation of preparing a transfer on a ledger and the ope= ration of passing an ILP packet from one peer to another.

    The protocol assumes your conditio= nal transfer is underpinned by some HTLA. It doesn't care whether that&#= 39;s on-ledger or not.

    What d= o you mean when you say "the protocol"? In my statement I am refe= rring to ILP.
    My point above being that ILP expects ILP packets to be p= assed from peer to peer but has no expectations about transfers.

    It's perfectly legal (from an ILP perspec= tive) for two peers to exchange ILP packets with no transfers. Clearly if a= node routes a packet on and has no incoming transfer it's going to los= e money but that's a consideration for that node. It doesn't affect= anyone else in the chain.

    ILP does= n't assume anything about transfers at all, let alone conditional trans= fers. It provides useful semantics for conditional transfers to be used by = two peers to transact as part of a larger ILP payment.
    =C2=A0
    <= div class=3D"gmail_quote">

    >=C2=A0- The condition and timeout should be included in the ILP payment = packet.

    I strongly disagree with thi= s. We had this debate a year ago and I was on your side but was convinced t= hat this is not a good idea.

    =
    Yes, I recall this and I'm sorry I didn't push harder on this = point. Unfortunately I think the decision to pull it out of the packet is m= ostly driven by how our prototypes were implemented rather than good archit= ecture.

    The layer below ILP must be capable of doing conditi= onal transfers based on sha256 hashlocks with 32-byte preimages.

    This is not true and I think it w= ould be useful for us to agree on this as this seems to be the argument I a= m coming up against most often. The peers participating in a transfer that = is part of an ILP payment may wish to use conditional transfers as a way to= enforce their agreement but this is not a requirement of the protocol.
    =
    The agreement between any two peers is: "I will pay you= X if you can provide a receipt that Y was paid Z before T".
    =
    ILP provides a standard for expressing this agreement so that these ca= n be chained together BUT it is not a requirement that every agreement in t= he chain uses the condition, and fulfillment provided at the ILP layer.
    =

    =C2=A0
    As a result, the original condition and the corresponding preimage M= UST be expressed in that layer.

    As I have shown above, this is not true.
    =C2= =A0
    Then t= he question is whether we should also include it in the packet that is forw= arded. What ultimately convinced me is the following: All connectors MUST i= gnore the condition if it is in the packet, because they are only guarantee= d their money back if they use the same condition from the incoming transfe= r they got.

    Here is where the layering is being corrupted.

    All connec= tors MUST inspect the condition in the ILP packet as part of their decision= to route the packet or not.
    When the l= ocal transfer module of the connectors stack passes the ILP packet up to th= e ILP module it should indicate the properties of the incoming transfer tha= t carried the packet.
    This is essential= firstly so that the routing logic in the ILP module can record the incomin= g transfer identifier so it is able to use the correct response id when it = passes back the fulfillment or error.
    The other properties that the ILP = module should look at are the condition and expiry on the incoming transfer= .

    If the incoming r= oute uses conditional transfers and these are supposed to match the conditi= on and expiry in the ILP packet then the ILP module should compare them and= reject the packet if:
    a) the conditions don't match OR
    b) the expiry is too short

    We should still d= iscuss if the expiry should be set by the sender and left unchanged or used= like a TTL and decremented by each node.
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
    Also, the receiv= er will need to take out the condition in order to hash the packet for PSK = or IPR.

    This is complet= ely normal. Zeroing a checksum field in a header before calculating the che= cksum is VERY common precisely because it's long been accepted that the= right place to put that data is in the headers and the work of zero'in= g it out to calculate the checksum (or signature in our case) is not materi= al.
    =C2=A0
    So basically, no one wants the condition in there. It = feels like it ought to be in there, but literally none of the parties want = the extra 32 bytes in there.

    =
    "Nobody wants it there" is a terrible reason to abandon the = correct design. The whole purpose of a good architecture is you accept that= there may be cases in future that haven't been considered now so desig= ning just for the known cases is a bad idea.

    Good archite= cture is not the same as optimization. Taking stuff out (even when it feels= wrong) to save a few bytes is a good sign that it's a bad idea.
    =C2=A0

    The reason the timeout should not be in there is = that there isn't a single timeout for the payment. There are multiple s= eparate timeouts for each of the bilateral transfers. Those must go in the = individual transfers and there is no sensible value to put in the Interledg= er packet.
    =C2=A0
    As above, t= his is somewhat equivalent to the TTL in an IP packet. I'm open to disc= ussing if it should be a fixed value set by the sender where each node uses= their own value but has the sender-defined value as a reference or it is a= ctually decremented at each hop.

    Either way, this is part= of ILP not the ledger layer just like the condition and fulfillment. It ma= y be used by the ledger layer but that's implementation specific. It be= longs in the ILP packet.
    =C2=A0





    --
    Sen= t from a mobile device, please excuse any typos





    --001a1148d5b28e078f055707adb9-- From nobody Fri Aug 18 13:07:40 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792F0132320 for ; Fri, 18 Aug 2017 13:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 O6OViaQhzJmN for ; Fri, 18 Aug 2017 13:07:29 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 6A7021320BB for ; Fri, 18 Aug 2017 13:07:29 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id d124so35675913vkf.2 for ; Fri, 18 Aug 2017 13:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e0nig7ziAK4xpX/OzkewJo6VdFCbJqCMBZdfP/eiwXQ=; b=RnqoiobsiQR7jTcs/TxF0pbIB+BHQ3OrkXXRb+i+xz9/DeH9eRplDuJtguah1pkcMm v0puXX4g7DmgYCWgysHyMv3RTQhfxFr7aQcVfcco0EnyfZGaq6hv7PSE23lk0Pzbywci zxzb8I9UfKVpqIKcQpomwtwFyCKMcWRQClsG0= 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=e0nig7ziAK4xpX/OzkewJo6VdFCbJqCMBZdfP/eiwXQ=; b=MhFOSHZhl6Kw8GzQZyr5AG/V1Ev/ew2TCCU2J7pmhL0giGn4I3Dq9n082MwaNtGRUd iNd1KOwZqfk6x1VQz7Y7s6FTzCVOOulEJr9+GnbkbazeN66i/mrvfNSnWhj/FyKWeFBQ BxrJkUC+9IePgIaZtwqyjbXfo51prXJffSRYwYTor4N3NFqnHC91FxQx0B+7VjwlV935 T/bqEmKYps/02+xCHrPCh87PXsWrKdvPDnSEF3Tr+E9BUq0bHVOpNx2H0CplKihbnlSh iRpdvV9RAqmgZBJAwLSLoIwfdPgx0eCQ+292Q43X2LM2N/VONgE0+25bkGMn5EDy5ZxI caVg== X-Gm-Message-State: AHYfb5hGNcXg2QG2BDV97fbRlExIS4Eql380yquVhJlxTszcdnm7o9RX bqC9cBN5MXcMfGzaodJ3RL7+zH22JLtkwpA= X-Received: by 10.31.223.68 with SMTP id w65mr6460240vkg.27.1503086848188; Fri, 18 Aug 2017 13:07:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.62.90 with HTTP; Fri, 18 Aug 2017 13:07:27 -0700 (PDT) In-Reply-To: References: From: Adrian Hope-Bailie Date: Fri, 18 Aug 2017 21:07:27 +0100 Message-ID: To: Ben Sharafian Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="94eb2c07cc8ea7364d05570cad59" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 20:07:38 -0000 --94eb2c07cc8ea7364d05570cad59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 18 August 2017 at 15:09, Ben Sharafian wrote: > What you're describing is an implementation of a local transfer service >> that doesn't (or can't) take advantage of Interledger. In fact, this wil= l >> be the norm for most existing payment networks that we want to add to th= e >> Interledger and this is where your work on payment channels and HTLAs co= mes >> in to play. > > > >> >> If you have a local transfer channel that doesn't support conditions >> natively or supports them in a way that requires some adaption you can >> create an overlay network that does what's needed. Example: Bitcoin is n= ot >> a suitable network to use for ILP so we use a payment channel between th= e >> peers that is underwritten by Bitcoin. > > > Exactly, when I say you need a to handle the condition and fulfillment vi= a > a clearing layer, this "overlay network" is what I'm referring to. The > whole point of an HTLA is that from ILP's point of view it's just a > lower-level protocol that can commit conditional transfers and fulfill > them. ILP doesn't care how the ledger/HTLA works under the hood, whether > it's a clearing/overlay layer or a "real" ledger. > My point is that it goes beyond that. ILP doesn't care if the layer below even has a concept of HTLAs. I can do ILP over Bitcoin without the overlay layer if I want to but I need to find a peer that is prepared to do that with me. In that case all I have to do is send them the ILP packet in a message that says I owe them some Bitcoin. the "owe them some Bitcoin" isn't being enforced anywhere using an HTLA. > > > You're equating this "overlay network," which is a type of ledger, with > the ILP layer. > Not at all. I agree with what you have below. It's a layer that exists below ILP but above the actual ledger. But crucially it's not a requirement for ILP to work so the protocol should depend on it existing. > If there is an overlay network that handles the condition and fulfillment= , > that means you _are_ using a ledger, because the overlay network _is_ a > ledger. The ILP layer is a layer above this. > Agreed. > > If we assume the ILP packet is well defined with all the ILP-required dat= a >> elements then when a lower layer wants to use that data it can but shoul= d >> do it in a way that doesn't break the ILP layer for everyone else. How t= hat >> is implemented in practice will depend on the lower layer protocol. > > > That's one way to see it, but what I'm wondering is why that's a better > model than saying there's a clearly defined interface that the ledger-lay= er > exposes, and then building the ILP layer on top of that. > Because that's not how you build a protocol stack. A protocol stack is not defined through interfaces. It's defined through layers of data where each layer has a standard packet format with headers carrying data for that layer and encapsulates the data of layer(s) above in the payload. The condition, fulfillment and expiry are part of ILP so they belong in the ILP packet. If there are lower layers that want to use those things then they can but ILP shouldn't depend on that. > > Unless the next hop is backwards > > > There's no reason to send a backwards hop. If you don't want to forward a > payment you reject it. > That's what I mean by a backwards hop. I was illustrating my point that validating a packet is part of the routing decision. > > Not at all. You're assuming that there is no expiry on the local transfer= . >> As a receiving node I have an incoming transfer with an expiry and it >> carries an ILP packet that also has an expiry. > > > If that's what you're talking about, the ILP packet already has an expiry= . > It's implemented in the PSK details so the receiver knows whether the > packet it issued is still valid. But that's an application layer concern, > because it's only the receiver who looks at the ILP packet's expiry. The > connectors only need to know the expiries of the local transfers. > There is a big misconception in your statement. The expiry is an end-to-end concern, or as you put it the sender sets and "the receiver looks at the ILP packet's expiry". That's why it's in the ILP packet. The idea that anything to be exchanged end-to-end must be in higher layers is completely wrong. The reason you'd put something in a higher layer payload is because the endpoints have agreed to use a higher layer protocol that requires it to be there. > On Fri, Aug 18, 2017 at 3:21 PM, Adrian Hope-Bailie > wrote: > >> >> >> On 18 August 2017 at 10:38, Ben Sharafian wrote: >> >>> Two connectors exchanging a transfer only care about the data that is >>>> relevant to them for that transfer. It's quite possible for two connec= tors >>>> to perform a transfer that has no conditions or fulfillments or a tran= sfer >>>> that has a different condition and fulfillment (such as an atomic mode >>>> transfer where the condition is a compound one that has multiple >>>> sub-conditions). >>> >>> >>> Yes, two connectors could absolutely send an unconditional transfer on >>> an underlying ledger in order to settle an Interledger payment. But in >>> order to benefit from any of Interledger's guarantees (trustless >>> connectors, retry-ability, etc.), they MUST keep a conditional local >>> transfer, at least for clearing. If the local transfer cannot time out,= it >>> cannot be safely retried. If the local transfer clears without a >>> fulfillment, it loses the "receipt or your money back" property. Yes, t= wo >>> parties in the chain could eschew these benefits but that is no longer = a >>> correct implementation of Interledger. >>> >> >> Aha! That is where I disagree! Interledger is not implemented at the >> local transfer layer, it is implemented at the Interledger layer. The wh= ole >> point is that it an Interledger payment can travel over payment networks >> that know nothing about ILP but the greatest value comes from using ones >> that do. >> >> What you're describing is an implementation of a local transfer service >> that doesn't (or can't) take advantage of Interledger. In fact, this wil= l >> be the norm for most existing payment networks that we want to add to th= e >> Interledger and this is where your work on payment channels and HTLAs co= mes >> in to play. >> >> If you have a local transfer channel that doesn't support conditions >> natively or supports them in a way that requires some adaption you can >> create an overlay network that does what's needed. Example: Bitcoin is n= ot >> a suitable network to use for ILP so we use a payment channel between th= e >> peers that is underwritten by Bitcoin. >> >> >>> >>> If a protocol at a lower layer wants to use that data then it must >>>> replicate it. That seems inefficient but it's the correct way to do it= . >>> >>> >>> What's the actual reasoning behind this, and why is it considered the >>> correct approach? If there's some IETF document that says this I'd like= to >>> see it, because it intuitively feels wrong to have lower level abstract= ions >>> looking into higher levels. >>> >> >> The data in the ILP layer is there for a specific reason. It's part of a= n >> end-to-end exchange between the sender and receiver. >> >> >> *Side note: It's unusual to be designing the whole stack at once so we >> keep being tempted to move things around but in reality we should look a= t >> the ILP layer in isolation and make sure it is complete. Alternatively w= e >> should try to test our design against a number of lower and upper layer >> protocols to make sure our thinking is sound.* >> If we assume the ILP packet is well defined with all the ILP-required >> data elements then when a lower layer wants to use that data it can but >> should do it in a way that doesn't break the ILP layer for everyone else= . >> How that is implemented in practice will depend on the lower layer >> protocol. >> >> >>> >>> Routing requires looking at the condition, expiry and amount. A >>>> connector's routing logic shouldn't forward a packet if the expiry is = too >>>> low or if the condition is obviously corrupted. >>> >>> >>> Those are validity checks and you're right that they are performed in >>> the connector, but the destination account, destination amount, and dat= a >>> are enough to figure out what the best next hop is. >>> >> >> Unless the next hop is backwards >> >> >>> >>> The ILP Packet's purpose is to describe where a payment is going. >>> >> >> Not only that. For comparison, an IP packet does a lot more than just >> describe where a packet is going. All end-to-end concerns need to be in >> there too. >> >> >>> The data it carries is only for the purpose of making sure the receiver >>> can identify that payment. >>> >> >> No, the condition is there so the receiver can ensure it is sending back >> the correct fulfillment and the expiry to give the receiver some assuran= ce >> that the packet is still worth processing. >> >> >>> In that context, the expiry has no bearing on where it will be routed >>> nor on how much to route, only on whether or not an individual connecto= r >>> will take the risk of forwarding it. >>> >>> The ILP packet just contains the end-to-end condition (always a SHA-256 >>>> hash) and then the local transfer can have a different condition that = is >>>> derived from the condition in the ILP packet. >>> >>> >>> Fair enough; in your case you can transmit the condition twice and >>> verify the structure of the complex local condition, and in the >>> no-condition-in-ILP version you can verify the structure of the local >>> condition and extract the SHA256 condition to pass on. >>> >>> I think the expiry should always be the expiry set by the sender. It >>>> won't be changed. >>> >>> >>> That increases connector risk enormously, allowing anybody to cause a >>> connector to lose money by submitting a fulfillment at the last moment. >>> >> >> Not at all. You're assuming that there is no expiry on the local >> transfer. As a receiving node I have an incoming transfer with an expiry >> and it carries an ILP packet that also has an expiry. >> >> My routing logic should look at both and decide a) if this is safe to >> route on (i.e. put some of my own capital at risk) and b) what expiry to >> set on the next hop. >> >> There is no incentive to change the expiry in the packet as this can onl= y >> be targeted at upstream connectors and the result will simply be that th= e >> payment is declined and the upstream local transfer rolls back. >> >> >>> If an attacker knows enough about latency in the chain, they could even >>> target this attack at somebody many hops away. Staggering expiries (giv= ing >>> you a minimum amount of time to fulfill a source transfer) is an easy >>> mitigation against this attack; we shouldn't take it out. >>> >> >> I agree. We would still have the local expiry. >> >> >>> >>> Comparing the condition in the local transfer and the one in the ILP >>>> packet should be part of the routing logic. >>> >>> >>> Sure, it can be done as an extra validity check, but it's just more cod= e >>> and more attack surface. I still don't see any tangible benefit from >>> doing the layering in this way, aside from your assertion that it's the >>> correct way to do it. If you've read any documents that explain why thi= s is >>> the correct way to do layering, I think I'd understand you better. >>> >>> >>> On Thu, Aug 17, 2017 at 7:32 PM, Adrian Hope-Bailie < >>> adrian@hopebailie.com> wrote: >>> >>>> >>>> >>>> On 16 August 2017 at 10:22, Ben Sharafian wrote= : >>>> >>>>> OK, I think in that case we're mostly disagreeing over where the >>>>> condition/fulfillment/expiry actually go in the data. >>>>> >>>> >>>> That's one way to look at it but that's ultimately what the >>>> architecting the layering is. Deciding at which layer (and therefor >>>> encapsulated in what packet) certain data should be. >>>> >>>> >>>>> The reason I don't agree with your position is based on which parties >>>>> I think should be aware of ILP. >>>>> >>>> >>>> I don't think that's the right way to look at it. The connector needs >>>> to be able to understand at least the ILP layer data AND the lower lay= er >>>> data. Normally the way the processing stack is implemented is that the= re is >>>> a module for each layer that processes the data from that layer and th= en >>>> passes the payload and any other important information up to the next = layer. >>>> >>>> >>>>> In order to track the balance between each other accurately, the two >>>>> connectors have to keep track of conditions, fulfillments, and expiri= es on >>>>> each of the transfers. >>>>> >>>> >>>> This is where I disagree with you. Two connectors exchanging a transfe= r >>>> only care about the data that is relevant to them for that transfer. I= t's >>>> quite possible for two connectors to perform a transfer that has no >>>> conditions or fulfillments or a transfer that has a different conditio= n and >>>> fulfillment (such as an atomic mode transfer where the condition is a >>>> compound one that has multiple sub-conditions). >>>> >>>> >>>>> That means the connectors' accounting logic that handles the >>>>> conditions, fulfillments, and expiries is going to be using some >>>>> information inside the ILP packet and some information outside of it = in >>>>> order to perform these transfers. >>>>> >>>> >>>> It will only use info inside the packet if it uses conditional >>>> transfers that use that same condition. This is the most likely scenar= io >>>> but that is not a protocol requirement. >>>> >>>> >>>>> >>>>> I think it's cleaner to say everything required to make these local >>>>> transfers should go in one protocol, so the accounting logic of these >>>>> connectors doesn't have to deal with ILP directly. >>>>> >>>> >>>> I strongly disagree with that. That's entirely the wrong reason to put >>>> data into a specific layer. The data in the ILP layer is there because= it's >>>> "end-to-end" data. >>>> >>>> If a protocol at a lower layer wants to use that data then it must >>>> replicate it. That seems inefficient but it's the correct way to do it= . >>>> >>>> One could define a lower layer protocol that doesn't replicate the dat= a >>>> but the rules of the protocol are "Get the condition from the ILP pack= et". >>>> In that case, that specific lower level protocol is forcing implementa= tions >>>> to understand the ILP packet format, that's an implementation detail. >>>> >>>> Another lower layer protocol might take the condition from the ILP >>>> packet and re-encode it in a different form (like a base64ulr string o= r NI: >>>> uri) >>>> >>>> >>>>> Then the connectors' ILP-packet-related behavior can all be routing >>>>> related. >>>>> >>>> >>>> Routing requires looking at the condition, expiry and amount. A >>>> connector's routing logic shouldn't forward a packet if the expiry is = too >>>> low or if the condition is obviously corrupted. >>>> >>>> If the protocols were designed correctly as I am proposing then anothe= r >>>> routing decision would be, is the condition that was used in the incom= ing >>>> transfer the same as the one used in the ILP packet? >>>> >>>> >>>> >>>>> This would add a few benefits; two connectors could perform non-ILP >>>>> conditional transfers between one another (which would be useful for >>>>> reconciliation and settlement), and could also allow two connectors t= o use >>>>> more complex condition types (i.e. signatures for atomic mode) withou= t >>>>> forcing us to support that in the ILP packet. >>>>> >>>> >>>> You seem to have this backwards. Both of these things are supported if >>>> the condition and expiry ARE in the ILP packet. Atomic mode is not >>>> supported in the ILP protocol it is supported in the lower layer trans= fer >>>> protocol. The ILP packet just contains the end-to-end condition (alway= s a >>>> SHA-256 hash) and then the local transfer can have a different conditi= on >>>> that is derived from the condition in the ILP packet. >>>> >>>> >>>>> It also keeps the integrity of the ILP packet as something lower >>>>> levels don't modify; the connector has to modify the expiry in order = to >>>>> pass along an ILP payment (they may not modify the expiry if they're = using >>>>> something like atomic mode, but then we have the issue with advanced >>>>> condition types not being supported in the ILP packet). >>>>> >>>> >>>> I think the expiry should always be the expiry set by the sender. It >>>> won't be changed. >>>> >>>>> >>>>> In the case where the ledger _does_ care about the condition and >>>>> fulfillment, the argument in favor of separating >>>>> condition/fulfillment/expiry from the rest of the packet is similar. >>>>> Because we don't control the features of all ledgers, we'll need our >>>>> plugins or ledger adapters to be aware of ILP. This makes it hard to >>>>> interact with any events that don't involve ILP packets, and impossib= le to >>>>> handle features that extend beyond what we support in the ILP packet.= We >>>>> could pass details about non-ILP ledger features (like a crypto condi= tion) >>>>> in the side data, but in the event of any redundancy we have to check= the >>>>> ledger-supplied info, not the info in the ILP packet. >>>>> >>>> >>>> Comparing the condition in the local transfer and the one in the ILP >>>> packet should be part of the routing logic. >>>> >>>> >>>>> >>>>> Basically, condition/fulfillment/expiry are used for accounting local >>>>> transfers (even if they aren't being "ledger" enforced) in addition t= o >>>>> their role as every-hop information. By putting them in the ILP packe= t, we >>>>> limit the special features that ledgers can support and make our soft= ware >>>>> abstractions harder to separate cleanly. By putting them in the local >>>>> transfer alongside the ILP packet but not inside it, we do separate t= he >>>>> data a little more, but we have more freedom in what the underlying >>>>> accounting and ledger logic can do, and our software modules will hav= e more >>>>> clearly separated domains. >>>>> >>>> >>>> They should be in both the local transfer AND the ILP packet if they >>>> are needed by the local transfer protocol. This allows the flexibility= you >>>> desire because the local transfer protocol can do ANYTHING including u= sing >>>> the condition from the ILP packet as-is, not at all or enhanced for >>>> something like atomic mode. >>>> >>>> >>>> >>>>> >>>>> On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie < >>>>> adrian@hopebailie.com> wrote: >>>>> >>>>>> Exactly =F0=9F=91=8D >>>>>> >>>>>> On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian >>>>>> wrote: >>>>>> >>>>>>> Ok, I think I have a better idea of what you're saying. >>>>>>> >>>>>>> It sounds like you're saying the ILP layer contains all information >>>>>>> that is common between every hop (destination, destination amount, = opaque >>>>>>> data, condition, fulfillment, expiry). The lower level would then b= e used >>>>>>> for all the transfer-local details (source amount, next connector a= ccount, >>>>>>> custom/local data). >>>>>>> >>>>>>> If the lower level wanted to do anything related to the every-hop >>>>>>> payment, i.e. escrow funds until the receipt has been produced, it = would >>>>>>> look into the ILP layer for that information. If the lower level di= dn't do >>>>>>> any escrow or expiries that require every-hop details, it would sim= ply >>>>>>> function as a communication method. >>>>>>> >>>>>>> Is that right? >>>>>>> >>>>>>> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >>>>>>> adrian@hopebailie.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 15 August 2017 at 16:00, Ben Sharafian >>>>>>>> wrote: >>>>>>>> >>>>>>>>> In that case, the plugin or whatever is doing the accounting is >>>>>>>>>>>> the ledger. Digital value is always tracked in ledgers, so I t= hink it does >>>>>>>>>>>> make sense to think of this as the base layer. The reason to a= bstract the >>>>>>>>>>>> functionality you expect from the ledger layer is precisely so= you can >>>>>>>>>>>> handle it in different ways, depending on what the underlying = systems >>>>>>>>>>>> provide. >>>>>>>>>>> >>>>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>>>> >>>>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities >>>>>>>>>>> and some type of HTLA >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. There are separate plugins for messaging and for >>>>>>>>>>> transfers and when you peer with someone you have to agree o= n a plugin for >>>>>>>>>>> each >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 1. We standardize the messaging part and say that all goes >>>>>>>>>>> over IP and then just have more minimal plugins for the on-l= edger >>>>>>>>>>> settlements >>>>>>>>>>> >>>>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>>>> sense. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I think you're confusing implementation details and defining of >>>>>>>>>> interfaces with definition of a protocol stack. The only differe= nces >>>>>>>>>> between the tree examples you have above is in implementation. >>>>>>>>> >>>>>>>>> >>>>>>>>> I had to scroll up after reading this to make sure it was @adrian >>>>>>>>> talking, because that seems like the opposite of what you were ar= guing for. >>>>>>>>> >>>>>>>> >>>>>>>> I don't think so. But I think that is part of the problem. We are >>>>>>>> not all focused on the same thing. I am actually not very interest= ed in CLP >>>>>>>> at all. It is one of potentially many protocols that may exist bel= ow the >>>>>>>> ILP layer. All we're doing by defining CLP is bootstrapping the ne= twork by >>>>>>>> defining a protocol for everyone to use to get started. >>>>>>>> >>>>>>>> In designing the ILP layer properly we should try and forget >>>>>>>> everything we know about the lower layers other than what features= we >>>>>>>> require of them. >>>>>>>> >>>>>>>> There is a misconception that ILP requires the lower layers to >>>>>>>> support conditional transfers, that is not true. >>>>>>>> >>>>>>>> All we actually need from a lower layer protocol is to transfer >>>>>>>> data back and forth and provide a way to reliably map requests to = responses. >>>>>>>> >>>>>>>> What ILP provides lower layers is a way to reward your peer for >>>>>>>> passing on the packet. The Internetworking layer defines a conditi= on, a >>>>>>>> reward that must be paid to the receiver for the fulfillment and t= he time >>>>>>>> allowed to claim this reward. >>>>>>>> >>>>>>>> Because of this, within lower-layer protocols that offer the basic >>>>>>>> request/response features we need, we could add conditional paymen= t >>>>>>>> semantics that use the condition, expiry and fulfillment provided = by ILP. >>>>>>>> This would allow a node to offer a reward to their next peer to f= or >>>>>>>> delivering the packet they send them and to make the local financi= al >>>>>>>> transaction contingent on the end-to-end transaction. >>>>>>>> >>>>>>>> But crucially, adding that semantic to the lower layer protocol >>>>>>>> provides nothing extra to the ILP layer. The value is purely deriv= ed from >>>>>>>> the two peers who use that protocol and can now use conditional pa= yments to >>>>>>>> protect themselves from their peers. >>>>>>>> >>>>>>>> >>>>>>>>> The proposal that you're arguing for is basically asserting that >>>>>>>>> we're going to be using CLP, because it makes the assumption that= the >>>>>>>>> connectors (who understand ILP) are managing the HTLA logic. >>>>>>>>> >>>>>>>> >>>>>>>> Not at all. I am asserting that it doesn't matter what protocol yo= u >>>>>>>> use below the ILP layer because it shouldn't matter. All of this t= alk about >>>>>>>> ILP being different because money is more important than data is n= onsense. >>>>>>>> >>>>>>>> The difference between ILP and IP that makes ILP suitable for valu= e >>>>>>>> transfer and IP not is at the internetworking layer. ILP requires = that all >>>>>>>> packets are either a request or response and that the responses fo= llow the >>>>>>>> same path as the requests. Further ILP defines a signature scheme = that >>>>>>>> gives the sender a way to be certain the request was received by t= he >>>>>>>> receiver. >>>>>>>> >>>>>>>> *This could be done entirely without money* but then there would >>>>>>>> be little incentive to sign the receipt or deliver the signature b= ack to >>>>>>>> the original sender. >>>>>>>> >>>>>>>> So, if you add money then you add economic incentives to the mix. >>>>>>>> At each hop the sender promises the next upstream peer a payment i= f they >>>>>>>> can return the receipt. The net effect is that this can be used to= transfer >>>>>>>> money from the sender to the receiver by simply defining up front = the >>>>>>>> amount that the receiver must get to produce the signature. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> In the current model, the CLP/trustline model and the direct >>>>>>>>> ledger model both work without having to treat anything on the IL= P layer >>>>>>>>> differently. We're favoring on-ledger messaging because of our >>>>>>>>> implementation, yes, but we've been able to switch most all of ou= r plugins >>>>>>>>> from on-ledger messaging to RPC-based messaging without changing = the ILP >>>>>>>>> layer at all. >>>>>>>>> >>>>>>>>> With the ledger-level abstraction, we were able to switch from ou= r >>>>>>>>> ledger-based mode of thinking to the CLP/trustline based way with= out >>>>>>>>> changing anything other than the plugin. Your argument comes from= an >>>>>>>>> assumption of a CLP-style ledger protocol with some underlying le= dger, >>>>>>>>> which we can't assume is always the case. >>>>>>>>> >>>>>>>> >>>>>>>> I'm not sure what any of that proves tbh. These are all >>>>>>>> implementation concerns. They don't change the fact that the condi= tion, >>>>>>>> expiry and fulfillment are part of ILP not the lower layer protoco= ls. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> From the perspective of the Interledger Protocol the >>>>>>>>>> implementation of the lower layers is not important, that's the = whole point >>>>>>>>>> of layering. By forcing important aspects of ILP like the condit= ion, >>>>>>>>>> fulfillment and expiry down into those layers you muddy the wate= rs and we >>>>>>>>>> now have to standardize those protocols too. Instead we should j= ust be >>>>>>>>>> defining the functions they must provide and then leave it up to >>>>>>>>>> implementations to provide those functions. >>>>>>>>> >>>>>>>>> >>>>>>>>> I don't agree with this point; the condition and fulfillment have >>>>>>>>> actual meaning to the ledger layer. >>>>>>>>> >>>>>>>> >>>>>>>> NO THEY DON'T! They have meaning to SOME ledgers that implement >>>>>>>> SOME lower layer protocols, IF they choose to use them. >>>>>>>> >>>>>>>> Excuse the shouting but this is the crux of the issue. We need to >>>>>>>> all agree that it is entirely possible for a transfer to be done t= hat >>>>>>>> doesn't use the condition and fulfillment and that if this was in = the >>>>>>>> middle of a 10-hop ILP payment it would have no effect on the send= er and >>>>>>>> receiver. >>>>>>>> >>>>>>>>> >>>>>>>>> You've said that the ledger often doesn't care about fulfillment >>>>>>>>> and condition, but the ledger _layer_'s (where transfers are done= ) role is >>>>>>>>> to take in condition and fulfillment and make a transfer which sa= tisfies >>>>>>>>> its HTLA. >>>>>>>>> >>>>>>>> >>>>>>>> No, the ledger's role is to keep a tab of net financial positions >>>>>>>> between two peers. It MAY use conditions and fulfillments that it = pulls >>>>>>>> from the ILP layer to help it do that in a way both peers agree on= . >>>>>>>> >>>>>>>> Note that a "layer" doesn't have a role. I think there is some >>>>>>>> confusion about the difference between layering the protocol and >>>>>>>> abstracting functionality into different components. >>>>>>>> >>>>>>>> >>>>>>>>> If the ledger layer has to look into the ILP packet to do so, tha= t >>>>>>>>> is a blatant breaking of layering. >>>>>>>>> >>>>>>>> >>>>>>>> Not at all! The module acting at the layers *below* the >>>>>>>> internetworking layer shouldn't modify anything inside the packets= of the >>>>>>>> higher layers but they can definitely inspect them and adjust thei= r >>>>>>>> behavior based on what they to find. >>>>>>>> >>>>>>>> In fact the prevalence of this is the subject of a lot of debate a= t >>>>>>>> the IETF currently because endpoints are often encrypting their pa= yloads >>>>>>>> and in some cases this makes it difficult for middle-boxes to be e= ffective >>>>>>>> at their jobs. >>>>>>>> >>>>>>>> By putting the condition, fulfillment, and expiry on the ledger >>>>>>>>> layer, we leave it open for any ledger type to work, rather than = forcing >>>>>>>>> all ledger-layer software to understand ILP. >>>>>>>>> >>>>>>>> >>>>>>>> Actually you do the opposite. You make it a requirement of every >>>>>>>> protocol below the ILP layer to define a way to carry these data e= lements >>>>>>>> and encode and decode them, even if they don't use them >>>>>>>> >>>>>>>> Ledger layer components don't have to understand ILP unless they >>>>>>>> choose to re-use the condition for their own local transfer. Ledge= rs >>>>>>>> themselves *never* have to understand ILP. >>>>>>>> >>>>>>>> Remember a ledger layer protocol could use a completely different >>>>>>>> conditional payments scheme, like atomic mode ILP, where it takes = the >>>>>>>> end-to-end condition and creates a new compound condition that dep= ends on >>>>>>>> the fulfillment and some notary signature. >>>>>>>> >>>>>>>> There will be a component in a connector's stack that must pass th= e >>>>>>>> ILP packet to the next peer. If it does this using a transfer prot= ocol that >>>>>>>> uses conditional transfers and wants to use the same condition as = the ILP >>>>>>>> packet then it must decode the packet. >>>>>>>> >>>>>>>> But, it will likely do something with that condition before sendin= g >>>>>>>> the transfer to the ledger like encoding it differently or rehashi= ng it >>>>>>>> (lightning?) so that it's in the form expected by the ledger. >>>>>>>> >>>>>>>> That's an implementation decision of the lower layer protocol used >>>>>>>> between those two peers. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I agree that Interledger defines how conditions, fulfillments, an= d >>>>>>>>> expiries should be chained together, but it makes no assertions a= bout their >>>>>>>>> data format. >>>>>>>>> >>>>>>>> >>>>>>>> ILP doesn't define how anything is chained together. From the >>>>>>>> perspective of ILP the condition and fulfillment are end-to-end da= ta. They >>>>>>>> are agreed by the two endpoints who don't care how they get from A= lice to >>>>>>>> Bob and back. >>>>>>>> >>>>>>>> The design of ILP is such that it facilitates the design of lower >>>>>>>> level protocols that can be used to carry the ILP packets across m= ultiple >>>>>>>> hops (networks) using economic incentives such that the sender pay= s enough >>>>>>>> for the first hop to ensure that all nodes in between can extract = the fee >>>>>>>> they want and the receiver will still get the amount they expected= .. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> ILP says you should send your outgoing transfer with the same >>>>>>>>> condition as the incoming one, and a lower expiry. >>>>>>>>> >>>>>>>> >>>>>>>> No it doesn't. An internetworking protocol can't prescribe that >>>>>>>> kind of thing to lower level protocols. An incoming and outgoing t= ransfer >>>>>>>> could be sent using completely different protocols and the financi= al >>>>>>>> agreement with the peers on those two routes could be vastly diffe= rent too. >>>>>>>> >>>>>>>> The only service ILP requires of lower level protocols is that the= y >>>>>>>> can map a response to an original request. This requirement is oka= y because >>>>>>>> it is isolated to a single route/link at a time not a requirement = that >>>>>>>> crosses the inter-network boundary that ILP crosses. >>>>>>>> >>>>>>>> >>>>>>>>> But because ILP allows for many different types of ledgers, it >>>>>>>>> doesn't make sense to assert how these are encoded. >>>>>>>>> >>>>>>>> >>>>>>>> By putting them in the ILP packet you do the opposite. You make no >>>>>>>> assertions about how they are encoded if they are used at lower la= yers, or >>>>>>>> how they may be combined with other conditions or even used to der= ive new >>>>>>>> conditions. >>>>>>>> >>>>>>>>> >>>>>>>>> IP doesn't tell you how to encode an ethernet packet. It doesn't >>>>>>>>> even know whether it's going over a computer or a hand-written le= tter >>>>>>>>> carried by a pigeon. IP takes for granted that you can send data = over one >>>>>>>>> connection by putting it in a lower level. >>>>>>>>> >>>>>>>> >>>>>>>> Correct, but if a link layer protocol wanted to look into the IP >>>>>>>> packet headers of a packet it wants to transfer and use some data = from >>>>>>>> there in its internal logic (or even reuse data in it's own frame)= that >>>>>>>> would be totally fine. >>>>>>>> >>>>>>>> >>>>>>>>> Even though IP tells you how to chain these connections together, >>>>>>>>> it doesn't have to put the things it's chaining on the internetwo= rking >>>>>>>>> level. >>>>>>>>> >>>>>>>> >>>>>>>> IP doesn't tell you how to chain things together. IP simply define= s >>>>>>>> the end-to end data envelope and address space. Because of this no= des that >>>>>>>> implement the multiple lower layer protocols are able to push IP p= ackets >>>>>>>> down a link and expect the node on the other side to understand th= e headers >>>>>>>> and route it onward on another link. >>>>>>>> >>>>>>>> Everything needed by the IP module to decide what to do with the >>>>>>>> packet is in the IP packet headers. i.e. Has it exceeded a TTL? Is= there a >>>>>>>> route for this destination? Is it corrupted (checksum fails)? But = also, >>>>>>>> everything that is needed by the endpoint (like the source address= ) is also >>>>>>>> in there. >>>>>>>> >>>>>>>> There is no dependency on nodes to be good citizens and always pas= s >>>>>>>> certain other data from the lower layers into the next link. That = would be >>>>>>>> breaking the layering. >>>>>>>> >>>>>>>> >>>>>>>>> IP also assumes that if you get some incoming data on a connectio= n >>>>>>>>> you can copy it and send it out on the next connection. Because y= ou can >>>>>>>>> already send data over a connection, all IP adds is the missing p= iece: a >>>>>>>>> packet that tells you where to go. >>>>>>>>> >>>>>>>>> With ILP, we assume that there is a way to prepare a conditional >>>>>>>>> transfer, expire a conditional transfer, and fulfill a conditiona= l >>>>>>>>> transfer. >>>>>>>>> >>>>>>>> >>>>>>>> No we don't! We assume that if we deliver the packet as intended >>>>>>>> we'll get back a response packet with a signature that matches the >>>>>>>> condition in the packet. So, if we have an agreement with someone = that they >>>>>>>> will pay us when we present that signature then we are prepared to= enter a >>>>>>>> similar agreement with the next peer because we expect that signat= ure to >>>>>>>> come all the way back along the interledger layer route.. >>>>>>>> >>>>>>>> >>>>>>>>> We also assume that if you get an incoming transfer you can creat= e >>>>>>>>> an outgoing transfer with the same condition. The abstraction we = made means >>>>>>>>> that conditions and fulfillments are already carried in the lower= levels. >>>>>>>>> >>>>>>>> >>>>>>>> That is a bad assumption that comes from the broken layering. What >>>>>>>> if my outgoing link doesn't support conditional transfers? So now = where do >>>>>>>> I put the condition? >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> We could have assumed that no ledgers ever support conditional >>>>>>>>> transfers, and said the only thing ILP gets from lower levels is = the >>>>>>>>> ability to send a transfer. But if we want to support the case wh= ere any of >>>>>>>>> them do, we have to keep the conditions and fulfillments in the l= ayer where >>>>>>>>> they're actually used. >>>>>>>>> >>>>>>>> >>>>>>>> I don't follow that logic at all. If we want to support the case >>>>>>>> where any of them do then we must ensure the condition and expiry = are >>>>>>>> always carried in a consistent place at the internetworking layer = so that >>>>>>>> if they do want to use them they know where to find them. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>>>>>>> adrian@hopebailie.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 14 August 2017 at 22:03, Evan Schwartz >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I think this thread is going to get extremely unwieldy but here >>>>>>>>>>> goes: >>>>>>>>>>> >>>>>>>>>>> > - All interledger layer messages should be ILP packets >>>>>>>>>>> (including fulfillments) and be capable of carrying higher laye= r protocol >>>>>>>>>>> payloads. >>>>>>>>>>> >>>>>>>>>>> Interledger has higher requirements than ILP for the lowest >>>>>>>>>>> layer, specifically because we are carrying money and not just = data. One of >>>>>>>>>>> the requirements is being able to transmit a 32-byte fulfillmen= t back along >>>>>>>>>>> the same path that carried the payment originally. If we expect= this of the >>>>>>>>>>> lower layer, I don't see a point in putting the fulfillment int= o an ILP >>>>>>>>>>> packet and transmitting it as Interledger data along the same p= ath. All >>>>>>>>>>> ledger-layer protocols will need to interpret the fulfillment p= assed in >>>>>>>>>>> their protocol, not the one passed through the Interledger laye= r. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is not correct. There is no requirement on ledger layer >>>>>>>>>> protocols to transmit or understand the fulfillment. You are loo= king at >>>>>>>>>> this through the lens of existing implementations from the botto= m up >>>>>>>>>> instead of starting at the interledger layer. >>>>>>>>>> >>>>>>>>>> The primary function of the condition and fulfillment is as a >>>>>>>>>> signed end-to-end receipt. If the sender agrees a condition with= a receiver >>>>>>>>>> and then gets back the valid fulfillment they don't care what ha= ppened in >>>>>>>>>> the middle. The receiver has signed a receipt saying they have t= heir money. >>>>>>>>>> >>>>>>>>>> The value of using a standard for the receipt and signature is >>>>>>>>>> that each transfer along the way CAN re-use it. One the one hand= you can >>>>>>>>>> have a transfer between two peers that have zero trust and the l= edger they >>>>>>>>>> use supports conditional payments completely. On the other extre= me you can >>>>>>>>>> have two peers that have a full trust and ignore the condition a= nd >>>>>>>>>> fulfillment completely. >>>>>>>>>> >>>>>>>>>> The ledger layer protocols carry ILP packets. Payment requests >>>>>>>>>> and either fulfillment or error responses. If a ledger layer pro= tocol wants >>>>>>>>>> to use the condition and fulfillment for their own operations th= ey can >>>>>>>>>> extract these from the ILP packets and use them. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> > - While it may make sense to split the interledger payment >>>>>>>>>>> and interledger quoting protocols into new higher level protoco= ls that >>>>>>>>>>> seems like an unnecessary abstraction. Instead the packet defin= itions >>>>>>>>>>> should just have some consistency and probably a common base/he= ader. >>>>>>>>>>> >>>>>>>>>>> The current protocols effectively have this header but it isn't >>>>>>>>>>> separated out. There are two fields in the request header: type= and >>>>>>>>>>> destination address. There is one field in the response header:= type. I >>>>>>>>>>> don't think it makes that much of a big difference to separate = these fields >>>>>>>>>>> if all of the fields in that packet need to be interpreted toge= ther (for >>>>>>>>>>> example, you can't understand a quote request if you strip off = the >>>>>>>>>>> destination address). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I agree that we don't HAVE to explicitly separate them out but I >>>>>>>>>> think ti would make it clearer how the stack is architected if t= here was a >>>>>>>>>> header that was consistent across all packets. Currently the onl= y thing >>>>>>>>>> that is consitent across all ILP packets is that they are define= d int he >>>>>>>>>> same file. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > - We should define two base ILP packet types: request and >>>>>>>>>>> response. >>>>>>>>>>> >>>>>>>>>>> Unless this adds some substantive benefit or new fields I don't >>>>>>>>>>> think it's worth breaking all of the formats we have just to re= arrange >>>>>>>>>>> things. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The goal of this exercise is to tease out the best design and >>>>>>>>>> ignore the cost of change until we can compare the results with = the current >>>>>>>>>> design. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>>>>>>> nodes/hosts. >>>>>>>>>>> >>>>>>>>>>> A ledger is any system that tracks accounts and balances. When >>>>>>>>>>> you use a trustline all of your messages still need to go throu= gh an >>>>>>>>>>> accounting system (such as the plugin in the JS implementation)= and then on >>>>>>>>>>> to the other program logic. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As above, this is incorrect. There is no requirement for "all >>>>>>>>>> messages to go through an accounting system". >>>>>>>>>> >>>>>>>>>> Since designing the first implementation of 5-bells ledger we >>>>>>>>>> have assumed that passing the ILP packet MUST be done by the led= ger because >>>>>>>>>> that is how we implemented it. But that is not true. It is perfe= ctly valid >>>>>>>>>> for the passing of an ILP packet from one peer to another to be = simply an >>>>>>>>>> exchange of data. >>>>>>>>>> >>>>>>>>>> The receiving peer makes a decision about whether or not to >>>>>>>>>> forward the packet based on the current financial position they = have with >>>>>>>>>> the sending peer. >>>>>>>>>> >>>>>>>>>> It is convenient if the ledger that records the net positions of >>>>>>>>>> the peers also forwards the messaging and even better if it nati= vely >>>>>>>>>> supports conditional payments and can use the condition and the = fulfillment >>>>>>>>>> from the ILP packet for those but that's all it is, convenient. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> In that case, the plugin or whatever is doing the accounting is >>>>>>>>>>> the ledger. Digital value is always tracked in ledgers, so I th= ink it does >>>>>>>>>>> make sense to think of this as the base layer. The reason to ab= stract the >>>>>>>>>>> functionality you expect from the ledger layer is precisely so = you can >>>>>>>>>>> handle it in different ways, depending on what the underlying s= ystems >>>>>>>>>>> provide. >>>>>>>>>>> >>>>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>>>> >>>>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities >>>>>>>>>>> and some type of HTLA >>>>>>>>>>> >>>>>>>>>>> 2. There are separate plugins for messaging and for >>>>>>>>>>> transfers and when you peer with someone you have to agree o= n a plugin for >>>>>>>>>>> each >>>>>>>>>>> 3. We standardize the messaging part and say that all goes >>>>>>>>>>> over IP and then just have more minimal plugins for the on-l= edger >>>>>>>>>>> settlements >>>>>>>>>>> >>>>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>>>> sense. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think you're confusing implementation details and defining of >>>>>>>>>> interfaces with definition of a protocol stack. The only differe= nces >>>>>>>>>> between the tree examples you have above is in implementation. >>>>>>>>>> >>>>>>>>>> From the perspective of the Interledger Protocol the >>>>>>>>>> implementation of the lower layers is not important, that's the = whole point >>>>>>>>>> of layering. By forcing important aspects of ILP like the condit= ion, >>>>>>>>>> fulfillment and expiry down into those layers you muddy the wate= rs and we >>>>>>>>>> now have to standardize those protocols too. Instead we should j= ust be >>>>>>>>>> defining the functions they must provide and then leave it up to >>>>>>>>>> implementations to provide those functions. >>>>>>>>>> >>>>>>>>>> I know we want to define a standard to bootstrap the system (CLP= ) >>>>>>>>>> but that's misleading us into thinking it's an essential part of= the stack. >>>>>>>>>> It's perfectly valid for two peers to not use CLP and still be p= art of the >>>>>>>>>> Interledger. >>>>>>>>>> >>>>>>>>>> That said, you raise an interesting consideration about the >>>>>>>>>> layers below ILP and actually I think it makes sense to split th= ese. >>>>>>>>>> >>>>>>>>>> We keep trying to force messaging through the ledger layer and >>>>>>>>>> actually that's the wrong place to put it if we can split the le= dger layer >>>>>>>>>> into a messaging layer and a ledger layer. That way we can stop = trying to >>>>>>>>>> think of all HLTAs as ledgers. >>>>>>>>>> >>>>>>>>>> A thought, why not use sub-layers as is common in other stacks: >>>>>>>>>> >>>>>>>>>> 1. Link layer: Layer upon which two peers that have a direct >>>>>>>>>> link, or participate in the same payment network, communicate >>>>>>>>>> 2. Transfer/ ledger: Layer on which financial positions between >>>>>>>>>> two peers are recorded >>>>>>>>>> >>>>>>>>>> This reflects the already emerging HTLA model and many of our >>>>>>>>>> existing plugins and ledger integrations. >>>>>>>>>> Link Layer: XRP Paychan, Lightning >>>>>>>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>>>>>>> >>>>>>>>>> This doesn't prevent us from defining a standard binary protocol >>>>>>>>>> that defines all of the operations for both layers (like CLP) bu= t I see >>>>>>>>>> value in distinguishing between these two. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > - The protocol should differentiate between the operation of >>>>>>>>>>> preparing a transfer on a ledger and the operation of passing a= n ILP packet >>>>>>>>>>> from one peer to another. >>>>>>>>>>> >>>>>>>>>>> The protocol assumes your conditional transfer is underpinned b= y >>>>>>>>>>> some HTLA >>>>>>>>>>> . >>>>>>>>>>> It doesn't care whether that's on-ledger or not. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What do you mean when you say "the protocol"? In my statement I >>>>>>>>>> am referring to ILP. >>>>>>>>>> My point above being that ILP expects ILP packets to be passed >>>>>>>>>> from peer to peer but has no expectations about transfers. >>>>>>>>>> >>>>>>>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>>>>>>> exchange ILP packets with no transfers. Clearly if a node routes= a packet >>>>>>>>>> on and has no incoming transfer it's going to lose money but tha= t's a >>>>>>>>>> consideration for that node. It doesn't affect anyone else in th= e chain. >>>>>>>>>> >>>>>>>>>> ILP doesn't assume anything about transfers at all, let alone >>>>>>>>>> conditional transfers. It provides useful semantics for conditio= nal >>>>>>>>>> transfers to be used by two peers to transact as part of a large= r ILP >>>>>>>>>> payment. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > - The condition and timeout should be included in the ILP >>>>>>>>>>> payment packet. >>>>>>>>>>> >>>>>>>>>>> I strongly disagree with this. We had this debate a year ago an= d >>>>>>>>>>> I was on your side but was convinced that this is not a good id= ea. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yes, I recall this and I'm sorry I didn't push harder on this >>>>>>>>>> point. Unfortunately I think the decision to pull it out of the = packet is >>>>>>>>>> mostly driven by how our prototypes were implemented rather than= good >>>>>>>>>> architecture. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The layer below ILP must be capable of doing conditional >>>>>>>>>>> transfers based on sha256 hashlocks with 32-byte preimages. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is not true and I think it would be useful for us to agree >>>>>>>>>> on this as this seems to be the argument I am coming up against = most often. >>>>>>>>>> The peers participating in a transfer that is part of an ILP pay= ment may >>>>>>>>>> wish to use conditional transfers as a way to enforce their agre= ement but >>>>>>>>>> this is not a requirement of the protocol. >>>>>>>>>> >>>>>>>>>> The agreement between any two peers is: "I will pay you X if you >>>>>>>>>> can provide a receipt that Y was paid Z before T". >>>>>>>>>> ILP provides a standard for expressing this agreement so that >>>>>>>>>> these can be chained together BUT it is not a requirement that e= very >>>>>>>>>> agreement in the chain uses the condition, and fulfillment provi= ded at the >>>>>>>>>> ILP layer. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As a result, the original condition and the corresponding >>>>>>>>>>> preimage MUST be expressed in that layer. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As I have shown above, this is not true. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Then the question is whether we should also include it in the >>>>>>>>>>> packet that is forwarded. What ultimately convinced me is the f= ollowing: >>>>>>>>>>> All connectors MUST ignore the condition if it is in the packet= , because >>>>>>>>>>> they are only guaranteed their money back if they use the same = condition >>>>>>>>>>> from the incoming transfer they got. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here is where the layering is being corrupted. >>>>>>>>>> >>>>>>>>>> All connectors MUST inspect the condition in the ILP packet as >>>>>>>>>> part of their decision to route the packet or not. >>>>>>>>>> When the local transfer module of the connectors stack passes th= e >>>>>>>>>> ILP packet up to the ILP module it should indicate the propertie= s of the >>>>>>>>>> incoming transfer that carried the packet. >>>>>>>>>> This is essential firstly so that the routing logic in the ILP >>>>>>>>>> module can record the incoming transfer identifier so it is able= to use the >>>>>>>>>> correct response id when it passes back the fulfillment or error= . >>>>>>>>>> The other properties that the ILP module should look at are the >>>>>>>>>> condition and expiry on the incoming transfer. >>>>>>>>>> >>>>>>>>>> If the incoming route uses conditional transfers and these are >>>>>>>>>> supposed to match the condition and expiry in the ILP packet the= n the ILP >>>>>>>>>> module should compare them and reject the packet if: >>>>>>>>>> a) the conditions don't match OR >>>>>>>>>> b) the expiry is too short >>>>>>>>>> >>>>>>>>>> We should still discuss if the expiry should be set by the sende= r >>>>>>>>>> and left unchanged or used like a TTL and decremented by each no= de. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Also, the receiver will need to take out the condition in order >>>>>>>>>>> to hash the packet for PSK or IPR. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is completely normal. Zeroing a checksum field in a header >>>>>>>>>> before calculating the checksum is VERY common precisely because= it's long >>>>>>>>>> been accepted that the right place to put that data is in the he= aders and >>>>>>>>>> the work of zero'ing it out to calculate the checksum (or signat= ure in our >>>>>>>>>> case) is not material. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> So basically, no one wants the condition in there. It feels lik= e >>>>>>>>>>> it ought to be in there, but literally none of the parties want= the extra >>>>>>>>>>> 32 bytes in there. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> "Nobody wants it there" is a terrible reason to abandon the >>>>>>>>>> correct design. The whole purpose of a good architecture is you = accept that >>>>>>>>>> there may be cases in future that haven't been considered now so= designing >>>>>>>>>> just for the known cases is a bad idea. >>>>>>>>>> >>>>>>>>>> Good architecture is not the same as optimization. Taking stuff >>>>>>>>>> out (even when it feels wrong) to save a few bytes is a good sig= n that it's >>>>>>>>>> a bad idea. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The reason the timeout should not be in there is that there >>>>>>>>>>> isn't a single timeout for the payment. There are multiple sepa= rate >>>>>>>>>>> timeouts for each of the bilateral transfers. Those must go in = the >>>>>>>>>>> individual transfers and there is no sensible value to put in t= he >>>>>>>>>>> Interledger packet. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As above, this is somewhat equivalent to the TTL in an IP packet= . >>>>>>>>>> I'm open to discussing if it should be a fixed value set by the = sender >>>>>>>>>> where each node uses their own value but has the sender-defined = value as a >>>>>>>>>> reference or it is actually decremented at each hop. >>>>>>>>>> >>>>>>>>>> Either way, this is part of ILP not the ledger layer just like >>>>>>>>>> the condition and fulfillment. It may be used by the ledger laye= r but >>>>>>>>>> that's implementation specific. It belongs in the ILP packet. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> -- >>>>>> Sent from a mobile device, please excuse any typos >>>>>> >>>>> >>>>> >>>> >>> >> > --94eb2c07cc8ea7364d05570cad59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On 18 August 2017 at 15:09, Ben Sharafian <sharafian@ripple.com= > wrote:
    What you're describing is an implementation of a = local transfer service that doesn't (or can't) take advantage of In= terledger. In fact, this will be the norm for most existing payment network= s that we want to add to the Interledger and this is where your work on pay= ment channels and HTLAs comes in to play.=C2=A0
    =C2= =A0

    If you have a local transfe= r channel that doesn't support conditions natively or supports them in = a way that requires some adaption you can create an overlay network that do= es what's needed. Example: Bitcoin is not a suitable network to use for= ILP so we use a payment channel between the peers that is underwritten by = Bitcoin.

    Exactly, when I say = you need a to handle the condition and fulfillment via a clearing layer, th= is "overlay network" is what I'm referring to. The whole poin= t of an HTLA is that from ILP's point of view it's just a lower-lev= el protocol that can commit conditional transfers and fulfill them. ILP doe= sn't care how the ledger/HTLA works under the hood, whether it's a = clearing/overlay layer or a "real" ledger.

    My point is that it goes beyond that. ILP doesn't= care if the layer below even has a concept of HTLAs. I can do ILP over Bit= coin without the overlay layer if I want to but I need to find a peer that = is prepared to do that with me.

    In that case all I have t= o do is send them the ILP packet in a message that says I owe them some Bit= coin. the "owe them some Bitcoin" isn't being enforced anywhe= re using an HTLA.
    =C2=A0

    You're equating this "overlay network,&q= uot; which is a type of ledger, with the ILP layer.

    Not at all. I agree with what you have below. It'= s a layer that exists below ILP but above the actual ledger. But crucially = it's not a requirement for ILP to work so the protocol should depend on= it existing.
    =C2=A0
    If there is an overlay network that handles the condition= and fulfillment, that means you _are_ using a ledger, because the overlay = network _is_ a ledger. The ILP layer is a layer above this.

    Agreed.

    If we assume th= e ILP packet is well defined with all the ILP-required data elements then w= hen a lower layer wants to use that data it can but should do it in a way t= hat doesn't break the ILP layer for everyone else. How that is implemen= ted in practice will depend on the lower layer protocol.

    That's one way to see it, but what I'm = wondering is why that's a better model than saying there's a clearl= y defined interface that the ledger-layer exposes, and then building the IL= P layer on top of that.

    Because that's not how you build a protocol stack. A protocol stac= k is not defined through interfaces. It's defined through layers of dat= a where each layer has a standard packet format with headers carrying data = for that layer and encapsulates the data of layer(s) above in the payload.<= br>
    The condition, fulfillment and expiry are par= t of ILP so they belong in the ILP packet. If there are lower layers that w= ant to use those things then they can but ILP shouldn't depend on that.=
    =C2=A0

    =
    Unless the next hop is backwards

    =
    There's no reason to send a backwards hop. If you don't= want to forward a payment you reject it.

    =
    That's what I mean by a backwards hop. I was illustrating my= point that validating a packet is part of the routing decision.
    <= div>=C2=A0

    Not at all. You're assuming that there is = no expiry on the local transfer. As a receiving node I have an incoming tra= nsfer with an expiry and it carries an ILP packet that also has an expiry.<= /span>

    If that's what you're= talking about, the ILP packet already has an expiry. It's implemented = in the PSK details so the receiver knows whether the packet it issued is st= ill valid. But that's an application layer concern, because it's on= ly the receiver who looks at the ILP packet's expiry. The connectors on= ly need to know the expiries of the local transfers.

    There is a big misconception in your statement. The expiry= is an end-to-end concern, or as you put it the sender sets and "the r= eceiver looks at the ILP packet's expiry". That's why it's= in the ILP packet.

    The idea that anything to be ex= changed end-to-end must be in higher layers is completely wrong. The reason= you'd put something in a higher layer payload is because the endpoints= have agreed to use a higher layer protocol that requires it to be there.

    On Fri, Aug 18, 2017 at 3:21 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    On 18 August 2017 at 10:38, Ben Sharafian &= lt;sharafian@ripp= le.com> wrote:
    Two connectors exchanging a transfer only care about the= data that is relevant to them for that transfer. It's quite possible f= or two connectors to perform a transfer that has no conditions or fulfillme= nts or a transfer that has a different condition and fulfillment (such as a= n atomic mode transfer where the condition is a compound one that has multi= ple sub-conditions).

    Yes, two= connectors could absolutely send an unconditional transfer on an underlyin= g ledger in order to settle an Interledger payment. But in order to benefit= from any of Interledger's guarantees (trustless connectors, retry-abil= ity, etc.), they MUST keep a conditional local transfer, at least for clear= ing. If the local transfer cannot time out, it cannot be safely retried. If= the local transfer clears without a fulfillment, it loses the "receip= t or your money back" property. Yes, two parties in the chain could es= chew these benefits but that is no longer a correct implementation of Inter= ledger.

    Aha! That is whe= re I disagree! Interledger is not implemented at the local transfer layer, = it is implemented at the Interledger layer. The whole point is that it an I= nterledger payment can travel over payment networks that know nothing about= ILP but the greatest value comes from using ones that do.

    What you&= #39;re describing is an implementation of a local transfer service that doe= sn't (or can't) take advantage of Interledger. In fact, this will b= e the norm for most existing payment networks that we want to add to the In= terledger and this is where your work on payment channels and HTLAs comes i= n to play.

    If you have a local transfer channel that doesn't su= pport conditions natively or supports them in a way that requires some adap= tion you can create an overlay network that does what's needed. Example= : Bitcoin is not a suitable network to use for ILP so we use a payment chan= nel between the peers that is underwritten by Bitcoin.
    = =C2=A0

    =
    If a protocol at a lower layer wants to use that data then it= must replicate it. That seems inefficient but it's the correct way to = do it.

    What's the actual = reasoning behind this, and why is it considered the correct approach? If th= ere's some IETF document that says this I'd like to see it, because= it intuitively feels wrong to have lower level abstractions looking into h= igher levels.

    The data i= n the ILP layer is there for a specific reason. It's part of an end-to-= end exchange between the sender and receiver.

    Side note: It's= unusual to be designing the whole stack at once so we keep being tempted t= o move things around but in reality we should look at the ILP layer in isol= ation and make sure it is complete. Alternatively we should try to test our= design against a number of lower and upper layer protocols to make sure ou= r thinking is sound.

    If we assume the ILP packet is well defined= with all the ILP-required data elements then when a lower layer wants to u= se that data it can but should do it in a way that doesn't break the IL= P layer for everyone else. How that is implemented in practice will depend = on the lower layer protocol.
    =C2=A0

    Routing requires looki= ng at the condition, expiry and amount. A connector's routing logic sho= uldn't forward a packet if the expiry is too low or if the condition is= obviously corrupted.

    Those a= re validity checks and you're right that they are performed in the conn= ector, but the destination account, destination amount, and data are enough= to figure out what the best next hop is.

    =
    Unless the next hop is backwards
    =C2= =A0

    The ILP Packet's purpose is to describe where a payment is going.

    Not only that. For compari= son, an IP packet does a lot more than just describe where a packet is goin= g. All end-to-end concerns need to be in there too.
    =C2= =A0
    The data it c= arries is only for the purpose of making sure the receiver can identify tha= t payment.

    No, the cond= ition is there so the receiver can ensure it is sending back the correct fu= lfillment and the expiry to give the receiver some assurance that the packe= t is still worth processing.
    =C2=A0
    In that context, the expiry has no b= earing on where it will be routed nor on how much to route, only on whether= or not an individual connector will take the risk of forwarding it.
    <= span>

    The ILP packet just contains the end-to-end con= dition (always a SHA-256 hash) and then the local transfer can have a diffe= rent condition that is derived from the condition in the ILP packet.=

    Fair enough; in your case you can t= ransmit the condition twice and verify the structure of the complex local c= ondition, and in the no-condition-in-ILP version you can verify the structu= re of the local condition and extract the SHA256 condition to pass on.

    If an attacker knows enough a= bout latency in the chain, they could even target this attack at somebody m= any hops away. Staggering expiries (giving you a minimum amount of time to = fulfill a source transfer) is an easy mitigation against this attack; we sh= ouldn't take it out.

    I agree. We would still have the local expiry.
    <= div class=3D"m_-2264255804784666760h5">
    =C2=A0

    Comparing the condition in the = local transfer and the one in the ILP packet should be part of the routing = logic.

    Sure, it can be done a= s an extra validity check, but it's just more code and more attack surf= ace.=C2=A0I still don't see any tangib= le benefit from doing the layering in this way, aside from your assertion t= hat it's the correct way to do it. If you've read any documents tha= t explain why this is the correct way to do layering, I think I'd under= stand you better.


    On Thu, Aug 1= 7, 2017 at 7:32 PM, Adrian Hope-Bailie <adrian@hopebailie.com><= /span> wrote:


    On 16 August 2017= at 10:22, Ben Sharafian <sharafian@ripple.com> wrote:
    OK, I think in that = case we're mostly disagreeing over where the condition/fulfillment/expi= ry actually go in the data.

    That's one way to look at it but that's ultimately wha= t the architecting the layering is. Deciding at which layer (and therefor e= ncapsulated in what packet) certain data should be.
    =C2= =A0
    The reason I= don't agree with your position is based on which parties I think shoul= d be aware of ILP.

    <= div>I don't think that's the right way to look at it. The connector= needs to be able to understand at least the ILP layer data AND the lower l= ayer data. Normally the way the processing stack is implemented is that the= re is a module for each layer that processes the data from that layer and t= hen passes the payload and any other important information up to the next l= ayer.
    =C2=A0
    In order to track the balance between each other ac= curately, the two connectors have to keep track of conditions, fulfillments= , and expiries on each of the transfers.
    This is where I disagree with you. Two connectors exchan= ging a transfer only care about the data that is relevant to them for that = transfer. It's quite possible for two connectors to perform a transfer = that has no conditions or fulfillments or a transfer that has a different c= ondition and fulfillment (such as an atomic mode transfer where the conditi= on is a compound one that has multiple sub-conditions).
    =C2=A0
    That mean= s the connectors' accounting logic that handles the conditions, fulfill= ments, and expiries is going to be using some information inside the ILP pa= cket and some information outside of it in order to perform these transfers= .

    It will only us= e info inside the packet if it uses conditional transfers that use that sam= e condition. This is the most likely scenario but that is not a protocol re= quirement.
    =C2=A0
    <= span class=3D"m_-2264255804784666760m_1380112361502110193m_-459247486030013= 2566m_-291143135448144913im m_-2264255804784666760m_1380112361502110193m_-4= 592474860300132566m_-291143135448144913HOEnZb">

    I think it&= #39;s cleaner to say everything required to make these local transfers shou= ld go in one protocol, so the accounting logic of these connectors doesn= 9;t have to deal with ILP directly.
    I strongly disagree with that. That's entirely the = wrong reason to put data into a specific layer. The data in the ILP layer i= s there because it's "end-to-end" data.

    If = a protocol at a lower layer wants to use that data then it must replicate i= t. That seems inefficient but it's the correct way to do it.

    One could define a lower layer protocol that doesn't replicate = the data but the rules of the protocol are "Get the condition from the= ILP packet". In that case, that specific lower level protocol is forc= ing implementations to understand the ILP packet format, that's an impl= ementation detail.

    Another lower layer protocol might tak= e the condition from the ILP packet and re-encode it in a different form (l= ike a base64ulr string or NI: uri)
    =C2=A0
    Then the connectors' ILP-p= acket-related behavior can all be routing related.

    Routing requires looking at the conditio= n, expiry and amount. A connector's routing logic shouldn't forward= a packet if the expiry is too low or if the condition is obviously corrupt= ed.

    If the protocols were designed correctly as I am prop= osing then another routing decision would be, is the condition that was use= d in the incoming transfer the same as the one used in the ILP packet?
    =

    =C2=A0
    =
    This would add a few benefits; two connectors could p= erform non-ILP conditional transfers between one another (which would be us= eful for reconciliation and settlement), and could also allow two connector= s to use more complex condition types (i.e. signatures for atomic mode) wit= hout forcing us to support that in the ILP packet.

    You seem to have this backwards. Both of= these things are supported if the condition and expiry ARE in the ILP pack= et. Atomic mode is not supported in the ILP protocol it is supported in the= lower layer transfer protocol. The ILP packet just contains the end-to-end= condition (always a SHA-256 hash) and then the local transfer can have a d= ifferent condition that is derived from the condition in the ILP packet.
    =C2=A0
    It also keeps the integrity of the ILP packet as something lower le= vels don't modify; the connector has to modify the expiry in order to p= ass along an ILP payment (they may not modify the expiry if they're usi= ng something like atomic mode, but then we have the issue with advanced con= dition types not being supported in the ILP packet).

    I think the expiry should always be the expi= ry set by the sender. It won't be changed.

    In the case where the ledger _does_ care= about the condition and fulfillment, the argument in favor of separating c= ondition/fulfillment/expiry from the rest of the packet is similar. Because= we don't control the features of all ledgers, we'll need our plugi= ns or ledger adapters to be aware of ILP. This makes it hard to interact wi= th any events that don't involve ILP packets, and impossible to handle = features that extend beyond what we support in the ILP packet. We could pas= s details about non-ILP ledger features (like a crypto condition) in the si= de data, but in the event of any redundancy we have to check the ledger-sup= plied info, not the info in the ILP packet.
    =

    Comparing the condition in the local transfer an= d the one in the ILP packet should be part of the routing logic.
    <= span>
    =C2=A0
    =
    Basically, condition/fulfillment/= expiry are used for accounting local transfers (even if they aren't bei= ng "ledger" enforced) in addition to their role as every-hop info= rmation. By putting them in the ILP packet, we limit the special features t= hat ledgers can support and make our software abstractions harder to separa= te cleanly. By putting them in the local transfer alongside the ILP packet = but not inside it, we do separate the data a little more, but we have more = freedom in what the underlying accounting and ledger logic can do, and our = software modules will have more clearly separated domains.

    They should be in both the local = transfer AND the ILP packet if they are needed by the local transfer protoc= ol. This allows the flexibility you desire because the local transfer proto= col can do ANYTHING including using the condition from the ILP packet as-is= , not at all or enhanced for something like atomic mode.

    =C2=A0

    <= div class=3D"gmail_quote">On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bai= lie <adrian@hopebailie.com> wrote:
    Exactly =F0=9F=91=8D

    =
    On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian <sharafian@ripple.com> wrote:
    Ok, I think I have a better ide= a of what you're saying.

    It sounds like you're s= aying the ILP layer contains all information that is common between every h= op (destination, destination amount, opaque data, condition, fulfillment, e= xpiry). The lower level would then be used for all the transfer-local detai= ls (source amount, next connector account, custom/local data).
    If the lower level wanted to do anything related to the every-= hop payment, i.e. escrow funds until the receipt has been produced, it woul= d look into the ILP layer for that information. If the lower level didn'= ;t do any escrow or expiries that require every-hop details, it would simpl= y function as a communication method.

    Is that righ= t?

    On = Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    On 15 August 2017 at 16:00, Ben= Sharafian <sharafian@ripple.com> wrote:
    <= span class=3D"m_-2264255804784666760m_1380112361502110193m_-459247486030013= 2566m_-291143135448144913m_7485895676561816267m_-6097996964176105341m_13109= 73367067486614m_2848463475820566235gmail-m_-8826841552502228180gmail-im" st= yle=3D"font-size:12.8px">
    =
    In that case, the plugin or whatever is doing= the accounting is the ledger. Digital value is always tracked in ledgers, = so I think it does make sense to think of this as the base layer. The reaso= n to abstract the functionality you expect from the ledger layer is precise= ly so you can handle it in different ways, depending on what the underlying= systems provide.
    I see 3 ways to think of the layer(s) underpi= nning ILP:
    1. The "Led= ger Layer" provides both messaging capabilities and some type of=C2=A0= HTLA<= /a>
    1. There are separate p= lugins for messaging and for transfers and when you peer with someone you h= ave to agree on a plugin for each
    1. We standardize the messaging part and say that all goes over IP and then= just have more minimal plugins for the on-ledger settlements
    Numb= er 1 is what we have and I think that still makes the most sense.

    I think you're confusing imple= mentation details and defining of interfaces with definition of a protocol = stack. The only differences between the tree examples you have above is in = implementation.



    Because of this, within lower-layer protocols that offer the basic reques= t/response features we need, we could add conditional payment semantics tha= t use the condition, expiry and fulfillment provided by ILP. This would all= ow a node to offer a reward to=C2=A0 their next peer to for delivering the = packet they send them and to make the local financial transaction contingen= t on the end-to-end transaction.

    =C2=A0
    The proposal that you're arguing for is basically = asserting that we're going to be using CLP, because it makes the assump= tion that the connectors (who understand ILP) are managing the HTLA logic.<= /div>

    Not at all. I am asserti= ng that it doesn't matter what protocol you use below the ILP layer bec= ause it shouldn't matter. All of this talk about ILP being different be= cause money is more important than data is nonsense.

    The diffe= rence between ILP and IP that makes ILP suitable for value transfer and IP = not is at the internetworking layer. ILP requires that all packets are eith= er a request or response and that the responses follow the same path as the= requests. Further ILP defines a signature scheme that gives the sender a w= ay to be certain the request was received by the receiver.

    This could be done entirely without money bu= t then there would be little incentive to sign the receipt or deliver the s= ignature back to the original sender.

    So, if you add money then you add economic incentives to the mix. At eac= h hop the sender promises the next upstream peer a payment if they can retu= rn the receipt. The net effect is that this can be used to transfer money f= rom the sender to the receiver by simply defining up front the amount that = the receiver must get to produce the signature.
    =C2=A0

    In the current mo= del, the CLP/trustline model and the direct ledger model both work without = having to treat anything on the ILP layer differently. We're favoring o= n-ledger messaging because of our implementation, yes, but we've been a= ble to switch most all of our plugins from on-ledger messaging to RPC-based= messaging without changing the ILP layer at all.

    = With the ledger-level abstraction, we were able to switch from our ledger-b= ased mode of thinking to the CLP/trustline based way without changing anyth= ing other than the plugin. Your argument comes from an assumption of a CLP-= style ledger protocol with some underlying ledger, which we can't assum= e is always the case.

    I'm= not sure what any of that proves tbh. These are all implementation concern= s. They don't change the fact that the condition, expiry and fulfillmen= t are part of ILP not the lower layer protocols.
    =C2=A0

    From = the perspective of the Interledger Protocol the implementation of the lower= layers is not important, that's the whole point of layering. By forcin= g important aspects of ILP like the condition, fulfillment and expiry down = into those layers you muddy the waters and we now have to standardize those= protocols too. Instead we should just be defining the functions they must = provide and then leave it up to implementations to provide those functions.=

    I don't agree with this = point; the condition and fulfillment have actual meaning to the ledger laye= r.

    =C2=A0
    You've said that the ledg= er often doesn't care about fulfillment and condition, but the ledger _= layer_'s (where transfers are done) role is to take in condition and fu= lfillment and make a transfer which satisfies its HTLA.

    No, the ledger's role is to keep a tab of n= et financial positions between two peers. It MAY use conditions and fulfill= ments that it pulls from the ILP layer to help it do that in a way both pee= rs agree on.

    Note that a "laye= r" doesn't have a role. I think there is some confusion about the = difference between layering the protocol and abstracting functionality into= different components.
    =C2=A0
    =
    If the ledger layer has to look into the ILP packet to do= so, that is a blatant breaking of layering.
    =
    Not at all! The module acting at the layers below<= /b> the internetworking layer shouldn't modify anything inside the pack= ets of the higher layers but they can definitely inspect them and adjust th= eir behavior based on what they to find.

    In fact the prevalenc= e of this is the subject of a lot of debate at the IETF currently because e= ndpoints are often encrypting their payloads and in some cases this makes i= t difficult for middle-boxes to be effective at their jobs.

    By putting the condition, fulfillment, and expiry on the le= dger layer, we leave it open for any ledger type to work, rather than forci= ng all ledger-layer software to understand ILP.


    ILP doesn't def= ine how anything is chained together. From the perspective of ILP the condi= tion and fulfillment are end-to-end data. They are agreed by the two endpoi= nts who don't care how they get from Alice to Bob and back.

    The design of ILP is such that it facilitates the design of lower le= vel protocols that can be used to carry the ILP packets across multiple hop= s (networks) using economic incentives such that the sender pays enough for= the first hop to ensure that all nodes in between can extract the fee they= want and the receiver will still get the amount they expected..

    =C2=A0
    ILP says you should send your outgoing transfer with the same co= ndition as the incoming one, and a lower expiry.
    <= div>
    No it doesn't. An internetworking protocol ca= n't prescribe that kind of thing to lower level protocols. An incoming = and outgoing transfer could be sent using completely different protocols an= d the financial agreement with the peers on those two routes could be vastl= y different too.

    The only service ILP requires of lower level protoc= ols is that they can map a response to an original request. This requiremen= t is okay because it is isolated to a single route/link at a time not a req= uirement that crosses the inter-network boundary that ILP crosses.
    =C2=A0
    <= div>
    But because ILP allows for many different types of ledgers, it doe= sn't make sense to assert how these are encoded.

    By putting them in the ILP packet you do the o= pposite. You make no assertions about how they are encoded if they are used= at lower layers, or how they may be combined with other conditions or even= used to derive new conditions.

    IP doesn't tell you how = to encode an ethernet packet. It doesn't even know whether it's goi= ng over a computer or a hand-written letter carried by a pigeon. IP takes f= or granted that you can send data over one connection by putting it in a lo= wer level.

    Correct, but= if a link layer protocol wanted to look into the IP packet headers of a pa= cket it wants to transfer and use some data from there in its internal logi= c (or even reuse data in it's own frame) that would be totally fine.
    =C2=A0
    Even though IP tells you how to chain these connections toge= ther, it doesn't have to put the things it's chaining on the intern= etworking level.

    IP doe= sn't tell you how to chain things together. IP simply defines the end-t= o end data envelope and address space. Because of this nodes that implement= the multiple lower layer protocols are able to push IP packets down a link= and expect the node on the other side to understand the headers and route = it onward on another link.

    Everything needed by the IP mo= dule to decide what to do with the packet is in the IP packet headers. i.e.= Has it exceeded a TTL? Is there a route for this destination? Is it corrup= ted (checksum fails)? But also, everything that is needed by the endpoint (= like the source address) is also in there.

    There is no de= pendency on nodes to be good citizens and always pass certain other data fr= om the lower layers into the next link. That would be breaking the layering= .
    =C2=A0
    IP also assumes that if you get some incoming data on = a connection you can copy it and send it out on the next connection. Becaus= e you can already send data over a connection, all IP adds is the missing p= iece: a packet that tells you where to go.

    With IL= P, we assume that there is a way to prepare a conditional transfer, expire = a conditional transfer, and fulfill a conditional transfer.

    No we don't! We assume that if we = deliver the packet as intended we'll get back a response packet with a = signature that matches the condition in the packet. So, if we have an agree= ment with someone that they will pay us when we present that signature then= we are prepared to enter a similar agreement with the next peer because we= expect that signature to come all the way back along the interledger layer= route..
    =C2=A0
    We also assume that if you get an incoming transf= er you can create an outgoing transfer with the same condition. The abstrac= tion we made means that conditions and fulfillments are already carried in = the lower levels.

    That i= s a bad assumption that comes from the broken layering. What if my outgoing= link doesn't support conditional transfers? So now where do I put the = condition?
    =C2=A0

    We could have assumed that no ledgers ever = support conditional transfers, and said the only thing ILP gets from lower = levels is the ability to send a transfer. But if we want to support the cas= e where any of them do, we have to keep the conditions and fulfillments in = the layer where they're actually used.
    I don't follow that logic at all. If we want to supp= ort the case where any of them do then we must ensure the condition and exp= iry are always carried in a consistent place at the internetworking layer s= o that if they do want to use them they know where to find them.
    <= div>
    =C2=A0

    On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie <adrian@hop= ebailie.com> wrote:


    On 14 August 2017 at 22:03, Evan Schwartz <evan@ripple.com> wrot= e:
    I think this t= hread is going to get extremely unwieldy but here goes:

    >=C2=A0- All interledger layer= messages should be ILP packets (including fulfillments) and be capable of = carrying higher layer protocol payloads.

    =
    Interledger has higher requirements than ILP for the lowest layer, spe= cifically because we are carrying money and not just data. One of the requi= rements is being able to transmit a 32-byte fulfillment back along the same= path that carried the payment originally. If we expect this of the lower l= ayer, I don't see a point in putting the fulfillment into an ILP packet= and transmitting it as Interledger data along the same path. All ledger-la= yer protocols will need to interpret the fulfillment passed in their protoc= ol, not the one passed through the Interledger layer.

    This is not correct. There is no requirement on le= dger layer protocols to transmit or understand the fulfillment. You are loo= king at this through the lens of existing implementations from the bottom u= p instead of starting at the interledger layer.

    The primary function of the condition and fulfillment is as a= signed end-to-end receipt. If the sender agrees a condition with a receive= r and then gets back the valid fulfillment they don't care what happene= d in the middle. The receiver has signed a receipt saying they have their m= oney.

    The value of using a standard= for the receipt and signature is that each transfer along the way CAN re-u= se it. One the one hand you can have a transfer between two peers that have= zero trust and the ledger they use supports conditional payments completel= y. On the other extreme you can have two peers that have a full trust and i= gnore the condition and fulfillment completely.
    =C2=A0
    The ledger layer protocols carry ILP packets. Paym= ent requests and either fulfillment or error responses. If a ledger layer p= rotocol wants to use the condition and fulfillment for their own operations= they can extract these from the ILP packets and use them.


    >=C2=A0<= span style=3D"color:rgb(33,33,33)">- While it may make sense to split the i= nterledger payment and interledger quoting protocols into new higher level = protocols that seems like an unnecessary abstraction. Instead the packet de= finitions should just have some consistency and probably a common base/head= er.

    <= /span>
    The current protocols effect= ively have this header but it isn't separated out. There are two fields= in the request header: type and destination address. There is one field in= the response header: type. I don't think it makes that much of a big d= ifference to separate these fields if all of the fields in that packet need= to be interpreted together (for example, you can't understand a quote = request if you strip off the destination address).

    I agree that we don't HAVE to explici= tly separate them out but I think ti would make it clearer how the stack is= architected if there was a header that was consistent across all packets. = Currently the only thing that is consitent across all ILP packets is that t= hey are defined int he same file.
    =C2=A0

    >=C2=A0- We should define tw= o base ILP packet types: request and response.

    Unless this= adds some substantive benefit or new fields I don't think it's wor= th breaking all of the formats we have just to rearrange things.

    The goal of this exercise is to te= ase out the best design and ignore the cost of change until we can compare = the results with the current design.
    =C2=A0

    = >=C2=A0- ILP is not about ledgers, i= t is about trustlines between nodes/hosts.

    A ledger is any system that tracks accounts and b= alances. When you use a trustline all of your messages still need to go thr= ough an accounting system (such as the plugin in the JS implementation) and= then on to the other program logic.

    As above, this is incorrect. There is no requirement for &quo= t;all messages to go through an accounting system".

    = Since designing the first implementation of 5-bells ledger we have assumed = that passing the ILP packet MUST be done by the ledger because that is how = we implemented it. But that is not true. It is perfectly valid for the pass= ing of an ILP packet from one peer to another to be simply an exchange of d= ata.

    The receiving peer makes a decision about whether or= not to forward the packet based on the current financial position they hav= e with the sending peer.

    It is convenient if t= he ledger that records the net positions of the peers also forwards the mes= saging and even better if it natively supports conditional payments and can= use the condition and the fulfillment from the ILP packet for those but th= at's all it is, convenient.

    =C2=A0
    In that case, the plug= in or whatever is doing the accounting is the ledger. Digital value is alwa= ys tracked in ledgers, so I think it does make sense to think of this as th= e base layer. The reason to abstract the functionality you expect from the = ledger layer is precisely so you can handle it in different ways, depending= on what the underlying systems provide.

    I see 3 w= ays to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messaging capabilities an= d some type of HTLA
    2. There are separate plugins for messagin= g and for transfers and when you peer with someone you have to agree on a p= lugin for each
    3. We standardize the messaging part and say that all g= oes over IP and then just have more minimal plugins for the on-ledger settl= ements
    Number 1 is what we have and I think that still makes = the most sense.

    I think you're= confusing implementation details and defining of interfaces with definitio= n of a protocol stack. The only differences between the tree examples you h= ave above is in implementation.

    From the perspective of the Interled= ger Protocol the implementation of the lower layers is not important, that&= #39;s the whole point of layering. By forcing important aspects of ILP like= the condition, fulfillment and expiry down into those layers you muddy the= waters and we now have to standardize those protocols too. Instead we shou= ld just be defining the functions they must provide and then leave it up to= implementations to provide those functions.

    I know we want to define a standard to bootstrap the system (CLP)= but that's misleading us into thinking it's an essential part of t= he stack. It's perfectly valid for two peers to not use CLP and still b= e part of the Interledger.

    That said, you raise an interesting considera= tion about the layers below ILP and actually I think it makes sense to spli= t these.

    We keep trying to force messaging through the le= dger layer and actually that's the wrong place to put it if we can spli= t the ledger layer into a messaging layer and a ledger layer. That way we c= an stop trying to think of all HLTAs as ledgers.

    A though= t, why not use sub-layers as is common in other stacks:

    1= . Link layer: Layer upon which two peers that have a direct link, or partic= ipate in the same payment network, communicate
    2. Transfer/ l= edger: Layer on which financial positions between two peers are recorded
    This reflects the already emerging HTLA model and many of our existing= plugins and ledger integrations.
    Link Layer: XRP Paychan, Li= ghtning
    Ledger Layer: XRP Ledger, Bitcoin

    <= /div>
    This doesn't prevent us from defining a standard binary proto= col that defines all of the operations for both layers (like CLP) but I see= value in distinguishing between these two.
    =C2=A0

    >=C2=A0- The protocol should = differentiate between the operation of preparing a transfer on a ledger and= the operation of passing an ILP packet from one peer to another.
    The protocol assumes your = conditional transfer is underpinned by some HTLA. It doesn't care whethe= r that's on-ledger or not.

    What do you mean when you say "the protocol"? In my statement I= am referring to ILP.
    My point above being that ILP expects ILP packets= to be passed from peer to peer but has no expectations about transfers.
    It's perfectly legal (from an ILP= perspective) for two peers to exchange ILP packets with no transfers. Clea= rly if a node routes a packet on and has no incoming transfer it's goin= g to lose money but that's a consideration for that node. It doesn'= t affect anyone else in the chain.

    = ILP doesn't assume anything about transfers at all, let alone condition= al transfers. It provides useful semantics for conditional transfers to be = used by two peers to transact as part of a larger ILP payment.
    =C2=A0

    >=C2=A0- The condition and timeout should be included in the ILP = payment packet.

    I strongly disagree = with this. We had this debate a year ago and I was on your side but was con= vinced that this is not a good idea.

    Yes, I recall this and I'm sorry I didn't push harder = on this point. Unfortunately I think the decision to pull it out of the pac= ket is mostly driven by how our prototypes were implemented rather than goo= d architecture.

    The layer below ILP must be capable of doing= conditional transfers based on sha256 hashlocks with 32-byte preimages.

    This is not true and I th= ink it would be useful for us to agree on this as this seems to be the argu= ment I am coming up against most often. The peers participating in a transf= er that is part of an ILP payment may wish to use conditional transfers as = a way to enforce their agreement but this is not a requirement of the proto= col.

    The agreement between any two peers is: "I will= pay you X if you can provide a receipt that Y was paid Z before T".
    ILP provides a standard for expressing this agreement so that = these can be chained together BUT it is not a requirement that every agreem= ent in the chain uses the condition, and fulfillment provided at the ILP la= yer.

    =C2=A0
    As a result, the original condition and the corresponding pr= eimage MUST be expressed in that layer.

    <= /div>
    As I have shown above, this is not true.
    =C2=A0
    = Then the question is whether we should also include it in the packet that i= s forwarded. What ultimately convinced me is the following: All connectors = MUST ignore the condition if it is in the packet, because they are only gua= ranteed their money back if they use the same condition from the incoming t= ransfer they got.

    Here is where the layering is being corrupted.

    All = connectors MUST inspect the condition in the ILP packet as part of their de= cision to route the packet or not.
    When= the local transfer module of the connectors stack passes the ILP packet up= to the ILP module it should indicate the properties of the incoming transf= er that carried the packet.
    This is ess= ential firstly so that the routing logic in the ILP module can record the i= ncoming transfer identifier so it is able to use the correct response id wh= en it passes back the fulfillment or error.
    The other properties that th= e ILP module should look at are the condition and expiry on the incoming tr= ansfer.

    If the inco= ming route uses conditional transfers and these are supposed to match the c= ondition and expiry in the ILP packet then the ILP module should compare th= em and reject the packet if:
    a) the conditions don't matc= h OR
    b) the expiry is too short

    We should s= till discuss if the expiry should be set by the sender and left unchanged o= r used like a TTL and decremented by each node.
    =C2=A0<= /div>
    Also, the = receiver will need to take out the condition in order to hash the packet fo= r PSK or IPR.

    This is c= ompletely normal. Zeroing a checksum field in a header before calculating t= he checksum is VERY common precisely because it's long been accepted th= at the right place to put that data is in the headers and the work of zero&= #39;ing it out to calculate the checksum (or signature in our case) is not = material.
    =C2=A0
    So basically, no one wants the condition in ther= e. It feels like it ought to be in there, but literally none of the parties= want the extra 32 bytes in there.

    <= /span>
    "Nobody wants it there" is a terrible reason to abando= n the correct design. The whole purpose of a good architecture is you accep= t that there may be cases in future that haven't been considered now so= designing just for the known cases is a bad idea.

    Good a= rchitecture is not the same as optimization. Taking stuff out (even when it= feels wrong) to save a few bytes is a good sign that it's a bad idea.<= br>
    =C2=A0

    The reason the timeout should not be in the= re is that there isn't a single timeout for the payment. There are mult= iple separate timeouts for each of the bilateral transfers. Those must go i= n the individual transfers and there is no sensible value to put in the Int= erledger packet.
    =C2=A0
    As ab= ove, this is somewhat equivalent to the TTL in an IP packet. I'm open t= o discussing if it should be a fixed value set by the sender where each nod= e uses their own value but has the sender-defined value as a reference or i= t is actually decremented at each hop.

    Either way, this i= s part of ILP not the ledger layer just like the condition and fulfillment.= It may be used by the ledger layer but that's implementation specific.= It belongs in the ILP packet.
    =C2=A0

    <= /span>




    --
    Sent from a mobile device, please = excuse any typos






    --94eb2c07cc8ea7364d05570cad59-- From nobody Fri Aug 18 13:10:53 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E11D132320 for ; Fri, 18 Aug 2017 13:10:51 -0700 (PDT) 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 RmGIkY6nG76H for ; Fri, 18 Aug 2017 13:10:45 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 6B02E1320BB for ; Fri, 18 Aug 2017 13:10:45 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id v29so59397305qtv.3 for ; Fri, 18 Aug 2017 13:10:45 -0700 (PDT) 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=61oqg/0rDbP5sfEbuDIabz/UAS+dP6hsGRvmMRcrFyY=; b=WPj4TrDGrYPTRQbuRsDPWXCliS/akgu5oPyelgIIxNUA2dtCNaAU39BNJ69f6gMrzB oV5+2mknBsU49MCoZDZ4peX8x8LSkZo3C64MPclo6fC3eDGwU610QlLd4FnnMfboG6wq D1ZhCoGzSjvYj9VgSFrM8vKuYgnYC+Nqe6bbbRxe6TjnbmIqGs135HN1idlJjjnvEaoL 91xftXIq7gwC23h88wBcc44tQ/EsZSxnY5IESwZti+4gST2bqhHde1uz5RKxCICWaKG8 k6PS9Lf1kPVkrATZhGYGkrLInWZlfMsajOFMTX0aBojYZVgpAJpeBVC+/H5bkhbKh+hi pzZw== 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=61oqg/0rDbP5sfEbuDIabz/UAS+dP6hsGRvmMRcrFyY=; b=geGKe1ISMnPRtCgh5iAEPO6iMW7b2X6Y+N3cg1PtBAIh5jqqwv/rDOA+znADdSixE2 LqK+ADf4J601dzxnO53+9wJDPRSUNYhTF29VQrtOYi0Mq4rpx+zR9Xwanv2eE90pqR+A ySMJm9VgO+L4o4LqOZxjZCHBNBry96Zimd9IAyCiY8Bv4/gjsjUbxi37KE19PA+kvKUv anAxPVnOa4LHqYDlNuSz1qQ+UIMa+5EFdCNNYmbFQBrUW9ceg48mw52RaRJSMi/kmhph LhPtXek+1ie0/BOhLoukXcpQDeMYERVwMZYI1ZRikhqnfC2OXUlV6fRuD0cRG5uNq+d3 qKyg== X-Gm-Message-State: AHYfb5jOoFeEr2ryO5W21Ix5yadALZkdxDBI3SVKJJQQid4TxB1JdjQa I67VsQN2SvwGjOsbiQq3T3vCxl9xTg== X-Received: by 10.237.56.228 with SMTP id k91mr13703201qte.146.1503087044309; Fri, 18 Aug 2017 13:10:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.145.100 with HTTP; Fri, 18 Aug 2017 13:10:43 -0700 (PDT) In-Reply-To: References: From: Andrew Bransford Brown Date: Fri, 18 Aug 2017 16:10:43 -0400 Message-ID: To: Adrian Hope-Bailie Cc: Ben Sharafian , Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1142c36a57b8f405570cb9f6" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 20:10:52 -0000 --001a1142c36a57b8f405570cb9f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the human species survives, they'll say humans nearly went extinct, because some liked to keep secrets (top secret, secret, classified). On Thu, Aug 17, 2017 at 1:32 PM, Adrian Hope-Bailie wrote: > > > On 16 August 2017 at 10:22, Ben Sharafian wrote: > >> OK, I think in that case we're mostly disagreeing over where the >> condition/fulfillment/expiry actually go in the data. >> > > That's one way to look at it but that's ultimately what the architecting > the layering is. Deciding at which layer (and therefor encapsulated in wh= at > packet) certain data should be. > > >> The reason I don't agree with your position is based on which parties I >> think should be aware of ILP. >> > > I don't think that's the right way to look at it. The connector needs to > be able to understand at least the ILP layer data AND the lower layer dat= a. > Normally the way the processing stack is implemented is that there is a > module for each layer that processes the data from that layer and then > passes the payload and any other important information up to the next lay= er. > > >> In order to track the balance between each other accurately, the two >> connectors have to keep track of conditions, fulfillments, and expiries = on >> each of the transfers. >> > > This is where I disagree with you. Two connectors exchanging a transfer > only care about the data that is relevant to them for that transfer. It's > quite possible for two connectors to perform a transfer that has no > conditions or fulfillments or a transfer that has a different condition a= nd > fulfillment (such as an atomic mode transfer where the condition is a > compound one that has multiple sub-conditions). > > >> That means the connectors' accounting logic that handles the conditions, >> fulfillments, and expiries is going to be using some information inside = the >> ILP packet and some information outside of it in order to perform these >> transfers. >> > > It will only use info inside the packet if it uses conditional transfers > that use that same condition. This is the most likely scenario but that i= s > not a protocol requirement. > > >> >> I think it's cleaner to say everything required to make these local >> transfers should go in one protocol, so the accounting logic of these >> connectors doesn't have to deal with ILP directly. >> > > I strongly disagree with that. That's entirely the wrong reason to put > data into a specific layer. The data in the ILP layer is there because it= 's > "end-to-end" data. > > If a protocol at a lower layer wants to use that data then it must > replicate it. That seems inefficient but it's the correct way to do it. > > One could define a lower layer protocol that doesn't replicate the data > but the rules of the protocol are "Get the condition from the ILP packet"= . > In that case, that specific lower level protocol is forcing implementatio= ns > to understand the ILP packet format, that's an implementation detail. > > Another lower layer protocol might take the condition from the ILP packet > and re-encode it in a different form (like a base64ulr string or NI: uri) > > >> Then the connectors' ILP-packet-related behavior can all be routing >> related. >> > > Routing requires looking at the condition, expiry and amount. A > connector's routing logic shouldn't forward a packet if the expiry is too > low or if the condition is obviously corrupted. > > If the protocols were designed correctly as I am proposing then another > routing decision would be, is the condition that was used in the incoming > transfer the same as the one used in the ILP packet? > > > >> This would add a few benefits; two connectors could perform non-ILP >> conditional transfers between one another (which would be useful for >> reconciliation and settlement), and could also allow two connectors to u= se >> more complex condition types (i.e. signatures for atomic mode) without >> forcing us to support that in the ILP packet. >> > > You seem to have this backwards. Both of these things are supported if th= e > condition and expiry ARE in the ILP packet. Atomic mode is not supported = in > the ILP protocol it is supported in the lower layer transfer protocol. Th= e > ILP packet just contains the end-to-end condition (always a SHA-256 hash) > and then the local transfer can have a different condition that is derive= d > from the condition in the ILP packet. > > >> It also keeps the integrity of the ILP packet as something lower levels >> don't modify; the connector has to modify the expiry in order to pass al= ong >> an ILP payment (they may not modify the expiry if they're using somethin= g >> like atomic mode, but then we have the issue with advanced condition typ= es >> not being supported in the ILP packet). >> > > I think the expiry should always be the expiry set by the sender. It won'= t > be changed. > >> >> In the case where the ledger _does_ care about the condition and >> fulfillment, the argument in favor of separating >> condition/fulfillment/expiry from the rest of the packet is similar. >> Because we don't control the features of all ledgers, we'll need our >> plugins or ledger adapters to be aware of ILP. This makes it hard to >> interact with any events that don't involve ILP packets, and impossible = to >> handle features that extend beyond what we support in the ILP packet. We >> could pass details about non-ILP ledger features (like a crypto conditio= n) >> in the side data, but in the event of any redundancy we have to check th= e >> ledger-supplied info, not the info in the ILP packet. >> > > Comparing the condition in the local transfer and the one in the ILP > packet should be part of the routing logic. > > >> >> Basically, condition/fulfillment/expiry are used for accounting local >> transfers (even if they aren't being "ledger" enforced) in addition to >> their role as every-hop information. By putting them in the ILP packet, = we >> limit the special features that ledgers can support and make our softwar= e >> abstractions harder to separate cleanly. By putting them in the local >> transfer alongside the ILP packet but not inside it, we do separate the >> data a little more, but we have more freedom in what the underlying >> accounting and ledger logic can do, and our software modules will have m= ore >> clearly separated domains. >> > > They should be in both the local transfer AND the ILP packet if they are > needed by the local transfer protocol. This allows the flexibility you > desire because the local transfer protocol can do ANYTHING including usin= g > the condition from the ILP packet as-is, not at all or enhanced for > something like atomic mode. > > > >> >> On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie < >> adrian@hopebailie.com> wrote: >> >>> Exactly =F0=9F=91=8D >>> >>> On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian >>> wrote: >>> >>>> Ok, I think I have a better idea of what you're saying. >>>> >>>> It sounds like you're saying the ILP layer contains all information >>>> that is common between every hop (destination, destination amount, opa= que >>>> data, condition, fulfillment, expiry). The lower level would then be u= sed >>>> for all the transfer-local details (source amount, next connector acco= unt, >>>> custom/local data). >>>> >>>> If the lower level wanted to do anything related to the every-hop >>>> payment, i.e. escrow funds until the receipt has been produced, it wou= ld >>>> look into the ILP layer for that information. If the lower level didn'= t do >>>> any escrow or expiries that require every-hop details, it would simply >>>> function as a communication method. >>>> >>>> Is that right? >>>> >>>> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >>>> adrian@hopebailie.com> wrote: >>>> >>>>> >>>>> >>>>> On 15 August 2017 at 16:00, Ben Sharafian >>>>> wrote: >>>>> >>>>>> In that case, the plugin or whatever is doing the accounting is the >>>>>>>>> ledger. Digital value is always tracked in ledgers, so I think it= does make >>>>>>>>> sense to think of this as the base layer. The reason to abstract = the >>>>>>>>> functionality you expect from the ledger layer is precisely so yo= u can >>>>>>>>> handle it in different ways, depending on what the underlying sys= tems >>>>>>>>> provide. >>>>>>>> >>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>> >>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>>> some type of HTLA >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 1. There are separate plugins for messaging and for transfers >>>>>>>> and when you peer with someone you have to agree on a plugin fo= r each >>>>>>>> >>>>>>>> >>>>>>>> 1. We standardize the messaging part and say that all goes over >>>>>>>> IP and then just have more minimal plugins for the on-ledger se= ttlements >>>>>>>> >>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>> sense. >>>>>>> >>>>>>> >>>>>> I think you're confusing implementation details and defining of >>>>>>> interfaces with definition of a protocol stack. The only difference= s >>>>>>> between the tree examples you have above is in implementation. >>>>>> >>>>>> >>>>>> I had to scroll up after reading this to make sure it was @adrian >>>>>> talking, because that seems like the opposite of what you were argui= ng for. >>>>>> >>>>> >>>>> I don't think so. But I think that is part of the problem. We are not >>>>> all focused on the same thing. I am actually not very interested in C= LP at >>>>> all. It is one of potentially many protocols that may exist below the= ILP >>>>> layer. All we're doing by defining CLP is bootstrapping the network b= y >>>>> defining a protocol for everyone to use to get started. >>>>> >>>>> In designing the ILP layer properly we should try and forget >>>>> everything we know about the lower layers other than what features we >>>>> require of them. >>>>> >>>>> There is a misconception that ILP requires the lower layers to suppor= t >>>>> conditional transfers, that is not true. >>>>> >>>>> All we actually need from a lower layer protocol is to transfer data >>>>> back and forth and provide a way to reliably map requests to response= s. >>>>> >>>>> What ILP provides lower layers is a way to reward your peer for >>>>> passing on the packet. The Internetworking layer defines a condition,= a >>>>> reward that must be paid to the receiver for the fulfillment and the = time >>>>> allowed to claim this reward. >>>>> >>>>> Because of this, within lower-layer protocols that offer the basic >>>>> request/response features we need, we could add conditional payment >>>>> semantics that use the condition, expiry and fulfillment provided by = ILP. >>>>> This would allow a node to offer a reward to their next peer to for >>>>> delivering the packet they send them and to make the local financial >>>>> transaction contingent on the end-to-end transaction. >>>>> >>>>> But crucially, adding that semantic to the lower layer protocol >>>>> provides nothing extra to the ILP layer. The value is purely derived = from >>>>> the two peers who use that protocol and can now use conditional payme= nts to >>>>> protect themselves from their peers. >>>>> >>>>> >>>>>> The proposal that you're arguing for is basically asserting that >>>>>> we're going to be using CLP, because it makes the assumption that th= e >>>>>> connectors (who understand ILP) are managing the HTLA logic. >>>>>> >>>>> >>>>> Not at all. I am asserting that it doesn't matter what protocol you >>>>> use below the ILP layer because it shouldn't matter. All of this talk= about >>>>> ILP being different because money is more important than data is nons= ense. >>>>> >>>>> The difference between ILP and IP that makes ILP suitable for value >>>>> transfer and IP not is at the internetworking layer. ILP requires tha= t all >>>>> packets are either a request or response and that the responses follo= w the >>>>> same path as the requests. Further ILP defines a signature scheme tha= t >>>>> gives the sender a way to be certain the request was received by the >>>>> receiver. >>>>> >>>>> *This could be done entirely without money* but then there would be >>>>> little incentive to sign the receipt or deliver the signature back to= the >>>>> original sender. >>>>> >>>>> So, if you add money then you add economic incentives to the mix. At >>>>> each hop the sender promises the next upstream peer a payment if they= can >>>>> return the receipt. The net effect is that this can be used to transf= er >>>>> money from the sender to the receiver by simply defining up front the >>>>> amount that the receiver must get to produce the signature. >>>>> >>>>> >>>>>> >>>>>> In the current model, the CLP/trustline model and the direct ledger >>>>>> model both work without having to treat anything on the ILP layer >>>>>> differently. We're favoring on-ledger messaging because of our >>>>>> implementation, yes, but we've been able to switch most all of our p= lugins >>>>>> from on-ledger messaging to RPC-based messaging without changing the= ILP >>>>>> layer at all. >>>>>> >>>>>> With the ledger-level abstraction, we were able to switch from our >>>>>> ledger-based mode of thinking to the CLP/trustline based way without >>>>>> changing anything other than the plugin. Your argument comes from an >>>>>> assumption of a CLP-style ledger protocol with some underlying ledge= r, >>>>>> which we can't assume is always the case. >>>>>> >>>>> >>>>> I'm not sure what any of that proves tbh. These are all implementatio= n >>>>> concerns. They don't change the fact that the condition, expiry and >>>>> fulfillment are part of ILP not the lower layer protocols. >>>>> >>>>>> >>>>>> >>>>>> From the perspective of the Interledger Protocol the implementation >>>>>>> of the lower layers is not important, that's the whole point of lay= ering. >>>>>>> By forcing important aspects of ILP like the condition, fulfillment= and >>>>>>> expiry down into those layers you muddy the waters and we now have = to >>>>>>> standardize those protocols too. Instead we should just be defining= the >>>>>>> functions they must provide and then leave it up to implementations= to >>>>>>> provide those functions. >>>>>> >>>>>> >>>>>> I don't agree with this point; the condition and fulfillment have >>>>>> actual meaning to the ledger layer. >>>>>> >>>>> >>>>> NO THEY DON'T! They have meaning to SOME ledgers that implement SOME >>>>> lower layer protocols, IF they choose to use them. >>>>> >>>>> Excuse the shouting but this is the crux of the issue. We need to all >>>>> agree that it is entirely possible for a transfer to be done that doe= sn't >>>>> use the condition and fulfillment and that if this was in the middle = of a >>>>> 10-hop ILP payment it would have no effect on the sender and receiver= . >>>>> >>>>>> >>>>>> You've said that the ledger often doesn't care about fulfillment and >>>>>> condition, but the ledger _layer_'s (where transfers are done) role = is to >>>>>> take in condition and fulfillment and make a transfer which satisfie= s its >>>>>> HTLA. >>>>>> >>>>> >>>>> No, the ledger's role is to keep a tab of net financial positions >>>>> between two peers. It MAY use conditions and fulfillments that it pul= ls >>>>> from the ILP layer to help it do that in a way both peers agree on. >>>>> >>>>> Note that a "layer" doesn't have a role. I think there is some >>>>> confusion about the difference between layering the protocol and >>>>> abstracting functionality into different components. >>>>> >>>>> >>>>>> If the ledger layer has to look into the ILP packet to do so, that i= s >>>>>> a blatant breaking of layering. >>>>>> >>>>> >>>>> Not at all! The module acting at the layers *below* the >>>>> internetworking layer shouldn't modify anything inside the packets of= the >>>>> higher layers but they can definitely inspect them and adjust their >>>>> behavior based on what they to find. >>>>> >>>>> In fact the prevalence of this is the subject of a lot of debate at >>>>> the IETF currently because endpoints are often encrypting their paylo= ads >>>>> and in some cases this makes it difficult for middle-boxes to be effe= ctive >>>>> at their jobs. >>>>> >>>>> By putting the condition, fulfillment, and expiry on the ledger layer= , >>>>>> we leave it open for any ledger type to work, rather than forcing al= l >>>>>> ledger-layer software to understand ILP. >>>>>> >>>>> >>>>> Actually you do the opposite. You make it a requirement of every >>>>> protocol below the ILP layer to define a way to carry these data elem= ents >>>>> and encode and decode them, even if they don't use them >>>>> >>>>> Ledger layer components don't have to understand ILP unless they >>>>> choose to re-use the condition for their own local transfer. Ledgers >>>>> themselves *never* have to understand ILP. >>>>> >>>>> Remember a ledger layer protocol could use a completely different >>>>> conditional payments scheme, like atomic mode ILP, where it takes the >>>>> end-to-end condition and creates a new compound condition that depend= s on >>>>> the fulfillment and some notary signature. >>>>> >>>>> There will be a component in a connector's stack that must pass the >>>>> ILP packet to the next peer. If it does this using a transfer protoco= l that >>>>> uses conditional transfers and wants to use the same condition as the= ILP >>>>> packet then it must decode the packet. >>>>> >>>>> But, it will likely do something with that condition before sending >>>>> the transfer to the ledger like encoding it differently or rehashing = it >>>>> (lightning?) so that it's in the form expected by the ledger. >>>>> >>>>> That's an implementation decision of the lower layer protocol used >>>>> between those two peers. >>>>> >>>>> >>>>>> >>>>>> I agree that Interledger defines how conditions, fulfillments, and >>>>>> expiries should be chained together, but it makes no assertions abou= t their >>>>>> data format. >>>>>> >>>>> >>>>> ILP doesn't define how anything is chained together. From the >>>>> perspective of ILP the condition and fulfillment are end-to-end data.= They >>>>> are agreed by the two endpoints who don't care how they get from Alic= e to >>>>> Bob and back. >>>>> >>>>> The design of ILP is such that it facilitates the design of lower >>>>> level protocols that can be used to carry the ILP packets across mult= iple >>>>> hops (networks) using economic incentives such that the sender pays e= nough >>>>> for the first hop to ensure that all nodes in between can extract the= fee >>>>> they want and the receiver will still get the amount they expected.. >>>>> >>>>> >>>>> >>>>>> ILP says you should send your outgoing transfer with the same >>>>>> condition as the incoming one, and a lower expiry. >>>>>> >>>>> >>>>> No it doesn't. An internetworking protocol can't prescribe that kind >>>>> of thing to lower level protocols. An incoming and outgoing transfer = could >>>>> be sent using completely different protocols and the financial agreem= ent >>>>> with the peers on those two routes could be vastly different too. >>>>> >>>>> The only service ILP requires of lower level protocols is that they >>>>> can map a response to an original request. This requirement is okay b= ecause >>>>> it is isolated to a single route/link at a time not a requirement tha= t >>>>> crosses the inter-network boundary that ILP crosses. >>>>> >>>>> >>>>>> But because ILP allows for many different types of ledgers, it >>>>>> doesn't make sense to assert how these are encoded. >>>>>> >>>>> >>>>> By putting them in the ILP packet you do the opposite. You make no >>>>> assertions about how they are encoded if they are used at lower layer= s, or >>>>> how they may be combined with other conditions or even used to derive= new >>>>> conditions. >>>>> >>>>>> >>>>>> IP doesn't tell you how to encode an ethernet packet. It doesn't eve= n >>>>>> know whether it's going over a computer or a hand-written letter car= ried by >>>>>> a pigeon. IP takes for granted that you can send data over one conne= ction >>>>>> by putting it in a lower level. >>>>>> >>>>> >>>>> Correct, but if a link layer protocol wanted to look into the IP >>>>> packet headers of a packet it wants to transfer and use some data fro= m >>>>> there in its internal logic (or even reuse data in it's own frame) th= at >>>>> would be totally fine. >>>>> >>>>> >>>>>> Even though IP tells you how to chain these connections together, it >>>>>> doesn't have to put the things it's chaining on the internetworking = level. >>>>>> >>>>> >>>>> IP doesn't tell you how to chain things together. IP simply defines >>>>> the end-to end data envelope and address space. Because of this nodes= that >>>>> implement the multiple lower layer protocols are able to push IP pack= ets >>>>> down a link and expect the node on the other side to understand the h= eaders >>>>> and route it onward on another link. >>>>> >>>>> Everything needed by the IP module to decide what to do with the >>>>> packet is in the IP packet headers. i.e. Has it exceeded a TTL? Is th= ere a >>>>> route for this destination? Is it corrupted (checksum fails)? But als= o, >>>>> everything that is needed by the endpoint (like the source address) i= s also >>>>> in there. >>>>> >>>>> There is no dependency on nodes to be good citizens and always pass >>>>> certain other data from the lower layers into the next link. That wou= ld be >>>>> breaking the layering. >>>>> >>>>> >>>>>> IP also assumes that if you get some incoming data on a connection >>>>>> you can copy it and send it out on the next connection. Because you = can >>>>>> already send data over a connection, all IP adds is the missing piec= e: a >>>>>> packet that tells you where to go. >>>>>> >>>>>> With ILP, we assume that there is a way to prepare a conditional >>>>>> transfer, expire a conditional transfer, and fulfill a conditional >>>>>> transfer. >>>>>> >>>>> >>>>> No we don't! We assume that if we deliver the packet as intended we'l= l >>>>> get back a response packet with a signature that matches the conditio= n in >>>>> the packet. So, if we have an agreement with someone that they will p= ay us >>>>> when we present that signature then we are prepared to enter a simila= r >>>>> agreement with the next peer because we expect that signature to come= all >>>>> the way back along the interledger layer route.. >>>>> >>>>> >>>>>> We also assume that if you get an incoming transfer you can create a= n >>>>>> outgoing transfer with the same condition. The abstraction we made m= eans >>>>>> that conditions and fulfillments are already carried in the lower le= vels. >>>>>> >>>>> >>>>> That is a bad assumption that comes from the broken layering. What if >>>>> my outgoing link doesn't support conditional transfers? So now where = do I >>>>> put the condition? >>>>> >>>>>> >>>>>> >>>>>> We could have assumed that no ledgers ever support conditional >>>>>> transfers, and said the only thing ILP gets from lower levels is the >>>>>> ability to send a transfer. But if we want to support the case where= any of >>>>>> them do, we have to keep the conditions and fulfillments in the laye= r where >>>>>> they're actually used. >>>>>> >>>>> >>>>> I don't follow that logic at all. If we want to support the case wher= e >>>>> any of them do then we must ensure the condition and expiry are alway= s >>>>> carried in a consistent place at the internetworking layer so that if= they >>>>> do want to use them they know where to find them. >>>>> >>>>> >>>>>> >>>>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>>>> adrian@hopebailie.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 14 August 2017 at 22:03, Evan Schwartz wrote: >>>>>>> >>>>>>>> I think this thread is going to get extremely unwieldy but here >>>>>>>> goes: >>>>>>>> >>>>>>>> > - All interledger layer messages should be ILP packets >>>>>>>> (including fulfillments) and be capable of carrying higher layer p= rotocol >>>>>>>> payloads. >>>>>>>> >>>>>>>> Interledger has higher requirements than ILP for the lowest layer, >>>>>>>> specifically because we are carrying money and not just data. One = of the >>>>>>>> requirements is being able to transmit a 32-byte fulfillment back = along the >>>>>>>> same path that carried the payment originally. If we expect this o= f the >>>>>>>> lower layer, I don't see a point in putting the fulfillment into a= n ILP >>>>>>>> packet and transmitting it as Interledger data along the same path= . All >>>>>>>> ledger-layer protocols will need to interpret the fulfillment pass= ed in >>>>>>>> their protocol, not the one passed through the Interledger layer. >>>>>>>> >>>>>>> >>>>>>> This is not correct. There is no requirement on ledger layer >>>>>>> protocols to transmit or understand the fulfillment. You are lookin= g at >>>>>>> this through the lens of existing implementations from the bottom u= p >>>>>>> instead of starting at the interledger layer. >>>>>>> >>>>>>> The primary function of the condition and fulfillment is as a signe= d >>>>>>> end-to-end receipt. If the sender agrees a condition with a receive= r and >>>>>>> then gets back the valid fulfillment they don't care what happened = in the >>>>>>> middle. The receiver has signed a receipt saying they have their mo= ney. >>>>>>> >>>>>>> The value of using a standard for the receipt and signature is that >>>>>>> each transfer along the way CAN re-use it. One the one hand you can= have a >>>>>>> transfer between two peers that have zero trust and the ledger they= use >>>>>>> supports conditional payments completely. On the other extreme you = can have >>>>>>> two peers that have a full trust and ignore the condition and fulfi= llment >>>>>>> completely. >>>>>>> >>>>>>> The ledger layer protocols carry ILP packets. Payment requests and >>>>>>> either fulfillment or error responses. If a ledger layer protocol w= ants to >>>>>>> use the condition and fulfillment for their own operations they can= extract >>>>>>> these from the ILP packets and use them. >>>>>>> >>>>>>> >>>>>>>> > - While it may make sense to split the interledger payment and >>>>>>>> interledger quoting protocols into new higher level protocols that= seems >>>>>>>> like an unnecessary abstraction. Instead the packet definitions sh= ould just >>>>>>>> have some consistency and probably a common base/header. >>>>>>>> >>>>>>>> The current protocols effectively have this header but it isn't >>>>>>>> separated out. There are two fields in the request header: type an= d >>>>>>>> destination address. There is one field in the response header: ty= pe. I >>>>>>>> don't think it makes that much of a big difference to separate the= se fields >>>>>>>> if all of the fields in that packet need to be interpreted togethe= r (for >>>>>>>> example, you can't understand a quote request if you strip off the >>>>>>>> destination address). >>>>>>>> >>>>>>> >>>>>>> I agree that we don't HAVE to explicitly separate them out but I >>>>>>> think ti would make it clearer how the stack is architected if ther= e was a >>>>>>> header that was consistent across all packets. Currently the only t= hing >>>>>>> that is consitent across all ILP packets is that they are defined i= nt he >>>>>>> same file. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> > - We should define two base ILP packet types: request and >>>>>>>> response. >>>>>>>> >>>>>>>> Unless this adds some substantive benefit or new fields I don't >>>>>>>> think it's worth breaking all of the formats we have just to rearr= ange >>>>>>>> things. >>>>>>>> >>>>>>> >>>>>>> The goal of this exercise is to tease out the best design and ignor= e >>>>>>> the cost of change until we can compare the results with the curren= t design. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>>>> nodes/hosts. >>>>>>>> >>>>>>>> A ledger is any system that tracks accounts and balances. When you >>>>>>>> use a trustline all of your messages still need to go through an a= ccounting >>>>>>>> system (such as the plugin in the JS implementation) and then on t= o the >>>>>>>> other program logic. >>>>>>>> >>>>>>> >>>>>>> As above, this is incorrect. There is no requirement for "all >>>>>>> messages to go through an accounting system". >>>>>>> >>>>>>> Since designing the first implementation of 5-bells ledger we have >>>>>>> assumed that passing the ILP packet MUST be done by the ledger beca= use that >>>>>>> is how we implemented it. But that is not true. It is perfectly val= id for >>>>>>> the passing of an ILP packet from one peer to another to be simply = an >>>>>>> exchange of data. >>>>>>> >>>>>>> The receiving peer makes a decision about whether or not to forward >>>>>>> the packet based on the current financial position they have with t= he >>>>>>> sending peer. >>>>>>> >>>>>>> It is convenient if the ledger that records the net positions of th= e >>>>>>> peers also forwards the messaging and even better if it natively su= pports >>>>>>> conditional payments and can use the condition and the fulfillment = from the >>>>>>> ILP packet for those but that's all it is, convenient. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> In that case, the plugin or whatever is doing the accounting is th= e >>>>>>>> ledger. Digital value is always tracked in ledgers, so I think it = does make >>>>>>>> sense to think of this as the base layer. The reason to abstract t= he >>>>>>>> functionality you expect from the ledger layer is precisely so you= can >>>>>>>> handle it in different ways, depending on what the underlying syst= ems >>>>>>>> provide. >>>>>>>> >>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>> >>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>>> some type of HTLA >>>>>>>> >>>>>>>> 2. There are separate plugins for messaging and for transfers >>>>>>>> and when you peer with someone you have to agree on a plugin fo= r each >>>>>>>> 3. We standardize the messaging part and say that all goes over >>>>>>>> IP and then just have more minimal plugins for the on-ledger se= ttlements >>>>>>>> >>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>> sense. >>>>>>>> >>>>>>> >>>>>>> I think you're confusing implementation details and defining of >>>>>>> interfaces with definition of a protocol stack. The only difference= s >>>>>>> between the tree examples you have above is in implementation. >>>>>>> >>>>>>> From the perspective of the Interledger Protocol the implementation >>>>>>> of the lower layers is not important, that's the whole point of lay= ering. >>>>>>> By forcing important aspects of ILP like the condition, fulfillment= and >>>>>>> expiry down into those layers you muddy the waters and we now have = to >>>>>>> standardize those protocols too. Instead we should just be defining= the >>>>>>> functions they must provide and then leave it up to implementations= to >>>>>>> provide those functions. >>>>>>> >>>>>>> I know we want to define a standard to bootstrap the system (CLP) >>>>>>> but that's misleading us into thinking it's an essential part of th= e stack. >>>>>>> It's perfectly valid for two peers to not use CLP and still be part= of the >>>>>>> Interledger. >>>>>>> >>>>>>> That said, you raise an interesting consideration about the layers >>>>>>> below ILP and actually I think it makes sense to split these. >>>>>>> >>>>>>> We keep trying to force messaging through the ledger layer and >>>>>>> actually that's the wrong place to put it if we can split the ledge= r layer >>>>>>> into a messaging layer and a ledger layer. That way we can stop try= ing to >>>>>>> think of all HLTAs as ledgers. >>>>>>> >>>>>>> A thought, why not use sub-layers as is common in other stacks: >>>>>>> >>>>>>> 1. Link layer: Layer upon which two peers that have a direct link, >>>>>>> or participate in the same payment network, communicate >>>>>>> 2. Transfer/ ledger: Layer on which financial positions between two >>>>>>> peers are recorded >>>>>>> >>>>>>> This reflects the already emerging HTLA model and many of our >>>>>>> existing plugins and ledger integrations. >>>>>>> Link Layer: XRP Paychan, Lightning >>>>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>>>> >>>>>>> This doesn't prevent us from defining a standard binary protocol >>>>>>> that defines all of the operations for both layers (like CLP) but I= see >>>>>>> value in distinguishing between these two. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> > - The protocol should differentiate between the operation of >>>>>>>> preparing a transfer on a ledger and the operation of passing an I= LP packet >>>>>>>> from one peer to another. >>>>>>>> >>>>>>>> The protocol assumes your conditional transfer is underpinned by >>>>>>>> some HTLA >>>>>>>> . >>>>>>>> It doesn't care whether that's on-ledger or not. >>>>>>>> >>>>>>> >>>>>>> What do you mean when you say "the protocol"? In my statement I am >>>>>>> referring to ILP. >>>>>>> My point above being that ILP expects ILP packets to be passed from >>>>>>> peer to peer but has no expectations about transfers. >>>>>>> >>>>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>>>> exchange ILP packets with no transfers. Clearly if a node routes a = packet >>>>>>> on and has no incoming transfer it's going to lose money but that's= a >>>>>>> consideration for that node. It doesn't affect anyone else in the c= hain. >>>>>>> >>>>>>> ILP doesn't assume anything about transfers at all, let alone >>>>>>> conditional transfers. It provides useful semantics for conditional >>>>>>> transfers to be used by two peers to transact as part of a larger I= LP >>>>>>> payment. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> > - The condition and timeout should be included in the ILP >>>>>>>> payment packet. >>>>>>>> >>>>>>>> I strongly disagree with this. We had this debate a year ago and I >>>>>>>> was on your side but was convinced that this is not a good idea. >>>>>>>> >>>>>>> >>>>>>> Yes, I recall this and I'm sorry I didn't push harder on this point= . >>>>>>> Unfortunately I think the decision to pull it out of the packet is = mostly >>>>>>> driven by how our prototypes were implemented rather than good arch= itecture. >>>>>>> >>>>>>>> >>>>>>>> The layer below ILP must be capable of doing conditional transfers >>>>>>>> based on sha256 hashlocks with 32-byte preimages. >>>>>>>> >>>>>>> >>>>>>> This is not true and I think it would be useful for us to agree on >>>>>>> this as this seems to be the argument I am coming up against most o= ften. >>>>>>> The peers participating in a transfer that is part of an ILP paymen= t may >>>>>>> wish to use conditional transfers as a way to enforce their agreeme= nt but >>>>>>> this is not a requirement of the protocol. >>>>>>> >>>>>>> The agreement between any two peers is: "I will pay you X if you ca= n >>>>>>> provide a receipt that Y was paid Z before T". >>>>>>> ILP provides a standard for expressing this agreement so that these >>>>>>> can be chained together BUT it is not a requirement that every agre= ement in >>>>>>> the chain uses the condition, and fulfillment provided at the ILP l= ayer. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> As a result, the original condition and the corresponding preimage >>>>>>>> MUST be expressed in that layer. >>>>>>>> >>>>>>> >>>>>>> As I have shown above, this is not true. >>>>>>> >>>>>>> >>>>>>>> Then the question is whether we should also include it in the >>>>>>>> packet that is forwarded. What ultimately convinced me is the foll= owing: >>>>>>>> All connectors MUST ignore the condition if it is in the packet, b= ecause >>>>>>>> they are only guaranteed their money back if they use the same con= dition >>>>>>>> from the incoming transfer they got. >>>>>>>> >>>>>>> >>>>>>> Here is where the layering is being corrupted. >>>>>>> >>>>>>> All connectors MUST inspect the condition in the ILP packet as part >>>>>>> of their decision to route the packet or not. >>>>>>> When the local transfer module of the connectors stack passes the >>>>>>> ILP packet up to the ILP module it should indicate the properties o= f the >>>>>>> incoming transfer that carried the packet. >>>>>>> This is essential firstly so that the routing logic in the ILP >>>>>>> module can record the incoming transfer identifier so it is able to= use the >>>>>>> correct response id when it passes back the fulfillment or error. >>>>>>> The other properties that the ILP module should look at are the >>>>>>> condition and expiry on the incoming transfer. >>>>>>> >>>>>>> If the incoming route uses conditional transfers and these are >>>>>>> supposed to match the condition and expiry in the ILP packet then t= he ILP >>>>>>> module should compare them and reject the packet if: >>>>>>> a) the conditions don't match OR >>>>>>> b) the expiry is too short >>>>>>> >>>>>>> We should still discuss if the expiry should be set by the sender >>>>>>> and left unchanged or used like a TTL and decremented by each node. >>>>>>> >>>>>>> >>>>>>>> Also, the receiver will need to take out the condition in order to >>>>>>>> hash the packet for PSK or IPR. >>>>>>>> >>>>>>> >>>>>>> This is completely normal. Zeroing a checksum field in a header >>>>>>> before calculating the checksum is VERY common precisely because it= 's long >>>>>>> been accepted that the right place to put that data is in the heade= rs and >>>>>>> the work of zero'ing it out to calculate the checksum (or signature= in our >>>>>>> case) is not material. >>>>>>> >>>>>>> >>>>>>>> So basically, no one wants the condition in there. It feels like i= t >>>>>>>> ought to be in there, but literally none of the parties want the e= xtra 32 >>>>>>>> bytes in there. >>>>>>>> >>>>>>> >>>>>>> "Nobody wants it there" is a terrible reason to abandon the correct >>>>>>> design. The whole purpose of a good architecture is you accept that= there >>>>>>> may be cases in future that haven't been considered now so designin= g just >>>>>>> for the known cases is a bad idea. >>>>>>> >>>>>>> Good architecture is not the same as optimization. Taking stuff out >>>>>>> (even when it feels wrong) to save a few bytes is a good sign that = it's a >>>>>>> bad idea. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The reason the timeout should not be in there is that there isn't = a >>>>>>>> single timeout for the payment. There are multiple separate timeou= ts for >>>>>>>> each of the bilateral transfers. Those must go in the individual t= ransfers >>>>>>>> and there is no sensible value to put in the Interledger packet. >>>>>>>> >>>>>>> >>>>>>> As above, this is somewhat equivalent to the TTL in an IP packet. >>>>>>> I'm open to discussing if it should be a fixed value set by the sen= der >>>>>>> where each node uses their own value but has the sender-defined val= ue as a >>>>>>> reference or it is actually decremented at each hop. >>>>>>> >>>>>>> Either way, this is part of ILP not the ledger layer just like the >>>>>>> condition and fulfillment. It may be used by the ledger layer but t= hat's >>>>>>> implementation specific. It belongs in the ILP packet. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> -- >>> Sent from a mobile device, please excuse any typos >>> >> >> > --001a1142c36a57b8f405570cb9f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    If the human species survives, they'll say humans near= ly went extinct, because some liked to keep secrets (top secret, secret, cl= assified).

    O= n Thu, Aug 17, 2017 at 1:32 PM, Adrian Hope-Bailie <adrian@hopebailie.= com> wrote:


    On 16= August 2017 at 10:22, Ben Sharafian <sharafian@ripple.com> wrote:
    OK, I think in that case we're mostly disagreeing over wh= ere the condition/fulfillment/expiry actually go in the data.
    =

    That's one way to look a= t it but that's ultimately what the architecting the layering is. Decid= ing at which layer (and therefor encapsulated in what packet) certain data = should be.
    =C2=A0
    <= span class=3D"m_-2520282122105586262im m_-2520282122105586262HOEnZb">
    The reason I don't agree wi= th your position is based on which parties I think should be aware of ILP. =

    I don't thi= nk that's the right way to look at it. The connector needs to be able t= o understand at least the ILP layer data AND the lower layer data. Normally= the way the processing stack is implemented is that there is a module for = each layer that processes the data from that layer and then passes the payl= oad and any other important information up to the next layer.
    =C2=A0
    In order to track the balance between each oth= er accurately, the two connectors have to keep track of conditions, fulfill= ments, and expiries on each of the transfers.

    This is where I disagree with you. Two connectors e= xchanging a transfer only care about the data that is relevant to them for = that transfer. It's quite possible for two connectors to perform a tran= sfer that has no conditions or fulfillments or a transfer that has a differ= ent condition and fulfillment (such as an atomic mode transfer where the co= ndition is a compound one that has multiple sub-conditions).
    =C2=A0
    That means the connectors' accounting logic that hand= les the conditions, fulfillments, and expiries is going to be using some in= formation inside the ILP packet and some information outside of it in order= to perform these transfers.

    =
    It will only use info inside the packet if it uses conditional = transfers that use that same condition. This is the most likely scenario bu= t that is not a protocol requirement.
    =C2=A0

    <= /div>
    I think it's cleaner to say everyt= hing required to make these local transfers should go in one protocol, so t= he accounting logic of these connectors doesn't have to deal with ILP d= irectly.

    I stron= gly disagree with that. That's entirely the wrong reason to put data in= to a specific layer. The data in the ILP layer is there because it's &q= uot;end-to-end" data.

    If a protocol at a lower layer= wants to use that data then it must replicate it. That seems inefficient b= ut it's the correct way to do it.

    One could define a = lower layer protocol that doesn't replicate the data but the rules of t= he protocol are "Get the condition from the ILP packet". In that = case, that specific lower level protocol is forcing implementations to unde= rstand the ILP packet format, that's an implementation detail.

    <= /div>
    Another lower layer protocol might take the condition from the IL= P packet and re-encode it in a different form (like a base64ulr string or N= I: uri)
    =C2=A0
    Then the connectors' ILP-packe= t-related behavior can all be routing related.

    Routing requires looking at the condition, e= xpiry and amount. A connector's routing logic shouldn't forward a p= acket if the expiry is too low or if the condition is obviously corrupted.<= br>
    If the protocols were designed correctly as I am proposin= g then another routing decision would be, is the condition that was used in= the incoming transfer the same as the one used in the ILP packet?

    =C2=A0
    This would add a few benefits; two= connectors could perform non-ILP conditional transfers between one another= (which would be useful for reconciliation and settlement), and could also = allow two connectors to use more complex condition types (i.e. signatures f= or atomic mode) without forcing us to support that in the ILP packet.

    You seem to have this= backwards. Both of these things are supported if the condition and expiry = ARE in the ILP packet. Atomic mode is not supported in the ILP protocol it = is supported in the lower layer transfer protocol. The ILP packet just cont= ains the end-to-end condition (always a SHA-256 hash) and then the local tr= ansfer can have a different condition that is derived from the condition in= the ILP packet.
    =C2=A0
    =
    It also keeps the integrit= y of the ILP packet as something lower levels don't modify; the connect= or has to modify the expiry in order to pass along an ILP payment (they may= not modify the expiry if they're using something like atomic mode, but= then we have the issue with advanced condition types not being supported i= n the ILP packet).

    I t= hink the expiry should always be the expiry set by the sender. It won't= be changed.

    In the case where the ledger _does_ care about the= condition and fulfillment, the argument in favor of separating condition/f= ulfillment/expiry from the rest of the packet is similar. Because we don= 9;t control the features of all ledgers, we'll need our plugins or ledg= er adapters to be aware of ILP. This makes it hard to interact with any eve= nts that don't involve ILP packets, and impossible to handle features t= hat extend beyond what we support in the ILP packet. We could pass details = about non-ILP ledger features (like a crypto condition) in the side data, b= ut in the event of any redundancy we have to check the ledger-supplied info= , not the info in the ILP packet.

    <= /div>
    Comparing the condition in the local transfer and the one = in the ILP packet should be part of the routing logic.
    = =C2=A0

    Basically, condition/= fulfillment/expiry are used for accounting local transfers (even if they ar= en't being "ledger" enforced) in addition to their role as ev= ery-hop information. By putting them in the ILP packet, we limit the specia= l features that ledgers can support and make our software abstractions hard= er to separate cleanly. By putting them in the local transfer alongside the= ILP packet but not inside it, we do separate the data a little more, but w= e have more freedom in what the underlying accounting and ledger logic can = do, and our software modules will have more clearly separated domains.

    They should be in bot= h the local transfer AND the ILP packet if they are needed by the local tra= nsfer protocol. This allows the flexibility you desire because the local tr= ansfer protocol can do ANYTHING including using the condition from the ILP = packet as-is, not at all or enhanced for something like atomic mode.

    =C2=A0

    On Tu= e, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie <adrian@hopebailie.com= > wrote:
    Exactly =F0=9F=91=8D

    On Tue, Aug 15, 2= 017 at 6:52 PM Ben Sharafian <sharafian@ripple.com> wrote:
    Ok, I think I have a better idea of what you're s= aying.

    It sounds like you're saying the ILP layer co= ntains all information that is common between every hop (destination, desti= nation amount, opaque data, condition, fulfillment, expiry). The lower leve= l would then be used for all the transfer-local details (source amount, nex= t connector account, custom/local data).

    If the lo= wer level wanted to do anything related to the every-hop payment, i.e. escr= ow funds until the receipt has been produced, it would look into the ILP la= yer for that information. If the lower level didn't do any escrow or ex= piries that require every-hop details, it would simply function as a commun= ication method.

    Is that right?

    On Tue, Aug 15, 2017 at 6= :35 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    On 15 August 2017 at 16:00, Ben Sharafian <= sharafian@ripple.= com> wrote:
    In that case, the plugin or whatever is do= ing the accounting is the ledger. Digital value is always tracked in ledger= s, so I think it does make sense to think of this as the base layer. The re= ason to abstract the functionality you expect from the ledger layer is prec= isely so you can handle it in different ways, depending on what the underly= ing systems provide.
    I see 3 ways to think of the layer(s) unde= rpinning ILP:
    1. The "= Ledger Layer" provides both messaging capabilities and some type of=C2= =A0HT= LA
    1. There are separat= e plugins for messaging and for transfers and when you peer with someone yo= u have to agree on a plugin for each
    1. We standardize the messaging part and say that all goes over IP and t= hen just have more minimal plugins for the on-ledger settlements
    N= umber 1 is what we have and I think that still makes the most sense.

    I think you're confusing im= plementation details and defining of interfaces with definition of a protoc= ol stack. The only differences between the tree examples you have above is = in implementation.

    I had to s= croll up after reading this to make sure it was @adrian talking, because th= at seems like the opposite of what you were arguing for.

    I don't think so. But I think that is= part of the problem. We are not all focused on the same thing. I am actual= ly not very interested in CLP at all. It is one of potentially many protoco= ls that may exist below the ILP layer. All we're doing by defining CLP = is bootstrapping the network by defining a protocol for everyone to use to = get started.

    In designing the ILP layer properly we shoul= d try and forget everything we know about the lower layers other than what = features we require of them.

    There is a misconception tha= t ILP requires the lower layers to support conditional transfers, that is n= ot true.

    All we actually need from a lower layer protocol= is to transfer data back and forth and provide a way to reliably map reque= sts to responses.

    What ILP provides lower layers is a way= to reward your peer for passing on the packet. The Internetworking layer d= efines a condition, a reward that must be paid to the receiver for the fulf= illment and the time allowed to claim this reward.

    =
    Because of this, within lower-layer protocols that offer the basic req= uest/response features we need, we could add conditional payment semantics = that use the condition, expiry and fulfillment provided by ILP. This would = allow a node to offer a reward to=C2=A0 their next peer to for delivering t= he packet they send them and to make the local financial transaction contin= gent on the end-to-end transaction.

    But crucially, adding= that semantic to the lower layer protocol provides nothing extra to the IL= P layer. The value is purely derived from the two peers who use that protoc= ol and can now use conditional payments to protect themselves from their pe= ers.
    =C2=A0
    The proposal that you're arguing for is basically= asserting that we're going to be using CLP, because it makes the assum= ption that the connectors (who understand ILP) are managing the HTLA logic.=

    Not at all. I am assert= ing that it doesn't matter what protocol you use below the ILP layer be= cause it shouldn't matter. All of this talk about ILP being different b= ecause money is more important than data is nonsense.

    The diff= erence between ILP and IP that makes ILP suitable for value transfer and IP= not is at the internetworking layer. ILP requires that all packets are eit= her a request or response and that the responses follow the same path as th= e requests. Further ILP defines a signature scheme that gives the sender a = way to be certain the request was received by the receiver.

    This could be done entirely without money b= ut then there would be little incentive to sign the receipt or deliver the = signature back to the original sender.

    So, if you add money then you add economic incentives to the mix. At ea= ch hop the sender promises the next upstream peer a payment if they can ret= urn the receipt. The net effect is that this can be used to transfer money = from the sender to the receiver by simply defining up front the amount that= the receiver must get to produce the signature.
    =C2=A0

    In the current m= odel, the CLP/trustline model and the direct ledger model both work without= having to treat anything on the ILP layer differently. We're favoring = on-ledger messaging because of our implementation, yes, but we've been = able to switch most all of our plugins from on-ledger messaging to RPC-base= d messaging without changing the ILP layer at all.

    With the ledger-level abstraction, we were able to switch from our ledger-= based mode of thinking to the CLP/trustline based way without changing anyt= hing other than the plugin. Your argument comes from an assumption of a CLP= -style ledger protocol with some underlying ledger, which we can't assu= me is always the case.

    I'= m not sure what any of that proves tbh. These are all implementation concer= ns. They don't change the fact that the condition, expiry and fulfillme= nt are part of ILP not the lower layer protocols.
    =C2=A0
    <= div>

    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">From the perspective of the Interledger Protocol the implementation = of the lower layers is not important, that's the whole point of layerin= g. By forcing important aspects of ILP like the condition, fulfillment and = expiry down into those layers you muddy the waters and we now have to stand= ardize those protocols too. Instead we should just be defining the function= s they must provide and then leave it up to implementations to provide thos= e functions.

    I don't agre= e with this point; the condition and fulfillment have actual meaning to the= ledger layer.

    NO THEY = DON'T! They have meaning to SOME ledgers that implement SOME lower laye= r protocols, IF they choose to use them.

    Excuse the shout= ing but this is the crux of the issue. We need to all agree that it is enti= rely possible for a transfer to be done that doesn't use the condition = and fulfillment and that if this was in the middle of a 10-hop ILP payment = it would have no effect on the sender and receiver.
    =C2=A0
    You've said t= hat the ledger often doesn't care about fulfillment and condition, but = the ledger _layer_'s (where transfers are done) role is to take in cond= ition and fulfillment and make a transfer which satisfies its HTLA.
    <= /div>

    No, the ledger's role is to kee= p a tab of net financial positions between two peers. It MAY use conditions= and fulfillments that it pulls from the ILP layer to help it do that in a = way both peers agree on.

    Note that = a "layer" doesn't have a role. I think there is some confusio= n about the difference between layering the protocol and abstracting functi= onality into different components.
    =C2= =A0
    If the ledger layer has to look into the ILP= packet to do so, that is a blatant breaking of layering.

    Not at all! The module acting at the lay= ers below the internetworking layer shouldn't modify anything in= side the packets of the higher layers but they can definitely inspect them = and adjust their behavior based on what they to find.

    In fact = the prevalence of this is the subject of a lot of debate at the IETF curren= tly because endpoints are often encrypting their payloads and in some cases= this makes it difficult for middle-boxes to be effective at their jobs.

    By putting the condition, fulfillment, and exp= iry on the ledger layer, we leave it open for any ledger type to work, rath= er than forcing all ledger-layer software to understand ILP.

    Actually you do the opposite. You make= it a requirement of every protocol below the ILP layer to define a way to = carry these data elements and encode and decode them, even if they don'= t use them

    Ledger layer components don't have to unde= rstand ILP unless they choose to re-use the condition for their own local t= ransfer. Ledgers themselves never have to understand ILP.

    Re= member a ledger layer protocol could use a completely different conditional= payments scheme, like atomic mode ILP, where it takes the end-to-end condi= tion and creates a new compound condition that depends on the fulfillment a= nd some notary signature.

    There will be a component in a = connector's stack that must pass the ILP packet to the next peer. If it= does this using a transfer protocol that uses conditional transfers and wa= nts to use the same condition as the ILP packet then it must decode the pac= ket.

    But, it will likely do something with that condition= before sending the transfer to the ledger like encoding it differently or = rehashing it (lightning?) so that it's in the form expected by the ledg= er.

    That's an implementation decision of t= he lower layer protocol used between those two peers.
    = =C2=A0
    I agree that Interledger defines how conditions, fulfillments, = and expiries should be chained together, but it makes no assertions about t= heir data format.

    ILP d= oesn't define how anything is chained together. From the perspective of= ILP the condition and fulfillment are end-to-end data. They are agreed by = the two endpoints who don't care how they get from Alice to Bob and bac= k.

    The design of ILP is such that it facilitates the desi= gn of lower level protocols that can be used to carry the ILP packets acros= s multiple hops (networks) using economic incentives such that the sender p= ays enough for the first hop to ensure that all nodes in between can extrac= t the fee they want and the receiver will still get the amount they expecte= d..

    =C2=A0
    ILP says you should send your outgoing transfer wi= th the same condition as the incoming one, and a lower expiry.
    =

    No it doesn't. An internetworki= ng protocol can't prescribe that kind of thing to lower level protocols= . An incoming and outgoing transfer could be sent using completely differen= t protocols and the financial agreement with the peers on those two routes = could be vastly different too.

    The only service ILP requires of lowe= r level protocols is that they can map a response to an original request. T= his requirement is okay because it is isolated to a single route/link at a = time not a requirement that crosses the inter-network boundary that ILP cro= sses.
    =C2=A0
    But because ILP allows for many different types of l= edgers, it doesn't make sense to assert how these are encoded.

    By putting them in the ILP packe= t you do the opposite. You make no assertions about how they are encoded if= they are used at lower layers, or how they may be combined with other cond= itions or even used to derive new conditions.

    IP doesn't= tell you how to encode an ethernet packet. It doesn't even know whethe= r it's going over a computer or a hand-written letter carried by a pige= on. IP takes for granted that you can send data over one connection by putt= ing it in a lower level.

    Correct, but if a link layer protocol wanted to look into the IP packet h= eaders of a packet it wants to transfer and use some data from there in its= internal logic (or even reuse data in it's own frame) that would be to= tally fine.
    =C2=A0
    Even though IP tells you how to chain these co= nnections together, it doesn't have to put the things it's chaining= on the internetworking level.

    IP doesn't tell you how to chain things together. IP simply def= ines the end-to end data envelope and address space. Because of this nodes = that implement the multiple lower layer protocols are able to push IP packe= ts down a link and expect the node on the other side to understand the head= ers and route it onward on another link.

    Everything neede= d by the IP module to decide what to do with the packet is in the IP packet= headers. i.e. Has it exceeded a TTL? Is there a route for this destination= ? Is it corrupted (checksum fails)? But also, everything that is needed by = the endpoint (like the source address) is also in there.

    = There is no dependency on nodes to be good citizens and always pass certain= other data from the lower layers into the next link. That would be breakin= g the layering.
    =C2=A0
    IP also assumes that if you get some incom= ing data on a connection you can copy it and send it out on the next connec= tion. Because you can already send data over a connection, all IP adds is t= he missing piece: a packet that tells you where to go.

    =
    With ILP, we assume that there is a way to prepare a conditional trans= fer, expire a conditional transfer, and fulfill a conditional transfer.

    No we don't! We assume= that if we deliver the packet as intended we'll get back a response pa= cket with a signature that matches the condition in the packet. So, if we h= ave an agreement with someone that they will pay us when we present that si= gnature then we are prepared to enter a similar agreement with the next pee= r because we expect that signature to come all the way back along the inter= ledger layer route..
    =C2=A0
    We also assume that if you get an inc= oming transfer you can create an outgoing transfer with the same condition.= The abstraction we made means that conditions and fulfillments are already= carried in the lower levels.

    That is a bad assumption that comes from the broken layering. What if= my outgoing link doesn't support conditional transfers? So now where d= o I put the condition?
    =C2=A0

    We could have assumed that no l= edgers ever support conditional transfers, and said the only thing ILP gets= from lower levels is the ability to send a transfer. But if we want to sup= port the case where any of them do, we have to keep the conditions and fulf= illments in the layer where they're actually used.

    I don't follow that logic at all. If we = want to support the case where any of them do then we must ensure the condi= tion and expiry are always carried in a consistent place at the internetwor= king layer so that if they do want to use them they know where to find them= .
    =C2=A0

    On Tue, Aug 15= , 2017 at 12:04 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote= :


    On 14 August 2017 at = 22:03, Evan Schwartz <evan@ripple.com> wrote:
    I think this thread is going to get extremely= unwieldy but here goes:

    >=C2=A0- All interledger layer messages should be ILP packets= (including fulfillments) and be capable of carrying higher layer protocol = payloads.

    Interledger has higher req= uirements than ILP for the lowest layer, specifically because we are carryi= ng money and not just data. One of the requirements is being able to transm= it a 32-byte fulfillment back along the same path that carried the payment = originally. If we expect this of the lower layer, I don't see a point i= n putting the fulfillment into an ILP packet and transmitting it as Interle= dger data along the same path. All ledger-layer protocols will need to inte= rpret the fulfillment passed in their protocol, not the one passed through = the Interledger layer.

    This i= s not correct. There is no requirement on ledger layer protocols to transmi= t or understand the fulfillment. You are looking at this through the lens o= f existing implementations from the bottom up instead of starting at the in= terledger layer.

    The primary funct= ion of the condition and fulfillment is as a signed end-to-end receipt. If = the sender agrees a condition with a receiver and then gets back the valid = fulfillment they don't care what happened in the middle. The receiver h= as signed a receipt saying they have their money.

    The value of using a standard for the receipt and signatur= e is that each transfer along the way CAN re-use it. One the one hand you c= an have a transfer between two peers that have zero trust and the ledger th= ey use supports conditional payments completely. On the other extreme you c= an have two peers that have a full trust and ignore the condition and fulfi= llment completely.
    =C2=A0
    The = ledger layer protocols carry ILP packets. Payment requests and either fulfi= llment or error responses. If a ledger layer protocol wants to use the cond= ition and fulfillment for their own operations they can extract these from = the ILP packets and use them.


    >=C2=A0- While it may make sense to split the interledger payment and interle= dger quoting protocols into new higher level protocols that seems like an u= nnecessary abstraction. Instead the packet definitions should just have som= e consistency and probably a common base/header.

    The current protocols effectively have this header but it = isn't separated out. There are two fields in the request header: type a= nd destination address. There is one field in the response header: type. I = don't think it makes that much of a big difference to separate these fi= elds if all of the fields in that packet need to be interpreted together (f= or example, you can't understand a quote request if you strip off the d= estination address).

    <= div>I agree that we don't HAVE to explicitly separate them out but I th= ink ti would make it clearer how the stack is architected if there was a he= ader that was consistent across all packets. Currently the only thing that = is consitent across all ILP packets is that they are defined int he same fi= le.
    =C2=A0

    <= /div>
    >=C2=A0- We should define two base ILP packet types: requ= est and response.

    Unless this adds some substan= tive benefit or new fields I don't think it's worth breaking all of= the formats we have just to rearrange things.

    The goal of this exercise is to tease out the best d= esign and ignore the cost of change until we can compare the results with t= he current design.
    =C2=A0

    >=C2=A0- ILP is not about ledgers, it is about trustli= nes between nodes/hosts.

    A ledger is any system that tracks accounts and balances. When you = use a trustline all of your messages still need to go through an accounting= system (such as the plugin in the JS implementation) and then on to the ot= her program logic.

    As a= bove, this is incorrect. There is no requirement for "all messages to = go through an accounting system".

    Since designing th= e first implementation of 5-bells ledger we have assumed that passing the I= LP packet MUST be done by the ledger because that is how we implemented it.= But that is not true. It is perfectly valid for the passing of an ILP pack= et from one peer to another to be simply an exchange of data.

    =
    The receiving peer makes a decision about whether or not to forward th= e packet based on the current financial position they have with the sending= peer.

    It is convenient if the ledger that rec= ords the net positions of the peers also forwards the messaging and even be= tter if it natively supports conditional payments and can use the condition= and the fulfillment from the ILP packet for those but that's all it is= , convenient.

    =C2=A0
    In that case, the plugin or whatever is = doing the accounting is the ledger. Digital value is always tracked in ledg= ers, so I think it does make sense to think of this as the base layer. The = reason to abstract the functionality you expect from the ledger layer is pr= ecisely so you can handle it in different ways, depending on what the under= lying systems provide.

    I see 3 ways to think of th= e layer(s) underpinning ILP:
    1. The "L= edger Layer" provides both messaging capabilities and some type of HTLA=
    2. There are separate plugins for messaging and for transfers = and when you peer with someone you have to agree on a plugin for each
      3. <= li>We standardize the messaging part and say that all goes over IP and then= just have more minimal plugins for the on-ledger settlements
    Number 1 is what we have and I think that still makes the most sense.

    I think you're confusing implement= ation details and defining of interfaces with definition of a protocol stac= k. The only differences between the tree examples you have above is in impl= ementation.

    From the perspective of the Interledger Protocol the imp= lementation of the lower layers is not important, that's the whole poin= t of layering. By forcing important aspects of ILP like the condition, fulf= illment and expiry down into those layers you muddy the waters and we now h= ave to standardize those protocols too. Instead we should just be defining = the functions they must provide and then leave it up to implementations to = provide those functions.

    I know we = want to define a standard to bootstrap the system (CLP) but that's misl= eading us into thinking it's an essential part of the stack. It's p= erfectly valid for two peers to not use CLP and still be part of the Interl= edger.

    That said, you raise an interesting consideration about the layer= s below ILP and actually I think it makes sense to split these.

    We keep trying to force messaging through the ledger layer and actua= lly that's the wrong place to put it if we can split the ledger layer i= nto a messaging layer and a ledger layer. That way we can stop trying to th= ink of all HLTAs as ledgers.

    A thought, why not use sub-l= ayers as is common in other stacks:

    1. Link layer: Layer = upon which two peers that have a direct link, or participate in the same pa= yment network, communicate
    2. Transfer/ ledger: Layer on whic= h financial positions between two peers are recorded

    This reflects t= he already emerging HTLA model and many of our existing plugins and ledger = integrations.
    Link Layer: XRP Paychan, Lightning
    Ledger Layer: XRP Ledger, Bitcoin

    This doesn= 't prevent us from defining a standard binary protocol that defines all= of the operations for both layers (like CLP) but I see value in distinguis= hing between these two.
    =C2=A0

    >=C2=A0<= span style=3D"color:rgb(33,33,33)">- The protocol should differentiate betw= een the operation of preparing a transfer on a ledger and the operation of = passing an ILP packet from one peer to another.

    The protocol assumes your conditional transf= er is underpinned by some HTLA. It doesn't care whether that's on-le= dger or not.

    What do you mean= when you say "the protocol"? In my statement I am referring to I= LP.
    My point above being that ILP expects ILP packets to be passed from= peer to peer but has no expectations about transfers.

    It's perfectly legal (from an ILP perspective) for = two peers to exchange ILP packets with no transfers. Clearly if a node rout= es a packet on and has no incoming transfer it's going to lose money bu= t that's a consideration for that node. It doesn't affect anyone el= se in the chain.

    ILP doesn't as= sume anything about transfers at all, let alone conditional transfers. It p= rovides useful semantics for conditional transfers to be used by two peers = to transact as part of a larger ILP payment.
    =C2=A0

    >=C2=A0= - The condition and timeout should be included in the ILP payment packet.

    I strongly disagree with this. We had= this debate a year ago and I was on your side but was convinced that this = is not a good idea.

    Yes,= I recall this and I'm sorry I didn't push harder on this point. Un= fortunately I think the decision to pull it out of the packet is mostly dri= ven by how our prototypes were implemented rather than good architecture.
    <= br>
    The layer below ILP must be capable of doing conditional tran= sfers based on sha256 hashlocks with 32-byte preimages.

    This is not true and I think it would be u= seful for us to agree on this as this seems to be the argument I am coming = up against most often. The peers participating in a transfer that is part o= f an ILP payment may wish to use conditional transfers as a way to enforce = their agreement but this is not a requirement of the protocol.

    The agreement between any two peers is: "I will pay you X if you= can provide a receipt that Y was paid Z before T".
    ILP = provides a standard for expressing this agreement so that these can be chai= ned together BUT it is not a requirement that every agreement in the chain = uses the condition, and fulfillment provided at the ILP layer.

    =C2=A0
    As= a result, the original condition and the corresponding preimage MUST be ex= pressed in that layer.

    = As I have shown above, this is not true.
    =C2=A0
    Then the question= is whether we should also include it in the packet that is forwarded. What= ultimately convinced me is the following: All connectors MUST ignore the c= ondition if it is in the packet, because they are only guaranteed their mon= ey back if they use the same condition from the incoming transfer they got.=

    = Here is where the layering is being corrupted.

    All connectors MUST i= nspect the condition in the ILP packet as part of their decision to route t= he packet or not.
    When the local transf= er module of the connectors stack passes the ILP packet up to the ILP modul= e it should indicate the properties of the incoming transfer that carried t= he packet.
    This is essential firstly so= that the routing logic in the ILP module can record the incoming transfer = identifier so it is able to use the correct response id when it passes back= the fulfillment or error.
    The other properties that the ILP module shou= ld look at are the condition and expiry on the incoming transfer.
    =

    If the incoming route uses c= onditional transfers and these are supposed to match the condition and expi= ry in the ILP packet then the ILP module should compare them and reject the= packet if:
    a) the conditions don't match OR
    b) the expiry is too short

    We should still discuss if t= he expiry should be set by the sender and left unchanged or used like a TTL= and decremented by each node.
    =C2=A0
    Also, the receiver will nee= d to take out the condition in order to hash the packet for PSK or IPR.

    This is completely normal.= Zeroing a checksum field in a header before calculating the checksum is VE= RY common precisely because it's long been accepted that the right plac= e to put that data is in the headers and the work of zero'ing it out to= calculate the checksum (or signature in our case) is not material.
    =C2=A0
    =
    So basically, no one wants the condition in there. It feels like = it ought to be in there, but literally none of the parties want the extra 3= 2 bytes in there.

    "= Nobody wants it there" is a terrible reason to abandon the correct des= ign. The whole purpose of a good architecture is you accept that there may = be cases in future that haven't been considered now so designing just f= or the known cases is a bad idea.

    Good architecture is no= t the same as optimization. Taking stuff out (even when it feels wrong) to = save a few bytes is a good sign that it's a bad idea.
    =C2=A0
    =
    The reason the timeout should not be in there is that there = isn't a single timeout for the payment. There are multiple separate tim= eouts for each of the bilateral transfers. Those must go in the individual = transfers and there is no sensible value to put in the Interledger packet.<= /div>
    =C2=A0
    As above, this is some= what equivalent to the TTL in an IP packet. I'm open to discussing if i= t should be a fixed value set by the sender where each node uses their own = value but has the sender-defined value as a reference or it is actually dec= remented at each hop.

    Either way, this is part of ILP not= the ledger layer just like the condition and fulfillment. It may be used b= y the ledger layer but that's implementation specific. It belongs in th= e ILP packet.
    =C2=A0

    =




    --
    Sent from a = mobile device, please excuse any typos



    --001a1142c36a57b8f405570cb9f6-- From nobody Fri Aug 18 13:14:06 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E36132320 for ; Fri, 18 Aug 2017 13:14:03 -0700 (PDT) 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 HS9RjTwVoUsL for ; Fri, 18 Aug 2017 13:13:58 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 A13E11320BB for ; Fri, 18 Aug 2017 13:13:57 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id b4so11641226qta.1 for ; Fri, 18 Aug 2017 13:13:57 -0700 (PDT) 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=9IaiVNg50adz4iWj1/sRz9qGpS+aOQG5uvo+/N7/N4o=; b=TuQkV7zfOHHB1PmDCLa+U6XXebhX63hy6SmXD5idPSV/am8O6I0EqS/mwtGbU8B0oS L4hB12hppVGKBxN5PgZDy03T3YhNKI7RZpLrLVBs5N6vGs0PQvcPCs6ub5SGc5x80LI5 08pukmvvK0DyKcmp4HFlI0GXDLtSOABzLoYuIGZi3IU0Ww6erLNRrm1xsRLOgDnglGyU wuf6Ff0GZzxDOpOgO8udrrbcAPgZou2kszldyJb5oqcVruv5NVCj15ngdpz5l33TkbCt gqKu6MkSg3QFS0nfR9i9Dy5vtGtXbBacB/DdzJr9gRg8a1L5eqP9gq6uPspR273+Po5r r2nw== 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=9IaiVNg50adz4iWj1/sRz9qGpS+aOQG5uvo+/N7/N4o=; b=JvfpY3OYM1cTOuwV3kbvD6wN9GOu86jNazSzS5QNN0AOt4rZVD9W22XPBIAyuiDPMP 6+PwsMbfa3PbBE7dZJN2ny7JPVylu32KpAubEDnuMKu1f83JSYhhMIuqSCyqnIrbtQNw CvRaHRnU4QeYgSK4VBvvejXksAwFYaeJ1yu96FaSuCV+K4VEatK7FGd1tgGkIQNRQ5gh rK+y6iUoEvBbIgarQEpb/dURhgGXXQ4fPaoTcmUv/4XM7/4ciaK1vLlpgGisVhs1xZZ7 IkQipbJthRplayhmI2Tx/Y6YC+k/duvmcBTij7iU05+nZ1+VMviGg553DmDBlGYDbSCf lGug== X-Gm-Message-State: AHYfb5iKx7n0nDuVGkCz7uxexNwWnSTtdiChMbqFWSoD7JecHS8++6RI HAhUk6sfJFp5z2h1b+HoToKhop4IMg== X-Received: by 10.237.56.228 with SMTP id k91mr13715914qte.146.1503087236559; Fri, 18 Aug 2017 13:13:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.145.100 with HTTP; Fri, 18 Aug 2017 13:13:55 -0700 (PDT) In-Reply-To: References: From: Andrew Bransford Brown Date: Fri, 18 Aug 2017 16:13:55 -0400 Message-ID: To: Adrian Hope-Bailie Cc: Ben Sharafian , Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1142c36acd38f005570cc4da" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 20:14:04 -0000 --001a1142c36acd38f005570cc4da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A standard up for review as part of NIST's Cybersecurity Framework: Only 3 commands are allowed to databases: Load, Store, and Delete. Proof of concept: http://systemdotpersistence.blogspot.com. Questions/comments welcome. On Fri, Aug 18, 2017 at 4:10 PM, Andrew Bransford Brown wrote: > If the human species survives, they'll say humans nearly went extinct, > because some liked to keep secrets (top secret, secret, classified). > > On Thu, Aug 17, 2017 at 1:32 PM, Adrian Hope-Bailie > wrote: > >> >> >> On 16 August 2017 at 10:22, Ben Sharafian wrote: >> >>> OK, I think in that case we're mostly disagreeing over where the >>> condition/fulfillment/expiry actually go in the data. >>> >> >> That's one way to look at it but that's ultimately what the architecting >> the layering is. Deciding at which layer (and therefor encapsulated in w= hat >> packet) certain data should be. >> >> >>> The reason I don't agree with your position is based on which parties I >>> think should be aware of ILP. >>> >> >> I don't think that's the right way to look at it. The connector needs to >> be able to understand at least the ILP layer data AND the lower layer da= ta. >> Normally the way the processing stack is implemented is that there is a >> module for each layer that processes the data from that layer and then >> passes the payload and any other important information up to the next la= yer. >> >> >>> In order to track the balance between each other accurately, the two >>> connectors have to keep track of conditions, fulfillments, and expiries= on >>> each of the transfers. >>> >> >> This is where I disagree with you. Two connectors exchanging a transfer >> only care about the data that is relevant to them for that transfer. It'= s >> quite possible for two connectors to perform a transfer that has no >> conditions or fulfillments or a transfer that has a different condition = and >> fulfillment (such as an atomic mode transfer where the condition is a >> compound one that has multiple sub-conditions). >> >> >>> That means the connectors' accounting logic that handles the conditions= , >>> fulfillments, and expiries is going to be using some information inside= the >>> ILP packet and some information outside of it in order to perform these >>> transfers. >>> >> >> It will only use info inside the packet if it uses conditional transfers >> that use that same condition. This is the most likely scenario but that = is >> not a protocol requirement. >> >> >>> >>> I think it's cleaner to say everything required to make these local >>> transfers should go in one protocol, so the accounting logic of these >>> connectors doesn't have to deal with ILP directly. >>> >> >> I strongly disagree with that. That's entirely the wrong reason to put >> data into a specific layer. The data in the ILP layer is there because i= t's >> "end-to-end" data. >> >> If a protocol at a lower layer wants to use that data then it must >> replicate it. That seems inefficient but it's the correct way to do it. >> >> One could define a lower layer protocol that doesn't replicate the data >> but the rules of the protocol are "Get the condition from the ILP packet= ". >> In that case, that specific lower level protocol is forcing implementati= ons >> to understand the ILP packet format, that's an implementation detail. >> >> Another lower layer protocol might take the condition from the ILP packe= t >> and re-encode it in a different form (like a base64ulr string or NI: uri= ) >> >> >>> Then the connectors' ILP-packet-related behavior can all be routing >>> related. >>> >> >> Routing requires looking at the condition, expiry and amount. A >> connector's routing logic shouldn't forward a packet if the expiry is to= o >> low or if the condition is obviously corrupted. >> >> If the protocols were designed correctly as I am proposing then another >> routing decision would be, is the condition that was used in the incomin= g >> transfer the same as the one used in the ILP packet? >> >> >> >>> This would add a few benefits; two connectors could perform non-ILP >>> conditional transfers between one another (which would be useful for >>> reconciliation and settlement), and could also allow two connectors to = use >>> more complex condition types (i.e. signatures for atomic mode) without >>> forcing us to support that in the ILP packet. >>> >> >> You seem to have this backwards. Both of these things are supported if >> the condition and expiry ARE in the ILP packet. Atomic mode is not >> supported in the ILP protocol it is supported in the lower layer transfe= r >> protocol. The ILP packet just contains the end-to-end condition (always = a >> SHA-256 hash) and then the local transfer can have a different condition >> that is derived from the condition in the ILP packet. >> >> >>> It also keeps the integrity of the ILP packet as something lower levels >>> don't modify; the connector has to modify the expiry in order to pass a= long >>> an ILP payment (they may not modify the expiry if they're using somethi= ng >>> like atomic mode, but then we have the issue with advanced condition ty= pes >>> not being supported in the ILP packet). >>> >> >> I think the expiry should always be the expiry set by the sender. It >> won't be changed. >> >>> >>> In the case where the ledger _does_ care about the condition and >>> fulfillment, the argument in favor of separating >>> condition/fulfillment/expiry from the rest of the packet is similar. >>> Because we don't control the features of all ledgers, we'll need our >>> plugins or ledger adapters to be aware of ILP. This makes it hard to >>> interact with any events that don't involve ILP packets, and impossible= to >>> handle features that extend beyond what we support in the ILP packet. W= e >>> could pass details about non-ILP ledger features (like a crypto conditi= on) >>> in the side data, but in the event of any redundancy we have to check t= he >>> ledger-supplied info, not the info in the ILP packet. >>> >> >> Comparing the condition in the local transfer and the one in the ILP >> packet should be part of the routing logic. >> >> >>> >>> Basically, condition/fulfillment/expiry are used for accounting local >>> transfers (even if they aren't being "ledger" enforced) in addition to >>> their role as every-hop information. By putting them in the ILP packet,= we >>> limit the special features that ledgers can support and make our softwa= re >>> abstractions harder to separate cleanly. By putting them in the local >>> transfer alongside the ILP packet but not inside it, we do separate the >>> data a little more, but we have more freedom in what the underlying >>> accounting and ledger logic can do, and our software modules will have = more >>> clearly separated domains. >>> >> >> They should be in both the local transfer AND the ILP packet if they are >> needed by the local transfer protocol. This allows the flexibility you >> desire because the local transfer protocol can do ANYTHING including usi= ng >> the condition from the ILP packet as-is, not at all or enhanced for >> something like atomic mode. >> >> >> >>> >>> On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie < >>> adrian@hopebailie.com> wrote: >>> >>>> Exactly =F0=9F=91=8D >>>> >>>> On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian >>>> wrote: >>>> >>>>> Ok, I think I have a better idea of what you're saying. >>>>> >>>>> It sounds like you're saying the ILP layer contains all information >>>>> that is common between every hop (destination, destination amount, op= aque >>>>> data, condition, fulfillment, expiry). The lower level would then be = used >>>>> for all the transfer-local details (source amount, next connector acc= ount, >>>>> custom/local data). >>>>> >>>>> If the lower level wanted to do anything related to the every-hop >>>>> payment, i.e. escrow funds until the receipt has been produced, it wo= uld >>>>> look into the ILP layer for that information. If the lower level didn= 't do >>>>> any escrow or expiries that require every-hop details, it would simpl= y >>>>> function as a communication method. >>>>> >>>>> Is that right? >>>>> >>>>> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >>>>> adrian@hopebailie.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 15 August 2017 at 16:00, Ben Sharafian >>>>>> wrote: >>>>>> >>>>>>> In that case, the plugin or whatever is doing the accounting is the >>>>>>>>>> ledger. Digital value is always tracked in ledgers, so I think i= t does make >>>>>>>>>> sense to think of this as the base layer. The reason to abstract= the >>>>>>>>>> functionality you expect from the ledger layer is precisely so y= ou can >>>>>>>>>> handle it in different ways, depending on what the underlying sy= stems >>>>>>>>>> provide. >>>>>>>>> >>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>> >>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>>>> some type of HTLA >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. There are separate plugins for messaging and for transfers >>>>>>>>> and when you peer with someone you have to agree on a plugin f= or each >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. We standardize the messaging part and say that all goes >>>>>>>>> over IP and then just have more minimal plugins for the on-led= ger >>>>>>>>> settlements >>>>>>>>> >>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>> sense. >>>>>>>> >>>>>>>> >>>>>>> I think you're confusing implementation details and defining of >>>>>>>> interfaces with definition of a protocol stack. The only differenc= es >>>>>>>> between the tree examples you have above is in implementation. >>>>>>> >>>>>>> >>>>>>> I had to scroll up after reading this to make sure it was @adrian >>>>>>> talking, because that seems like the opposite of what you were argu= ing for. >>>>>>> >>>>>> >>>>>> I don't think so. But I think that is part of the problem. We are no= t >>>>>> all focused on the same thing. I am actually not very interested in = CLP at >>>>>> all. It is one of potentially many protocols that may exist below th= e ILP >>>>>> layer. All we're doing by defining CLP is bootstrapping the network = by >>>>>> defining a protocol for everyone to use to get started. >>>>>> >>>>>> In designing the ILP layer properly we should try and forget >>>>>> everything we know about the lower layers other than what features w= e >>>>>> require of them. >>>>>> >>>>>> There is a misconception that ILP requires the lower layers to >>>>>> support conditional transfers, that is not true. >>>>>> >>>>>> All we actually need from a lower layer protocol is to transfer data >>>>>> back and forth and provide a way to reliably map requests to respons= es. >>>>>> >>>>>> What ILP provides lower layers is a way to reward your peer for >>>>>> passing on the packet. The Internetworking layer defines a condition= , a >>>>>> reward that must be paid to the receiver for the fulfillment and the= time >>>>>> allowed to claim this reward. >>>>>> >>>>>> Because of this, within lower-layer protocols that offer the basic >>>>>> request/response features we need, we could add conditional payment >>>>>> semantics that use the condition, expiry and fulfillment provided by= ILP. >>>>>> This would allow a node to offer a reward to their next peer to for >>>>>> delivering the packet they send them and to make the local financial >>>>>> transaction contingent on the end-to-end transaction. >>>>>> >>>>>> But crucially, adding that semantic to the lower layer protocol >>>>>> provides nothing extra to the ILP layer. The value is purely derived= from >>>>>> the two peers who use that protocol and can now use conditional paym= ents to >>>>>> protect themselves from their peers. >>>>>> >>>>>> >>>>>>> The proposal that you're arguing for is basically asserting that >>>>>>> we're going to be using CLP, because it makes the assumption that t= he >>>>>>> connectors (who understand ILP) are managing the HTLA logic. >>>>>>> >>>>>> >>>>>> Not at all. I am asserting that it doesn't matter what protocol you >>>>>> use below the ILP layer because it shouldn't matter. All of this tal= k about >>>>>> ILP being different because money is more important than data is non= sense. >>>>>> >>>>>> The difference between ILP and IP that makes ILP suitable for value >>>>>> transfer and IP not is at the internetworking layer. ILP requires th= at all >>>>>> packets are either a request or response and that the responses foll= ow the >>>>>> same path as the requests. Further ILP defines a signature scheme th= at >>>>>> gives the sender a way to be certain the request was received by the >>>>>> receiver. >>>>>> >>>>>> *This could be done entirely without money* but then there would be >>>>>> little incentive to sign the receipt or deliver the signature back t= o the >>>>>> original sender. >>>>>> >>>>>> So, if you add money then you add economic incentives to the mix. At >>>>>> each hop the sender promises the next upstream peer a payment if the= y can >>>>>> return the receipt. The net effect is that this can be used to trans= fer >>>>>> money from the sender to the receiver by simply defining up front th= e >>>>>> amount that the receiver must get to produce the signature. >>>>>> >>>>>> >>>>>>> >>>>>>> In the current model, the CLP/trustline model and the direct ledger >>>>>>> model both work without having to treat anything on the ILP layer >>>>>>> differently. We're favoring on-ledger messaging because of our >>>>>>> implementation, yes, but we've been able to switch most all of our = plugins >>>>>>> from on-ledger messaging to RPC-based messaging without changing th= e ILP >>>>>>> layer at all. >>>>>>> >>>>>>> With the ledger-level abstraction, we were able to switch from our >>>>>>> ledger-based mode of thinking to the CLP/trustline based way withou= t >>>>>>> changing anything other than the plugin. Your argument comes from a= n >>>>>>> assumption of a CLP-style ledger protocol with some underlying ledg= er, >>>>>>> which we can't assume is always the case. >>>>>>> >>>>>> >>>>>> I'm not sure what any of that proves tbh. These are all >>>>>> implementation concerns. They don't change the fact that the conditi= on, >>>>>> expiry and fulfillment are part of ILP not the lower layer protocols= . >>>>>> >>>>>>> >>>>>>> >>>>>>> From the perspective of the Interledger Protocol the implementation >>>>>>>> of the lower layers is not important, that's the whole point of la= yering. >>>>>>>> By forcing important aspects of ILP like the condition, fulfillmen= t and >>>>>>>> expiry down into those layers you muddy the waters and we now have= to >>>>>>>> standardize those protocols too. Instead we should just be definin= g the >>>>>>>> functions they must provide and then leave it up to implementation= s to >>>>>>>> provide those functions. >>>>>>> >>>>>>> >>>>>>> I don't agree with this point; the condition and fulfillment have >>>>>>> actual meaning to the ledger layer. >>>>>>> >>>>>> >>>>>> NO THEY DON'T! They have meaning to SOME ledgers that implement SOME >>>>>> lower layer protocols, IF they choose to use them. >>>>>> >>>>>> Excuse the shouting but this is the crux of the issue. We need to al= l >>>>>> agree that it is entirely possible for a transfer to be done that do= esn't >>>>>> use the condition and fulfillment and that if this was in the middle= of a >>>>>> 10-hop ILP payment it would have no effect on the sender and receive= r. >>>>>> >>>>>>> >>>>>>> You've said that the ledger often doesn't care about fulfillment an= d >>>>>>> condition, but the ledger _layer_'s (where transfers are done) role= is to >>>>>>> take in condition and fulfillment and make a transfer which satisfi= es its >>>>>>> HTLA. >>>>>>> >>>>>> >>>>>> No, the ledger's role is to keep a tab of net financial positions >>>>>> between two peers. It MAY use conditions and fulfillments that it pu= lls >>>>>> from the ILP layer to help it do that in a way both peers agree on. >>>>>> >>>>>> Note that a "layer" doesn't have a role. I think there is some >>>>>> confusion about the difference between layering the protocol and >>>>>> abstracting functionality into different components. >>>>>> >>>>>> >>>>>>> If the ledger layer has to look into the ILP packet to do so, that >>>>>>> is a blatant breaking of layering. >>>>>>> >>>>>> >>>>>> Not at all! The module acting at the layers *below* the >>>>>> internetworking layer shouldn't modify anything inside the packets o= f the >>>>>> higher layers but they can definitely inspect them and adjust their >>>>>> behavior based on what they to find. >>>>>> >>>>>> In fact the prevalence of this is the subject of a lot of debate at >>>>>> the IETF currently because endpoints are often encrypting their payl= oads >>>>>> and in some cases this makes it difficult for middle-boxes to be eff= ective >>>>>> at their jobs. >>>>>> >>>>>> By putting the condition, fulfillment, and expiry on the ledger >>>>>>> layer, we leave it open for any ledger type to work, rather than fo= rcing >>>>>>> all ledger-layer software to understand ILP. >>>>>>> >>>>>> >>>>>> Actually you do the opposite. You make it a requirement of every >>>>>> protocol below the ILP layer to define a way to carry these data ele= ments >>>>>> and encode and decode them, even if they don't use them >>>>>> >>>>>> Ledger layer components don't have to understand ILP unless they >>>>>> choose to re-use the condition for their own local transfer. Ledgers >>>>>> themselves *never* have to understand ILP. >>>>>> >>>>>> Remember a ledger layer protocol could use a completely different >>>>>> conditional payments scheme, like atomic mode ILP, where it takes th= e >>>>>> end-to-end condition and creates a new compound condition that depen= ds on >>>>>> the fulfillment and some notary signature. >>>>>> >>>>>> There will be a component in a connector's stack that must pass the >>>>>> ILP packet to the next peer. If it does this using a transfer protoc= ol that >>>>>> uses conditional transfers and wants to use the same condition as th= e ILP >>>>>> packet then it must decode the packet. >>>>>> >>>>>> But, it will likely do something with that condition before sending >>>>>> the transfer to the ledger like encoding it differently or rehashing= it >>>>>> (lightning?) so that it's in the form expected by the ledger. >>>>>> >>>>>> That's an implementation decision of the lower layer protocol used >>>>>> between those two peers. >>>>>> >>>>>> >>>>>>> >>>>>>> I agree that Interledger defines how conditions, fulfillments, and >>>>>>> expiries should be chained together, but it makes no assertions abo= ut their >>>>>>> data format. >>>>>>> >>>>>> >>>>>> ILP doesn't define how anything is chained together. From the >>>>>> perspective of ILP the condition and fulfillment are end-to-end data= . They >>>>>> are agreed by the two endpoints who don't care how they get from Ali= ce to >>>>>> Bob and back. >>>>>> >>>>>> The design of ILP is such that it facilitates the design of lower >>>>>> level protocols that can be used to carry the ILP packets across mul= tiple >>>>>> hops (networks) using economic incentives such that the sender pays = enough >>>>>> for the first hop to ensure that all nodes in between can extract th= e fee >>>>>> they want and the receiver will still get the amount they expected.. >>>>>> >>>>>> >>>>>> >>>>>>> ILP says you should send your outgoing transfer with the same >>>>>>> condition as the incoming one, and a lower expiry. >>>>>>> >>>>>> >>>>>> No it doesn't. An internetworking protocol can't prescribe that kind >>>>>> of thing to lower level protocols. An incoming and outgoing transfer= could >>>>>> be sent using completely different protocols and the financial agree= ment >>>>>> with the peers on those two routes could be vastly different too. >>>>>> >>>>>> The only service ILP requires of lower level protocols is that they >>>>>> can map a response to an original request. This requirement is okay = because >>>>>> it is isolated to a single route/link at a time not a requirement th= at >>>>>> crosses the inter-network boundary that ILP crosses. >>>>>> >>>>>> >>>>>>> But because ILP allows for many different types of ledgers, it >>>>>>> doesn't make sense to assert how these are encoded. >>>>>>> >>>>>> >>>>>> By putting them in the ILP packet you do the opposite. You make no >>>>>> assertions about how they are encoded if they are used at lower laye= rs, or >>>>>> how they may be combined with other conditions or even used to deriv= e new >>>>>> conditions. >>>>>> >>>>>>> >>>>>>> IP doesn't tell you how to encode an ethernet packet. It doesn't >>>>>>> even know whether it's going over a computer or a hand-written lett= er >>>>>>> carried by a pigeon. IP takes for granted that you can send data ov= er one >>>>>>> connection by putting it in a lower level. >>>>>>> >>>>>> >>>>>> Correct, but if a link layer protocol wanted to look into the IP >>>>>> packet headers of a packet it wants to transfer and use some data fr= om >>>>>> there in its internal logic (or even reuse data in it's own frame) t= hat >>>>>> would be totally fine. >>>>>> >>>>>> >>>>>>> Even though IP tells you how to chain these connections together, i= t >>>>>>> doesn't have to put the things it's chaining on the internetworking= level. >>>>>>> >>>>>> >>>>>> IP doesn't tell you how to chain things together. IP simply defines >>>>>> the end-to end data envelope and address space. Because of this node= s that >>>>>> implement the multiple lower layer protocols are able to push IP pac= kets >>>>>> down a link and expect the node on the other side to understand the = headers >>>>>> and route it onward on another link. >>>>>> >>>>>> Everything needed by the IP module to decide what to do with the >>>>>> packet is in the IP packet headers. i.e. Has it exceeded a TTL? Is t= here a >>>>>> route for this destination? Is it corrupted (checksum fails)? But al= so, >>>>>> everything that is needed by the endpoint (like the source address) = is also >>>>>> in there. >>>>>> >>>>>> There is no dependency on nodes to be good citizens and always pass >>>>>> certain other data from the lower layers into the next link. That wo= uld be >>>>>> breaking the layering. >>>>>> >>>>>> >>>>>>> IP also assumes that if you get some incoming data on a connection >>>>>>> you can copy it and send it out on the next connection. Because you= can >>>>>>> already send data over a connection, all IP adds is the missing pie= ce: a >>>>>>> packet that tells you where to go. >>>>>>> >>>>>>> With ILP, we assume that there is a way to prepare a conditional >>>>>>> transfer, expire a conditional transfer, and fulfill a conditional >>>>>>> transfer. >>>>>>> >>>>>> >>>>>> No we don't! We assume that if we deliver the packet as intended >>>>>> we'll get back a response packet with a signature that matches the >>>>>> condition in the packet. So, if we have an agreement with someone th= at they >>>>>> will pay us when we present that signature then we are prepared to e= nter a >>>>>> similar agreement with the next peer because we expect that signatur= e to >>>>>> come all the way back along the interledger layer route.. >>>>>> >>>>>> >>>>>>> We also assume that if you get an incoming transfer you can create >>>>>>> an outgoing transfer with the same condition. The abstraction we ma= de means >>>>>>> that conditions and fulfillments are already carried in the lower l= evels. >>>>>>> >>>>>> >>>>>> That is a bad assumption that comes from the broken layering. What i= f >>>>>> my outgoing link doesn't support conditional transfers? So now where= do I >>>>>> put the condition? >>>>>> >>>>>>> >>>>>>> >>>>>>> We could have assumed that no ledgers ever support conditional >>>>>>> transfers, and said the only thing ILP gets from lower levels is th= e >>>>>>> ability to send a transfer. But if we want to support the case wher= e any of >>>>>>> them do, we have to keep the conditions and fulfillments in the lay= er where >>>>>>> they're actually used. >>>>>>> >>>>>> >>>>>> I don't follow that logic at all. If we want to support the case >>>>>> where any of them do then we must ensure the condition and expiry ar= e >>>>>> always carried in a consistent place at the internetworking layer so= that >>>>>> if they do want to use them they know where to find them. >>>>>> >>>>>> >>>>>>> >>>>>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>>>>> adrian@hopebailie.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 14 August 2017 at 22:03, Evan Schwartz wrote: >>>>>>>> >>>>>>>>> I think this thread is going to get extremely unwieldy but here >>>>>>>>> goes: >>>>>>>>> >>>>>>>>> > - All interledger layer messages should be ILP packets >>>>>>>>> (including fulfillments) and be capable of carrying higher layer = protocol >>>>>>>>> payloads. >>>>>>>>> >>>>>>>>> Interledger has higher requirements than ILP for the lowest layer= , >>>>>>>>> specifically because we are carrying money and not just data. One= of the >>>>>>>>> requirements is being able to transmit a 32-byte fulfillment back= along the >>>>>>>>> same path that carried the payment originally. If we expect this = of the >>>>>>>>> lower layer, I don't see a point in putting the fulfillment into = an ILP >>>>>>>>> packet and transmitting it as Interledger data along the same pat= h. All >>>>>>>>> ledger-layer protocols will need to interpret the fulfillment pas= sed in >>>>>>>>> their protocol, not the one passed through the Interledger layer. >>>>>>>>> >>>>>>>> >>>>>>>> This is not correct. There is no requirement on ledger layer >>>>>>>> protocols to transmit or understand the fulfillment. You are looki= ng at >>>>>>>> this through the lens of existing implementations from the bottom = up >>>>>>>> instead of starting at the interledger layer. >>>>>>>> >>>>>>>> The primary function of the condition and fulfillment is as a >>>>>>>> signed end-to-end receipt. If the sender agrees a condition with a= receiver >>>>>>>> and then gets back the valid fulfillment they don't care what happ= ened in >>>>>>>> the middle. The receiver has signed a receipt saying they have the= ir money. >>>>>>>> >>>>>>>> The value of using a standard for the receipt and signature is tha= t >>>>>>>> each transfer along the way CAN re-use it. One the one hand you ca= n have a >>>>>>>> transfer between two peers that have zero trust and the ledger the= y use >>>>>>>> supports conditional payments completely. On the other extreme you= can have >>>>>>>> two peers that have a full trust and ignore the condition and fulf= illment >>>>>>>> completely. >>>>>>>> >>>>>>>> The ledger layer protocols carry ILP packets. Payment requests and >>>>>>>> either fulfillment or error responses. If a ledger layer protocol = wants to >>>>>>>> use the condition and fulfillment for their own operations they ca= n extract >>>>>>>> these from the ILP packets and use them. >>>>>>>> >>>>>>>> >>>>>>>>> > - While it may make sense to split the interledger payment and >>>>>>>>> interledger quoting protocols into new higher level protocols tha= t seems >>>>>>>>> like an unnecessary abstraction. Instead the packet definitions s= hould just >>>>>>>>> have some consistency and probably a common base/header. >>>>>>>>> >>>>>>>>> The current protocols effectively have this header but it isn't >>>>>>>>> separated out. There are two fields in the request header: type a= nd >>>>>>>>> destination address. There is one field in the response header: t= ype. I >>>>>>>>> don't think it makes that much of a big difference to separate th= ese fields >>>>>>>>> if all of the fields in that packet need to be interpreted togeth= er (for >>>>>>>>> example, you can't understand a quote request if you strip off th= e >>>>>>>>> destination address). >>>>>>>>> >>>>>>>> >>>>>>>> I agree that we don't HAVE to explicitly separate them out but I >>>>>>>> think ti would make it clearer how the stack is architected if the= re was a >>>>>>>> header that was consistent across all packets. Currently the only = thing >>>>>>>> that is consitent across all ILP packets is that they are defined = int he >>>>>>>> same file. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> > - We should define two base ILP packet types: request and >>>>>>>>> response. >>>>>>>>> >>>>>>>>> Unless this adds some substantive benefit or new fields I don't >>>>>>>>> think it's worth breaking all of the formats we have just to rear= range >>>>>>>>> things. >>>>>>>>> >>>>>>>> >>>>>>>> The goal of this exercise is to tease out the best design and >>>>>>>> ignore the cost of change until we can compare the results with th= e current >>>>>>>> design. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>>>>> nodes/hosts. >>>>>>>>> >>>>>>>>> A ledger is any system that tracks accounts and balances. When yo= u >>>>>>>>> use a trustline all of your messages still need to go through an = accounting >>>>>>>>> system (such as the plugin in the JS implementation) and then on = to the >>>>>>>>> other program logic. >>>>>>>>> >>>>>>>> >>>>>>>> As above, this is incorrect. There is no requirement for "all >>>>>>>> messages to go through an accounting system". >>>>>>>> >>>>>>>> Since designing the first implementation of 5-bells ledger we have >>>>>>>> assumed that passing the ILP packet MUST be done by the ledger bec= ause that >>>>>>>> is how we implemented it. But that is not true. It is perfectly va= lid for >>>>>>>> the passing of an ILP packet from one peer to another to be simply= an >>>>>>>> exchange of data. >>>>>>>> >>>>>>>> The receiving peer makes a decision about whether or not to forwar= d >>>>>>>> the packet based on the current financial position they have with = the >>>>>>>> sending peer. >>>>>>>> >>>>>>>> It is convenient if the ledger that records the net positions of >>>>>>>> the peers also forwards the messaging and even better if it native= ly >>>>>>>> supports conditional payments and can use the condition and the fu= lfillment >>>>>>>> from the ILP packet for those but that's all it is, convenient. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In that case, the plugin or whatever is doing the accounting is >>>>>>>>> the ledger. Digital value is always tracked in ledgers, so I thin= k it does >>>>>>>>> make sense to think of this as the base layer. The reason to abst= ract the >>>>>>>>> functionality you expect from the ledger layer is precisely so yo= u can >>>>>>>>> handle it in different ways, depending on what the underlying sys= tems >>>>>>>>> provide. >>>>>>>>> >>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>> >>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities and >>>>>>>>> some type of HTLA >>>>>>>>> >>>>>>>>> 2. There are separate plugins for messaging and for transfers >>>>>>>>> and when you peer with someone you have to agree on a plugin f= or each >>>>>>>>> 3. We standardize the messaging part and say that all goes >>>>>>>>> over IP and then just have more minimal plugins for the on-led= ger >>>>>>>>> settlements >>>>>>>>> >>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>> sense. >>>>>>>>> >>>>>>>> >>>>>>>> I think you're confusing implementation details and defining of >>>>>>>> interfaces with definition of a protocol stack. The only differenc= es >>>>>>>> between the tree examples you have above is in implementation. >>>>>>>> >>>>>>>> From the perspective of the Interledger Protocol the implementatio= n >>>>>>>> of the lower layers is not important, that's the whole point of la= yering. >>>>>>>> By forcing important aspects of ILP like the condition, fulfillmen= t and >>>>>>>> expiry down into those layers you muddy the waters and we now have= to >>>>>>>> standardize those protocols too. Instead we should just be definin= g the >>>>>>>> functions they must provide and then leave it up to implementation= s to >>>>>>>> provide those functions. >>>>>>>> >>>>>>>> I know we want to define a standard to bootstrap the system (CLP) >>>>>>>> but that's misleading us into thinking it's an essential part of t= he stack. >>>>>>>> It's perfectly valid for two peers to not use CLP and still be par= t of the >>>>>>>> Interledger. >>>>>>>> >>>>>>>> That said, you raise an interesting consideration about the layers >>>>>>>> below ILP and actually I think it makes sense to split these. >>>>>>>> >>>>>>>> We keep trying to force messaging through the ledger layer and >>>>>>>> actually that's the wrong place to put it if we can split the ledg= er layer >>>>>>>> into a messaging layer and a ledger layer. That way we can stop tr= ying to >>>>>>>> think of all HLTAs as ledgers. >>>>>>>> >>>>>>>> A thought, why not use sub-layers as is common in other stacks: >>>>>>>> >>>>>>>> 1. Link layer: Layer upon which two peers that have a direct link, >>>>>>>> or participate in the same payment network, communicate >>>>>>>> 2. Transfer/ ledger: Layer on which financial positions between tw= o >>>>>>>> peers are recorded >>>>>>>> >>>>>>>> This reflects the already emerging HTLA model and many of our >>>>>>>> existing plugins and ledger integrations. >>>>>>>> Link Layer: XRP Paychan, Lightning >>>>>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>>>>> >>>>>>>> This doesn't prevent us from defining a standard binary protocol >>>>>>>> that defines all of the operations for both layers (like CLP) but = I see >>>>>>>> value in distinguishing between these two. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> > - The protocol should differentiate between the operation of >>>>>>>>> preparing a transfer on a ledger and the operation of passing an = ILP packet >>>>>>>>> from one peer to another. >>>>>>>>> >>>>>>>>> The protocol assumes your conditional transfer is underpinned by >>>>>>>>> some HTLA >>>>>>>>> . >>>>>>>>> It doesn't care whether that's on-ledger or not. >>>>>>>>> >>>>>>>> >>>>>>>> What do you mean when you say "the protocol"? In my statement I am >>>>>>>> referring to ILP. >>>>>>>> My point above being that ILP expects ILP packets to be passed fro= m >>>>>>>> peer to peer but has no expectations about transfers. >>>>>>>> >>>>>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>>>>> exchange ILP packets with no transfers. Clearly if a node routes a= packet >>>>>>>> on and has no incoming transfer it's going to lose money but that'= s a >>>>>>>> consideration for that node. It doesn't affect anyone else in the = chain. >>>>>>>> >>>>>>>> ILP doesn't assume anything about transfers at all, let alone >>>>>>>> conditional transfers. It provides useful semantics for conditiona= l >>>>>>>> transfers to be used by two peers to transact as part of a larger = ILP >>>>>>>> payment. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> > - The condition and timeout should be included in the ILP >>>>>>>>> payment packet. >>>>>>>>> >>>>>>>>> I strongly disagree with this. We had this debate a year ago and = I >>>>>>>>> was on your side but was convinced that this is not a good idea. >>>>>>>>> >>>>>>>> >>>>>>>> Yes, I recall this and I'm sorry I didn't push harder on this >>>>>>>> point. Unfortunately I think the decision to pull it out of the pa= cket is >>>>>>>> mostly driven by how our prototypes were implemented rather than g= ood >>>>>>>> architecture. >>>>>>>> >>>>>>>>> >>>>>>>>> The layer below ILP must be capable of doing conditional transfer= s >>>>>>>>> based on sha256 hashlocks with 32-byte preimages. >>>>>>>>> >>>>>>>> >>>>>>>> This is not true and I think it would be useful for us to agree on >>>>>>>> this as this seems to be the argument I am coming up against most = often. >>>>>>>> The peers participating in a transfer that is part of an ILP payme= nt may >>>>>>>> wish to use conditional transfers as a way to enforce their agreem= ent but >>>>>>>> this is not a requirement of the protocol. >>>>>>>> >>>>>>>> The agreement between any two peers is: "I will pay you X if you >>>>>>>> can provide a receipt that Y was paid Z before T". >>>>>>>> ILP provides a standard for expressing this agreement so that thes= e >>>>>>>> can be chained together BUT it is not a requirement that every agr= eement in >>>>>>>> the chain uses the condition, and fulfillment provided at the ILP = layer. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> As a result, the original condition and the corresponding preimag= e >>>>>>>>> MUST be expressed in that layer. >>>>>>>>> >>>>>>>> >>>>>>>> As I have shown above, this is not true. >>>>>>>> >>>>>>>> >>>>>>>>> Then the question is whether we should also include it in the >>>>>>>>> packet that is forwarded. What ultimately convinced me is the fol= lowing: >>>>>>>>> All connectors MUST ignore the condition if it is in the packet, = because >>>>>>>>> they are only guaranteed their money back if they use the same co= ndition >>>>>>>>> from the incoming transfer they got. >>>>>>>>> >>>>>>>> >>>>>>>> Here is where the layering is being corrupted. >>>>>>>> >>>>>>>> All connectors MUST inspect the condition in the ILP packet as par= t >>>>>>>> of their decision to route the packet or not. >>>>>>>> When the local transfer module of the connectors stack passes the >>>>>>>> ILP packet up to the ILP module it should indicate the properties = of the >>>>>>>> incoming transfer that carried the packet. >>>>>>>> This is essential firstly so that the routing logic in the ILP >>>>>>>> module can record the incoming transfer identifier so it is able t= o use the >>>>>>>> correct response id when it passes back the fulfillment or error. >>>>>>>> The other properties that the ILP module should look at are the >>>>>>>> condition and expiry on the incoming transfer. >>>>>>>> >>>>>>>> If the incoming route uses conditional transfers and these are >>>>>>>> supposed to match the condition and expiry in the ILP packet then = the ILP >>>>>>>> module should compare them and reject the packet if: >>>>>>>> a) the conditions don't match OR >>>>>>>> b) the expiry is too short >>>>>>>> >>>>>>>> We should still discuss if the expiry should be set by the sender >>>>>>>> and left unchanged or used like a TTL and decremented by each node= . >>>>>>>> >>>>>>>> >>>>>>>>> Also, the receiver will need to take out the condition in order t= o >>>>>>>>> hash the packet for PSK or IPR. >>>>>>>>> >>>>>>>> >>>>>>>> This is completely normal. Zeroing a checksum field in a header >>>>>>>> before calculating the checksum is VERY common precisely because i= t's long >>>>>>>> been accepted that the right place to put that data is in the head= ers and >>>>>>>> the work of zero'ing it out to calculate the checksum (or signatur= e in our >>>>>>>> case) is not material. >>>>>>>> >>>>>>>> >>>>>>>>> So basically, no one wants the condition in there. It feels like >>>>>>>>> it ought to be in there, but literally none of the parties want t= he extra >>>>>>>>> 32 bytes in there. >>>>>>>>> >>>>>>>> >>>>>>>> "Nobody wants it there" is a terrible reason to abandon the correc= t >>>>>>>> design. The whole purpose of a good architecture is you accept tha= t there >>>>>>>> may be cases in future that haven't been considered now so designi= ng just >>>>>>>> for the known cases is a bad idea. >>>>>>>> >>>>>>>> Good architecture is not the same as optimization. Taking stuff ou= t >>>>>>>> (even when it feels wrong) to save a few bytes is a good sign that= it's a >>>>>>>> bad idea. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> The reason the timeout should not be in there is that there isn't >>>>>>>>> a single timeout for the payment. There are multiple separate tim= eouts for >>>>>>>>> each of the bilateral transfers. Those must go in the individual = transfers >>>>>>>>> and there is no sensible value to put in the Interledger packet. >>>>>>>>> >>>>>>>> >>>>>>>> As above, this is somewhat equivalent to the TTL in an IP packet. >>>>>>>> I'm open to discussing if it should be a fixed value set by the se= nder >>>>>>>> where each node uses their own value but has the sender-defined va= lue as a >>>>>>>> reference or it is actually decremented at each hop. >>>>>>>> >>>>>>>> Either way, this is part of ILP not the ledger layer just like the >>>>>>>> condition and fulfillment. It may be used by the ledger layer but = that's >>>>>>>> implementation specific. It belongs in the ILP packet. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> -- >>>> Sent from a mobile device, please excuse any typos >>>> >>> >>> >> > --001a1142c36acd38f005570cc4da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    A standard up for review as part of NIST's Cybers= ecurity Framework:=C2=A0 Only 3 commands are allowed to databases:=C2=A0 Lo= ad, Store, and Delete.


    Questions/comments welcome.

    On Fri,= Aug 18, 2017 at 4:10 PM, Andrew Bransford Brown <andrewbb@gmail.com&= gt; wrote:
    If the= human species survives, they'll say humans nearly went extinct, becaus= e some liked to keep secrets (top secret, secret, classified).

    On Thu, Aug 17, 2017 at 1:32 PM, Adrian Hope-Bailie <= adrian@hopebailie.com> wrote:


    On 16 August 2017 at 10:22, Ben Sharafian &l= t;sharafian@rippl= e.com> wrote:
    OK, I think in that case we're mostly disagreeing over where the con= dition/fulfillment/expiry actually go in the data.

    That's one way to look at it but th= at's ultimately what the architecting the layering is. Deciding at whic= h layer (and therefor encapsulated in what packet) certain data should be.<= br>
    =C2=A0
    The reason I don't agree with your position is based on which partie= s I think should be aware of ILP.
    I don't think that's the right way to look at it= . The connector needs to be able to understand at least the ILP layer data = AND the lower layer data. Normally the way the processing stack is implemen= ted is that there is a module for each layer that processes the data from t= hat layer and then passes the payload and any other important information u= p to the next layer.
    =C2=A0
    In order to track the balance between each ot= her accurately, the two connectors have to keep track of conditions, fulfil= lments, and expiries on each of the transfers.

    This is where I disagree with you. Two connectors = exchanging a transfer only care about the data that is relevant to them for= that transfer. It's quite possible for two connectors to perform a tra= nsfer that has no conditions or fulfillments or a transfer that has a diffe= rent condition and fulfillment (such as an atomic mode transfer where the c= ondition is a compound one that has multiple sub-conditions).
    =C2=A0
    That means t= he connectors' accounting logic that handles the conditions, fulfillmen= ts, and expiries is going to be using some information inside the ILP packe= t and some information outside of it in order to perform these transfers.

    It will only use i= nfo inside the packet if it uses conditional transfers that use that same c= ondition. This is the most likely scenario but that is not a protocol requi= rement.
    =C2=A0

    I think it's cleaner= to say everything required to make these local transfers should go in one = protocol, so the accounting logic of these connectors doesn't have to d= eal with ILP directly.

    I strongly disagree with that. That's entirely the wrong reason = to put data into a specific layer. The data in the ILP layer is there becau= se it's "end-to-end" data.

    If a protocol at= a lower layer wants to use that data then it must replicate it. That seems= inefficient but it's the correct way to do it.

    One c= ould define a lower layer protocol that doesn't replicate the data but = the rules of the protocol are "Get the condition from the ILP packet&q= uot;. In that case, that specific lower level protocol is forcing implement= ations to understand the ILP packet format, that's an implementation de= tail.

    Another lower layer protocol might take the conditi= on from the ILP packet and re-encode it in a different form (like a base64u= lr string or NI: uri)
    =C2=A0
    Then the connectors' ILP-packet-related behavior= can all be routing related.

    Routing requires looking at the condition, expiry and amount. = A connector's routing logic shouldn't forward a packet if the expir= y is too low or if the condition is obviously corrupted.

    = If the protocols were designed correctly as I am proposing then another rou= ting decision would be, is the condition that was used in the incoming tran= sfer the same as the one used in the ILP packet?

    <= /div>
    =C2=A0
    This woul= d add a few benefits; two connectors could perform non-ILP conditional tran= sfers between one another (which would be useful for reconciliation and set= tlement), and could also allow two connectors to use more complex condition= types (i.e. signatures for atomic mode) without forcing us to support that= in the ILP packet.

    <= div>You seem to have this backwards. Both of these things are supported if = the condition and expiry ARE in the ILP packet. Atomic mode is not supporte= d in the ILP protocol it is supported in the lower layer transfer protocol.= The ILP packet just contains the end-to-end condition (always a SHA-256 ha= sh) and then the local transfer can have a different condition that is deri= ved from the condition in the ILP packet.
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    It also keeps the integrity of t= he ILP packet as something lower levels don't modify; the connector has= to modify the expiry in order to pass along an ILP payment (they may not m= odify the expiry if they're using something like atomic mode, but then = we have the issue with advanced condition types not being supported in the = ILP packet).

    I think t= he expiry should always be the expiry set by the sender. It won't be ch= anged.

    In the case wh= ere the ledger _does_ care about the condition and fulfillment, the argumen= t in favor of separating condition/fulfillment/expiry from the rest of the = packet is similar. Because we don't control the features of all ledgers= , we'll need our plugins or ledger adapters to be aware of ILP. This ma= kes it hard to interact with any events that don't involve ILP packets,= and impossible to handle features that extend beyond what we support in th= e ILP packet. We could pass details about non-ILP ledger features (like a c= rypto condition) in the side data, but in the event of any redundancy we ha= ve to check the ledger-supplied info, not the info in the ILP packet.
    =

    Comparing the conditio= n in the local transfer and the one in the ILP packet should be part of the= routing logic.
    =C2=A0

    Basically, condi= tion/fulfillment/expiry are used for accounting local transfers (even if th= ey aren't being "ledger" enforced) in addition to their role = as every-hop information. By putting them in the ILP packet, we limit the s= pecial features that ledgers can support and make our software abstractions= harder to separate cleanly. By putting them in the local transfer alongsid= e the ILP packet but not inside it, we do separate the data a little more, = but we have more freedom in what the underlying accounting and ledger logic= can do, and our software modules will have more clearly separated domains.=

    They should be i= n both the local transfer AND the ILP packet if they are needed by the loca= l transfer protocol. This allows the flexibility you desire because the loc= al transfer protocol can do ANYTHING including using the condition from the= ILP packet as-is, not at all or enhanced for something like atomic mode.

    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

    On Tue, A= ug 15, 2017 at 10:24 AM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:
    Exactly =F0=9F=91=8D

    On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian <sharafian@ripple.com> wrote:
    =
    Ok, I think I have a better idea = of what you're saying.

    It sounds like you're say= ing the ILP layer contains all information that is common between every hop= (destination, destination amount, opaque data, condition, fulfillment, exp= iry). The lower level would then be used for all the transfer-local details= (source amount, next connector account, custom/local data).

    =
    If the lower level wanted to do anything related to the every-ho= p payment, i.e. escrow funds until the receipt has been produced, it would = look into the ILP layer for that information. If the lower level didn't= do any escrow or expiries that require every-hop details, it would simply = function as a communication method.

    Is that right?=

    On Tu= e, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    On 15 August 2017 at 16:00, Ben S= harafian <sharafian@ripple.com> wrote:
    In that case, the plugin or whatever is doing the accoun= ting is the ledger. Digital value is always tracked in ledgers, so I think = it does make sense to think of this as the base layer. The reason to abstra= ct the functionality you expect from the ledger layer is precisely so you c= an handle it in different ways, depending on what the underlying systems pr= ovide.
    I see 3 ways to think of the layer(s) underpinning ILP:<= ol>
  • The "Ledger Layer&q= uot; provides both messaging capabilities and some type of=C2=A0HTLA<= /li>
    1. There are separate plugins for = messaging and for transfers and when you peer with someone you have to agre= e on a plugin for each
    1. We stand= ardize the messaging part and say that all goes over IP and then just have = more minimal plugins for the on-ledger settlements
    Number 1 is wha= t we have and I think that still makes the most sense.

    • I think you're confusing implementation d= etails and defining of interfaces with definition of a protocol stack. The = only differences between the tree examples you have above is in implementat= ion.

    I had to scroll up after= reading this to make sure it was @adrian talking, because that seems like = the opposite of what you were arguing for.
    I don't think so. But I think that is part of the p= roblem. We are not all focused on the same thing. I am actually not very in= terested in CLP at all. It is one of potentially many protocols that may ex= ist below the ILP layer. All we're doing by defining CLP is bootstrappi= ng the network by defining a protocol for everyone to use to get started.
    In designing the ILP layer properly we should try and forg= et everything we know about the lower layers other than what features we re= quire of them.

    There is a misconception that ILP requires= the lower layers to support conditional transfers, that is not true.
    All we actually need from a lower layer protocol is to transfe= r data back and forth and provide a way to reliably map requests to respons= es.

    What ILP provides lower layers is a way to reward you= r peer for passing on the packet. The Internetworking layer defines a condi= tion, a reward that must be paid to the receiver for the fulfillment and th= e time allowed to claim this reward.

    Because o= f this, within lower-layer protocols that offer the basic request/response = features we need, we could add conditional payment semantics that use the c= ondition, expiry and fulfillment provided by ILP. This would allow a node t= o offer a reward to=C2=A0 their next peer to for delivering the packet they= send them and to make the local financial transaction contingent on the en= d-to-end transaction.

    But crucially, adding that semantic= to the lower layer protocol provides nothing extra to the ILP layer. The v= alue is purely derived from the two peers who use that protocol and can now= use conditional payments to protect themselves from their peers.
    =
    =C2=A0
    The proposal that you're arguing for is basically asserting tha= t we're going to be using CLP, because it makes the assumption that the= connectors (who understand ILP) are managing the HTLA logic.

    Not at all. I am asserting that it do= esn't matter what protocol you use below the ILP layer because it shoul= dn't matter. All of this talk about ILP being different because money i= s more important than data is nonsense.

    The difference between= ILP and IP that makes ILP suitable for value transfer and IP not is at the= internetworking layer. ILP requires that all packets are either a request = or response and that the responses follow the same path as the requests. Fu= rther ILP defines a signature scheme that gives the sender a way to be cert= ain the request was received by the receiver.

    This could be done entirely without money but then there = would be little incentive to sign the receipt or deliver the signature back= to the original sender.

    So, if you= add money then you add economic incentives to the mix. At each hop the sen= der promises the next upstream peer a payment if they can return the receip= t. The net effect is that this can be used to transfer money from the sende= r to the receiver by simply defining up front the amount that the receiver = must get to produce the signature.
    =C2= =A0

    In the current model, the CLP= /trustline model and the direct ledger model both work without having to tr= eat anything on the ILP layer differently. We're favoring on-ledger mes= saging because of our implementation, yes, but we've been able to switc= h most all of our plugins from on-ledger messaging to RPC-based messaging w= ithout changing the ILP layer at all.

    With the led= ger-level abstraction, we were able to switch from our ledger-based mode of= thinking to the CLP/trustline based way without changing anything other th= an the plugin. Your argument comes from an assumption of a CLP-style ledger= protocol with some underlying ledger, which we can't assume is always = the case.

    I'm not sure wh= at any of that proves tbh. These are all implementation concerns. They don&= #39;t change the fact that the condition, expiry and fulfillment are part o= f ILP not the lower layer protocols.
    <= span>=C2=A0
    From the perspective of the Interledger Protocol the implem= entation of the lower layers is not important, that's the whole point o= f layering. By forcing important aspects of ILP like the condition, fulfill= ment and expiry down into those layers you muddy the waters and we now have= to standardize those protocols too. Instead we should just be defining the= functions they must provide and then leave it up to implementations to pro= vide those functions.

    I don&#= 39;t agree with this point; the condition and fulfillment have actual meani= ng to the ledger layer.

    NO THEY DON'T! They have meaning to SOME ledgers that implement SOME l= ower layer protocols, IF they choose to use them.

    Excuse = the shouting but this is the crux of the issue. We need to all agree that i= t is entirely possible for a transfer to be done that doesn't use the c= ondition and fulfillment and that if this was in the middle of a 10-hop ILP= payment it would have no effect on the sender and receiver.
    =C2=A0
    You'= ve said that the ledger often doesn't care about fulfillment and condit= ion, but the ledger _layer_'s (where transfers are done) role is to tak= e in condition and fulfillment and make a transfer which satisfies its HTLA= .

    No, the ledger's role = is to keep a tab of net financial positions between two peers. It MAY use c= onditions and fulfillments that it pulls from the ILP layer to help it do t= hat in a way both peers agree on.

    N= ote that a "layer" doesn't have a role. I think there is some= confusion about the difference between layering the protocol and abstracti= ng functionality into different components.
    =C2=A0
    If the ledger layer has to look into= the ILP packet to do so, that is a blatant breaking of layering.

    Not at all! The module acting at= the layers below the internetworking layer shouldn't modify any= thing inside the packets of the higher layers but they can definitely inspe= ct them and adjust their behavior based on what they to find.

    = In fact the prevalence of this is the subject of a lot of debate at the IET= F currently because endpoints are often encrypting their payloads and in so= me cases this makes it difficult for middle-boxes to be effective at their = jobs.

    By putting the condition, fulfillment,= and expiry on the ledger layer, we leave it open for any ledger type to wo= rk, rather than forcing all ledger-layer software to understand ILP.
    <= /div>

    Actually you do the opposite. = You make it a requirement of every protocol below the ILP layer to define a= way to carry these data elements and encode and decode them, even if they = don't use them

    Ledger layer components don't have= to understand ILP unless they choose to re-use the condition for their own= local transfer. Ledgers themselves never have to understand ILP.
    Remember a ledger layer protocol could use a completely different con= ditional payments scheme, like atomic mode ILP, where it takes the end-to-e= nd condition and creates a new compound condition that depends on the fulfi= llment and some notary signature.

    There will be a compone= nt in a connector's stack that must pass the ILP packet to the next pee= r. If it does this using a transfer protocol that uses conditional transfer= s and wants to use the same condition as the ILP packet then it must decode= the packet.

    But, it will likely do something with that c= ondition before sending the transfer to the ledger like encoding it differe= ntly or rehashing it (lightning?) so that it's in the form expected by = the ledger.

    That's an implementation decis= ion of the lower layer protocol used between those two peers.
    =C2=A0
    <= div>
    I agree that Interledger defines how conditions, fulfill= ments, and expiries should be chained together, but it makes no assertions = about their data format.

    ILP doesn't define how anything is chained together. From the perspec= tive of ILP the condition and fulfillment are end-to-end data. They are agr= eed by the two endpoints who don't care how they get from Alice to Bob = and back.

    The design of ILP is such that it facilitates t= he design of lower level protocols that can be used to carry the ILP packet= s across multiple hops (networks) using economic incentives such that the s= ender pays enough for the first hop to ensure that all nodes in between can= extract the fee they want and the receiver will still get the amount they = expected..

    =C2=A0
    ILP says you should send your outgoing tran= sfer with the same condition as the incoming one, and a lower expiry.

    No it doesn't. An intern= etworking protocol can't prescribe that kind of thing to lower level pr= otocols. An incoming and outgoing transfer could be sent using completely d= ifferent protocols and the financial agreement with the peers on those two = routes could be vastly different too.

    The only service ILP requires = of lower level protocols is that they can map a response to an original req= uest. This requirement is okay because it is isolated to a single route/lin= k at a time not a requirement that crosses the inter-network boundary that = ILP crosses.
    =C2=A0
    But because ILP allows for many different typ= es of ledgers, it doesn't make sense to assert how these are encoded.

    By putting them in the IL= P packet you do the opposite. You make no assertions about how they are enc= oded if they are used at lower layers, or how they may be combined with oth= er conditions or even used to derive new conditions.

    IP does= n't tell you how to encode an ethernet packet. It doesn't even know= whether it's going over a computer or a hand-written letter carried by= a pigeon. IP takes for granted that you can send data over one connection = by putting it in a lower level.

    Correct, but if a link layer protocol wanted to look into the IP p= acket headers of a packet it wants to transfer and use some data from there= in its internal logic (or even reuse data in it's own frame) that woul= d be totally fine.
    =C2=A0
    Even though IP tells you how to chain t= hese connections together, it doesn't have to put the things it's c= haining on the internetworking level.

    IP doesn't tell you how to chain things together. IP sim= ply defines the end-to end data envelope and address space. Because of this= nodes that implement the multiple lower layer protocols are able to push I= P packets down a link and expect the node on the other side to understand t= he headers and route it onward on another link.

    Everythin= g needed by the IP module to decide what to do with the packet is in the IP= packet headers. i.e. Has it exceeded a TTL? Is there a route for this dest= ination? Is it corrupted (checksum fails)? But also, everything that is nee= ded by the endpoint (like the source address) is also in there.

    There is no dependency on nodes to be good citizens and always pass = certain other data from the lower layers into the next link. That would be = breaking the layering.
    =C2=A0
    IP also assumes that if you get som= e incoming data on a connection you can copy it and send it out on the next= connection. Because you can already send data over a connection, all IP ad= ds is the missing piece: a packet that tells you where to go.
    With ILP, we assume that there is a way to prepare a conditiona= l transfer, expire a conditional transfer, and fulfill a conditional transf= er.

    No we don't! We= assume that if we deliver the packet as intended we'll get back a resp= onse packet with a signature that matches the condition in the packet. So, = if we have an agreement with someone that they will pay us when we present = that signature then we are prepared to enter a similar agreement with the n= ext peer because we expect that signature to come all the way back along th= e interledger layer route..
    =C2=A0
    We also assume that if you get= an incoming transfer you can create an outgoing transfer with the same con= dition. The abstraction we made means that conditions and fulfillments are = already carried in the lower levels.

    That is a bad assumption that comes from the broken layering. = What if my outgoing link doesn't support conditional transfers? So now = where do I put the condition?
    =C2=A0

    We could have assumed th= at no ledgers ever support conditional transfers, and said the only thing I= LP gets from lower levels is the ability to send a transfer. But if we want= to support the case where any of them do, we have to keep the conditions a= nd fulfillments in the layer where they're actually used.

    I don't follow that logic at all.= If we want to support the case where any of them do then we must ensure th= e condition and expiry are always carried in a consistent place at the inte= rnetworking layer so that if they do want to use them they know where to fi= nd them.
    <= div>=C2=A0

    On Tue, Aug 15, = 2017 at 12:04 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:<= br>


    On 14 August 2017 at 22:= 03, Evan Schwartz <evan@ripple.com> wrote:
    I think this thread is going to get extremely un= wieldy but here goes:

    >=C2=A0- All interledger layer messages should be ILP packets (i= ncluding fulfillments) and be capable of carrying higher layer protocol pay= loads.

    Interledger has higher requir= ements than ILP for the lowest layer, specifically because we are carrying = money and not just data. One of the requirements is being able to transmit = a 32-byte fulfillment back along the same path that carried the payment ori= ginally. If we expect this of the lower layer, I don't see a point in p= utting the fulfillment into an ILP packet and transmitting it as Interledge= r data along the same path. All ledger-layer protocols will need to interpr= et the fulfillment passed in their protocol, not the one passed through the= Interledger layer.

    This is n= ot correct. There is no requirement on ledger layer protocols to transmit o= r understand the fulfillment. You are looking at this through the lens of e= xisting implementations from the bottom up instead of starting at the inter= ledger layer.

    The primary function= of the condition and fulfillment is as a signed end-to-end receipt. If the= sender agrees a condition with a receiver and then gets back the valid ful= fillment they don't care what happened in the middle. The receiver has = signed a receipt saying they have their money.

    The value of using a standard for the receipt and signature is = that each transfer along the way CAN re-use it. One the one hand you can ha= ve a transfer between two peers that have zero trust and the ledger they us= e supports conditional payments completely. On the other extreme you can ha= ve two peers that have a full trust and ignore the condition and fulfillmen= t completely.
    =C2=A0
    The ledge= r layer protocols carry ILP packets. Payment requests and either fulfillmen= t or error responses. If a ledger layer protocol wants to use the condition= and fulfillment for their own operations they can extract these from the I= LP packets and use them.


    >=C2=A0= - While it may make sense to split the interledger payment and interledger = quoting protocols into new higher level protocols that seems like an unnece= ssary abstraction. Instead the packet definitions should just have some con= sistency and probably a common base/header.

    The current protocols effectively have this header but it isn&#= 39;t separated out. There are two fields in the request header: type and de= stination address. There is one field in the response header: type. I don&#= 39;t think it makes that much of a big difference to separate these fields = if all of the fields in that packet need to be interpreted together (for ex= ample, you can't understand a quote request if you strip off the destin= ation address).

    I= agree that we don't HAVE to explicitly separate them out but I think t= i would make it clearer how the stack is architected if there was a header = that was consistent across all packets. Currently the only thing that is co= nsitent across all ILP packets is that they are defined int he same file.
    =C2=A0

    =
    >=C2=A0- We should define two base ILP packet types: request an= d response.

    Unless this a= dds some substantive benefit or new fields I don't think it's worth= breaking all of the formats we have just to rearrange things.
    <= /blockquote>

    The goal of this exercise is to teas= e out the best design and ignore the cost of change until we can compare th= e results with the current design.
    =C2=A0

    &g= t;=C2=A0- ILP is not about ledgers, it = is about trustlines between nodes/hosts.

    A ledger is any system that tracks accounts and bal= ances. When you use a trustline all of your messages still need to go throu= gh an accounting system (such as the plugin in the JS implementation) and t= hen on to the other program logic.

    =
    As above, this is incorrect. There is no requirement for "= all messages to go through an accounting system".

    Si= nce designing the first implementation of 5-bells ledger we have assumed th= at passing the ILP packet MUST be done by the ledger because that is how we= implemented it. But that is not true. It is perfectly valid for the passin= g of an ILP packet from one peer to another to be simply an exchange of dat= a.

    The receiving peer makes a decision about whether or n= ot to forward the packet based on the current financial position they have = with the sending peer.

    It is convenient if the= ledger that records the net positions of the peers also forwards the messa= ging and even better if it natively supports conditional payments and can u= se the condition and the fulfillment from the ILP packet for those but that= 's all it is, convenient.

    =C2=A0
    In that case, the plugin= or whatever is doing the accounting is the ledger. Digital value is always= tracked in ledgers, so I think it does make sense to think of this as the = base layer. The reason to abstract the functionality you expect from the le= dger layer is precisely so you can handle it in different ways, depending o= n what the underlying systems provide.

    I see 3 way= s to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messaging capabilities an= d some type of HTLA
    2. There are separate plugins for messagin= g and for transfers and when you peer with someone you have to agree on a p= lugin for each
    3. We standardize the messaging part and say that all g= oes over IP and then just have more minimal plugins for the on-ledger settl= ements
    Number 1 is what we have and I think that still makes = the most sense.

    I think you're= confusing implementation details and defining of interfaces with definitio= n of a protocol stack. The only differences between the tree examples you h= ave above is in implementation.

    From the perspective of the Interled= ger Protocol the implementation of the lower layers is not important, that&= #39;s the whole point of layering. By forcing important aspects of ILP like= the condition, fulfillment and expiry down into those layers you muddy the= waters and we now have to standardize those protocols too. Instead we shou= ld just be defining the functions they must provide and then leave it up to= implementations to provide those functions.

    I know we want to define a standard to bootstrap the system (CLP)= but that's misleading us into thinking it's an essential part of t= he stack. It's perfectly valid for two peers to not use CLP and still b= e part of the Interledger.

    That said, you raise an interesting considera= tion about the layers below ILP and actually I think it makes sense to spli= t these.

    We keep trying to force messaging through the le= dger layer and actually that's the wrong place to put it if we can spli= t the ledger layer into a messaging layer and a ledger layer. That way we c= an stop trying to think of all HLTAs as ledgers.

    A though= t, why not use sub-layers as is common in other stacks:

    1= . Link layer: Layer upon which two peers that have a direct link, or partic= ipate in the same payment network, communicate
    2. Transfer/ l= edger: Layer on which financial positions between two peers are recorded
    This reflects the already emerging HTLA model and many of our existing= plugins and ledger integrations.
    Link Layer: XRP Paychan, Li= ghtning
    Ledger Layer: XRP Ledger, Bitcoin

    <= /div>
    This doesn't prevent us from defining a standard binary proto= col that defines all of the operations for both layers (like CLP) but I see= value in distinguishing between these two.
    =C2=A0

    >=C2=A0- The protocol should = differentiate between the operation of preparing a transfer on a ledger and= the operation of passing an ILP packet from one peer to another.
    The protocol assumes your = conditional transfer is underpinned by some HTLA. It doesn't care whethe= r that's on-ledger or not.

    What do you mean when you say "the protocol"? In my statement I= am referring to ILP.
    My point above being that ILP expects ILP packets= to be passed from peer to peer but has no expectations about transfers.
    It's perfectly legal (from an ILP= perspective) for two peers to exchange ILP packets with no transfers. Clea= rly if a node routes a packet on and has no incoming transfer it's goin= g to lose money but that's a consideration for that node. It doesn'= t affect anyone else in the chain.

    = ILP doesn't assume anything about transfers at all, let alone condition= al transfers. It provides useful semantics for conditional transfers to be = used by two peers to transact as part of a larger ILP payment.
    =C2=A0

    >=C2=A0- The condition and timeout should be included in the ILP = payment packet.

    I strongly disagree = with this. We had this debate a year ago and I was on your side but was con= vinced that this is not a good idea.

    Yes, I recall this and I'm sorry I didn't push harder = on this point. Unfortunately I think the decision to pull it out of the pac= ket is mostly driven by how our prototypes were implemented rather than goo= d architecture.

    The layer below ILP must be capable of doing= conditional transfers based on sha256 hashlocks with 32-byte preimages.

    This is not true and I th= ink it would be useful for us to agree on this as this seems to be the argu= ment I am coming up against most often. The peers participating in a transf= er that is part of an ILP payment may wish to use conditional transfers as = a way to enforce their agreement but this is not a requirement of the proto= col.

    The agreement between any two peers is: "I will= pay you X if you can provide a receipt that Y was paid Z before T".
    ILP provides a standard for expressing this agreement so that = these can be chained together BUT it is not a requirement that every agreem= ent in the chain uses the condition, and fulfillment provided at the ILP la= yer.

    =C2=A0
    As a result, the original condition and the corresponding pr= eimage MUST be expressed in that layer.

    <= /div>
    As I have shown above, this is not true.
    =C2=A0
    = Then the question is whether we should also include it in the packet that i= s forwarded. What ultimately convinced me is the following: All connectors = MUST ignore the condition if it is in the packet, because they are only gua= ranteed their money back if they use the same condition from the incoming t= ransfer they got.

    Here is where the layering is being corrupted.

    All = connectors MUST inspect the condition in the ILP packet as part of their de= cision to route the packet or not.
    When= the local transfer module of the connectors stack passes the ILP packet up= to the ILP module it should indicate the properties of the incoming transf= er that carried the packet.
    This is ess= ential firstly so that the routing logic in the ILP module can record the i= ncoming transfer identifier so it is able to use the correct response id wh= en it passes back the fulfillment or error.
    The other properties that th= e ILP module should look at are the condition and expiry on the incoming tr= ansfer.

    If the inco= ming route uses conditional transfers and these are supposed to match the c= ondition and expiry in the ILP packet then the ILP module should compare th= em and reject the packet if:
    a) the conditions don't matc= h OR
    b) the expiry is too short

    We should s= till discuss if the expiry should be set by the sender and left unchanged o= r used like a TTL and decremented by each node.
    =C2=A0<= /div>
    Also, the = receiver will need to take out the condition in order to hash the packet fo= r PSK or IPR.

    This is c= ompletely normal. Zeroing a checksum field in a header before calculating t= he checksum is VERY common precisely because it's long been accepted th= at the right place to put that data is in the headers and the work of zero&= #39;ing it out to calculate the checksum (or signature in our case) is not = material.
    =C2=A0
    So basically, no one wants the condition in ther= e. It feels like it ought to be in there, but literally none of the parties= want the extra 32 bytes in there.

    <= /span>
    "Nobody wants it there" is a terrible reason to abando= n the correct design. The whole purpose of a good architecture is you accep= t that there may be cases in future that haven't been considered now so= designing just for the known cases is a bad idea.

    Good a= rchitecture is not the same as optimization. Taking stuff out (even when it= feels wrong) to save a few bytes is a good sign that it's a bad idea.<= br>
    =C2=A0

    The reason the timeout should not be in the= re is that there isn't a single timeout for the payment. There are mult= iple separate timeouts for each of the bilateral transfers. Those must go i= n the individual transfers and there is no sensible value to put in the Int= erledger packet.
    =C2=A0
    As ab= ove, this is somewhat equivalent to the TTL in an IP packet. I'm open t= o discussing if it should be a fixed value set by the sender where each nod= e uses their own value but has the sender-defined value as a reference or i= t is actually decremented at each hop.

    Either way, this i= s part of ILP not the ledger layer just like the condition and fulfillment.= It may be used by the ledger layer but that's implementation specific.= It belongs in the ILP packet.
    =C2=A0


    <= /div>



    <= div dir=3D"ltr">--
    Sent from a mobile device, please excuse an= y typos




    --001a1142c36acd38f005570cc4da-- From nobody Fri Aug 18 14:39:25 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DF2132350 for ; Fri, 18 Aug 2017 14:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ripple.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 5_CzZrC4ZcU2 for ; Fri, 18 Aug 2017 14:39:14 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 A360B13234C for ; Fri, 18 Aug 2017 14:39:13 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id t201so8846371wmt.1 for ; Fri, 18 Aug 2017 14:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LrCVu7oBdFmav1mdbEDedfQq4nleNLnhbwZbOwAt8yY=; b=PGPW8CiutGTV/33pUOMyI/VX/m9+3ewlMmz3CGUe39gJEfNP49DZaI9b7Pq7FMigv3 n37qtHIMBu5/2FTvKJKUG9u6lxve02lhJhc6kEmBS9q3QYK1Ct2zI8I+2NocM6ZwU82a THb/DbDe/wCVqyWoYkAbYhWtTXXCE6A1QQ3OA= 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=LrCVu7oBdFmav1mdbEDedfQq4nleNLnhbwZbOwAt8yY=; b=fYM/LdaulIBqhfhjjG+SE0yxMEtmSfcEfVdTOrQQKNTtUAdU1MTW4XBwCgzI1cqY8K oUTGCj14uttFx05YHqlE12NFpqdvHTrPlXSTIdh9iO5sxK80HX1O2PIS3ib7RZGQOkEW aaV1xMHr4QAYoLD7IOtEkfCPjmRoWyIER9E1HcZI1onH6GUylwiIja4//ViDQGV06SUf i6rln1pzFJa+W6r/C/lKwFU6lbjT5ZDj4gxIPdMDmjYMlMxJMETAExsmWcflm99XtoDh 8XPXDnHiTRrXIpjhkIv0QxOfFun9WwtbMWRxXGzz3muBJwC15GYO0f7ejKINAv+V9woN xnRA== X-Gm-Message-State: AHYfb5g+QtkGLJnBNiYr1dHfNGRhwJDvstnleJ6FGxnHRNK5r9z3Nx5N /NSZ2xEVH168lXZljU9+e4ryKclY167T X-Received: by 10.28.10.131 with SMTP id 125mr2514150wmk.132.1503092351784; Fri, 18 Aug 2017 14:39:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.60.135 with HTTP; Fri, 18 Aug 2017 14:39:10 -0700 (PDT) In-Reply-To: References: From: Ben Sharafian Date: Fri, 18 Aug 2017 23:39:10 +0200 Message-ID: To: Adrian Hope-Bailie Cc: Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a11442d84b177bc05570df5f4" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 21:39:22 -0000 --001a11442d84b177bc05570df5f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > My point is that it goes beyond that. ILP doesn't care if the layer below > even has a concept of HTLAs. I can do ILP over Bitcoin without the overla= y > layer if I want to but I need to find a peer that is prepared to do that > with me. Because that's not how you build a protocol stack. A protocol stack is not > defined through interfaces. It's defined through layers of data where eac= h > layer has a standard packet format with headers carrying data for that > layer and encapsulates the data of layer(s) above in the payload. I guess we're just using the term "doing ILP" differently. When I say it I'm referring to the flow with prepare/fulfill/reject on a sha256 condition. If I'm understanding you correctly, you mean it to refer to the data format; anything that gets the ILP packet to the destination via peering or ledger connections counts as ILP. On Fri, Aug 18, 2017 at 10:07 PM, Adrian Hope-Bailie wrote: > > > On 18 August 2017 at 15:09, Ben Sharafian wrote: > >> What you're describing is an implementation of a local transfer service >>> that doesn't (or can't) take advantage of Interledger. In fact, this wi= ll >>> be the norm for most existing payment networks that we want to add to t= he >>> Interledger and this is where your work on payment channels and HTLAs c= omes >>> in to play. >> >> >> >>> >>> If you have a local transfer channel that doesn't support conditions >>> natively or supports them in a way that requires some adaption you can >>> create an overlay network that does what's needed. Example: Bitcoin is = not >>> a suitable network to use for ILP so we use a payment channel between t= he >>> peers that is underwritten by Bitcoin. >> >> >> Exactly, when I say you need a to handle the condition and fulfillment >> via a clearing layer, this "overlay network" is what I'm referring to. T= he >> whole point of an HTLA is that from ILP's point of view it's just a >> lower-level protocol that can commit conditional transfers and fulfill >> them. ILP doesn't care how the ledger/HTLA works under the hood, whether >> it's a clearing/overlay layer or a "real" ledger. >> > > My point is that it goes beyond that. ILP doesn't care if the layer below > even has a concept of HTLAs. I can do ILP over Bitcoin without the overla= y > layer if I want to but I need to find a peer that is prepared to do that > with me. > > In that case all I have to do is send them the ILP packet in a message > that says I owe them some Bitcoin. the "owe them some Bitcoin" isn't bein= g > enforced anywhere using an HTLA. > >> >> >> You're equating this "overlay network," which is a type of ledger, with >> the ILP layer. >> > > Not at all. I agree with what you have below. It's a layer that exists > below ILP but above the actual ledger. But crucially it's not a requireme= nt > for ILP to work so the protocol should depend on it existing. > > >> If there is an overlay network that handles the condition and >> fulfillment, that means you _are_ using a ledger, because the overlay >> network _is_ a ledger. The ILP layer is a layer above this. >> > > Agreed. > >> >> If we assume the ILP packet is well defined with all the ILP-required >>> data elements then when a lower layer wants to use that data it can but >>> should do it in a way that doesn't break the ILP layer for everyone els= e. >>> How that is implemented in practice will depend on the lower layer prot= ocol. >> >> >> That's one way to see it, but what I'm wondering is why that's a better >> model than saying there's a clearly defined interface that the ledger-la= yer >> exposes, and then building the ILP layer on top of that. >> > > Because that's not how you build a protocol stack. A protocol stack is no= t > defined through interfaces. It's defined through layers of data where eac= h > layer has a standard packet format with headers carrying data for that > layer and encapsulates the data of layer(s) above in the payload. > > The condition, fulfillment and expiry are part of ILP so they belong in > the ILP packet. If there are lower layers that want to use those things > then they can but ILP shouldn't depend on that. > > >> >> Unless the next hop is backwards >> >> >> There's no reason to send a backwards hop. If you don't want to forward = a >> payment you reject it. >> > > That's what I mean by a backwards hop. I was illustrating my point that > validating a packet is part of the routing decision. > > >> >> Not at all. You're assuming that there is no expiry on the local >>> transfer. As a receiving node I have an incoming transfer with an expir= y >>> and it carries an ILP packet that also has an expiry. >> >> >> If that's what you're talking about, the ILP packet already has an >> expiry. It's implemented in the PSK details so the receiver knows whethe= r >> the packet it issued is still valid. But that's an application layer >> concern, because it's only the receiver who looks at the ILP packet's >> expiry. The connectors only need to know the expiries of the local >> transfers. >> > > There is a big misconception in your statement. The expiry is an > end-to-end concern, or as you put it the sender sets and "the receiver > looks at the ILP packet's expiry". That's why it's in the ILP packet. > > The idea that anything to be exchanged end-to-end must be in higher layer= s > is completely wrong. The reason you'd put something in a higher layer > payload is because the endpoints have agreed to use a higher layer protoc= ol > that requires it to be there. > > >> On Fri, Aug 18, 2017 at 3:21 PM, Adrian Hope-Bailie < >> adrian@hopebailie.com> wrote: >> >>> >>> >>> On 18 August 2017 at 10:38, Ben Sharafian wrote: >>> >>>> Two connectors exchanging a transfer only care about the data that is >>>>> relevant to them for that transfer. It's quite possible for two conne= ctors >>>>> to perform a transfer that has no conditions or fulfillments or a tra= nsfer >>>>> that has a different condition and fulfillment (such as an atomic mod= e >>>>> transfer where the condition is a compound one that has multiple >>>>> sub-conditions). >>>> >>>> >>>> Yes, two connectors could absolutely send an unconditional transfer on >>>> an underlying ledger in order to settle an Interledger payment. But in >>>> order to benefit from any of Interledger's guarantees (trustless >>>> connectors, retry-ability, etc.), they MUST keep a conditional local >>>> transfer, at least for clearing. If the local transfer cannot time out= , it >>>> cannot be safely retried. If the local transfer clears without a >>>> fulfillment, it loses the "receipt or your money back" property. Yes, = two >>>> parties in the chain could eschew these benefits but that is no longer= a >>>> correct implementation of Interledger. >>>> >>> >>> Aha! That is where I disagree! Interledger is not implemented at the >>> local transfer layer, it is implemented at the Interledger layer. The w= hole >>> point is that it an Interledger payment can travel over payment network= s >>> that know nothing about ILP but the greatest value comes from using one= s >>> that do. >>> >>> What you're describing is an implementation of a local transfer service >>> that doesn't (or can't) take advantage of Interledger. In fact, this wi= ll >>> be the norm for most existing payment networks that we want to add to t= he >>> Interledger and this is where your work on payment channels and HTLAs c= omes >>> in to play. >>> >>> If you have a local transfer channel that doesn't support conditions >>> natively or supports them in a way that requires some adaption you can >>> create an overlay network that does what's needed. Example: Bitcoin is = not >>> a suitable network to use for ILP so we use a payment channel between t= he >>> peers that is underwritten by Bitcoin. >>> >>> >>>> >>>> If a protocol at a lower layer wants to use that data then it must >>>>> replicate it. That seems inefficient but it's the correct way to do i= t. >>>> >>>> >>>> What's the actual reasoning behind this, and why is it considered the >>>> correct approach? If there's some IETF document that says this I'd lik= e to >>>> see it, because it intuitively feels wrong to have lower level abstrac= tions >>>> looking into higher levels. >>>> >>> >>> The data in the ILP layer is there for a specific reason. It's part of >>> an end-to-end exchange between the sender and receiver. >>> >>> >>> *Side note: It's unusual to be designing the whole stack at once so we >>> keep being tempted to move things around but in reality we should look = at >>> the ILP layer in isolation and make sure it is complete. Alternatively = we >>> should try to test our design against a number of lower and upper layer >>> protocols to make sure our thinking is sound.* >>> If we assume the ILP packet is well defined with all the ILP-required >>> data elements then when a lower layer wants to use that data it can but >>> should do it in a way that doesn't break the ILP layer for everyone els= e. >>> How that is implemented in practice will depend on the lower layer >>> protocol. >>> >>> >>>> >>>> Routing requires looking at the condition, expiry and amount. A >>>>> connector's routing logic shouldn't forward a packet if the expiry is= too >>>>> low or if the condition is obviously corrupted. >>>> >>>> >>>> Those are validity checks and you're right that they are performed in >>>> the connector, but the destination account, destination amount, and da= ta >>>> are enough to figure out what the best next hop is. >>>> >>> >>> Unless the next hop is backwards >>> >>> >>>> >>>> The ILP Packet's purpose is to describe where a payment is going. >>>> >>> >>> Not only that. For comparison, an IP packet does a lot more than just >>> describe where a packet is going. All end-to-end concerns need to be in >>> there too. >>> >>> >>>> The data it carries is only for the purpose of making sure the receive= r >>>> can identify that payment. >>>> >>> >>> No, the condition is there so the receiver can ensure it is sending bac= k >>> the correct fulfillment and the expiry to give the receiver some assura= nce >>> that the packet is still worth processing. >>> >>> >>>> In that context, the expiry has no bearing on where it will be routed >>>> nor on how much to route, only on whether or not an individual connect= or >>>> will take the risk of forwarding it. >>>> >>>> The ILP packet just contains the end-to-end condition (always a SHA-25= 6 >>>>> hash) and then the local transfer can have a different condition that= is >>>>> derived from the condition in the ILP packet. >>>> >>>> >>>> Fair enough; in your case you can transmit the condition twice and >>>> verify the structure of the complex local condition, and in the >>>> no-condition-in-ILP version you can verify the structure of the local >>>> condition and extract the SHA256 condition to pass on. >>>> >>>> I think the expiry should always be the expiry set by the sender. It >>>>> won't be changed. >>>> >>>> >>>> That increases connector risk enormously, allowing anybody to cause a >>>> connector to lose money by submitting a fulfillment at the last moment= . >>>> >>> >>> Not at all. You're assuming that there is no expiry on the local >>> transfer. As a receiving node I have an incoming transfer with an expir= y >>> and it carries an ILP packet that also has an expiry. >>> >>> My routing logic should look at both and decide a) if this is safe to >>> route on (i.e. put some of my own capital at risk) and b) what expiry t= o >>> set on the next hop. >>> >>> There is no incentive to change the expiry in the packet as this can >>> only be targeted at upstream connectors and the result will simply be t= hat >>> the payment is declined and the upstream local transfer rolls back. >>> >>> >>>> If an attacker knows enough about latency in the chain, they could eve= n >>>> target this attack at somebody many hops away. Staggering expiries (gi= ving >>>> you a minimum amount of time to fulfill a source transfer) is an easy >>>> mitigation against this attack; we shouldn't take it out. >>>> >>> >>> I agree. We would still have the local expiry. >>> >>> >>>> >>>> Comparing the condition in the local transfer and the one in the ILP >>>>> packet should be part of the routing logic. >>>> >>>> >>>> Sure, it can be done as an extra validity check, but it's just more >>>> code and more attack surface. I still don't see any tangible benefit >>>> from doing the layering in this way, aside from your assertion that it= 's >>>> the correct way to do it. If you've read any documents that explain wh= y >>>> this is the correct way to do layering, I think I'd understand you bet= ter. >>>> >>>> >>>> On Thu, Aug 17, 2017 at 7:32 PM, Adrian Hope-Bailie < >>>> adrian@hopebailie.com> wrote: >>>> >>>>> >>>>> >>>>> On 16 August 2017 at 10:22, Ben Sharafian >>>>> wrote: >>>>> >>>>>> OK, I think in that case we're mostly disagreeing over where the >>>>>> condition/fulfillment/expiry actually go in the data. >>>>>> >>>>> >>>>> That's one way to look at it but that's ultimately what the >>>>> architecting the layering is. Deciding at which layer (and therefor >>>>> encapsulated in what packet) certain data should be. >>>>> >>>>> >>>>>> The reason I don't agree with your position is based on which partie= s >>>>>> I think should be aware of ILP. >>>>>> >>>>> >>>>> I don't think that's the right way to look at it. The connector needs >>>>> to be able to understand at least the ILP layer data AND the lower la= yer >>>>> data. Normally the way the processing stack is implemented is that th= ere is >>>>> a module for each layer that processes the data from that layer and t= hen >>>>> passes the payload and any other important information up to the next= layer. >>>>> >>>>> >>>>>> In order to track the balance between each other accurately, the two >>>>>> connectors have to keep track of conditions, fulfillments, and expir= ies on >>>>>> each of the transfers. >>>>>> >>>>> >>>>> This is where I disagree with you. Two connectors exchanging a >>>>> transfer only care about the data that is relevant to them for that >>>>> transfer. It's quite possible for two connectors to perform a transfe= r that >>>>> has no conditions or fulfillments or a transfer that has a different >>>>> condition and fulfillment (such as an atomic mode transfer where the >>>>> condition is a compound one that has multiple sub-conditions). >>>>> >>>>> >>>>>> That means the connectors' accounting logic that handles the >>>>>> conditions, fulfillments, and expiries is going to be using some >>>>>> information inside the ILP packet and some information outside of it= in >>>>>> order to perform these transfers. >>>>>> >>>>> >>>>> It will only use info inside the packet if it uses conditional >>>>> transfers that use that same condition. This is the most likely scena= rio >>>>> but that is not a protocol requirement. >>>>> >>>>> >>>>>> >>>>>> I think it's cleaner to say everything required to make these local >>>>>> transfers should go in one protocol, so the accounting logic of thes= e >>>>>> connectors doesn't have to deal with ILP directly. >>>>>> >>>>> >>>>> I strongly disagree with that. That's entirely the wrong reason to pu= t >>>>> data into a specific layer. The data in the ILP layer is there becaus= e it's >>>>> "end-to-end" data. >>>>> >>>>> If a protocol at a lower layer wants to use that data then it must >>>>> replicate it. That seems inefficient but it's the correct way to do i= t. >>>>> >>>>> One could define a lower layer protocol that doesn't replicate the >>>>> data but the rules of the protocol are "Get the condition from the IL= P >>>>> packet". In that case, that specific lower level protocol is forcing >>>>> implementations to understand the ILP packet format, that's an >>>>> implementation detail. >>>>> >>>>> Another lower layer protocol might take the condition from the ILP >>>>> packet and re-encode it in a different form (like a base64ulr string = or NI: >>>>> uri) >>>>> >>>>> >>>>>> Then the connectors' ILP-packet-related behavior can all be routing >>>>>> related. >>>>>> >>>>> >>>>> Routing requires looking at the condition, expiry and amount. A >>>>> connector's routing logic shouldn't forward a packet if the expiry is= too >>>>> low or if the condition is obviously corrupted. >>>>> >>>>> If the protocols were designed correctly as I am proposing then >>>>> another routing decision would be, is the condition that was used in = the >>>>> incoming transfer the same as the one used in the ILP packet? >>>>> >>>>> >>>>> >>>>>> This would add a few benefits; two connectors could perform non-ILP >>>>>> conditional transfers between one another (which would be useful for >>>>>> reconciliation and settlement), and could also allow two connectors = to use >>>>>> more complex condition types (i.e. signatures for atomic mode) witho= ut >>>>>> forcing us to support that in the ILP packet. >>>>>> >>>>> >>>>> You seem to have this backwards. Both of these things are supported i= f >>>>> the condition and expiry ARE in the ILP packet. Atomic mode is not >>>>> supported in the ILP protocol it is supported in the lower layer tran= sfer >>>>> protocol. The ILP packet just contains the end-to-end condition (alwa= ys a >>>>> SHA-256 hash) and then the local transfer can have a different condit= ion >>>>> that is derived from the condition in the ILP packet. >>>>> >>>>> >>>>>> It also keeps the integrity of the ILP packet as something lower >>>>>> levels don't modify; the connector has to modify the expiry in order= to >>>>>> pass along an ILP payment (they may not modify the expiry if they're= using >>>>>> something like atomic mode, but then we have the issue with advanced >>>>>> condition types not being supported in the ILP packet). >>>>>> >>>>> >>>>> I think the expiry should always be the expiry set by the sender. It >>>>> won't be changed. >>>>> >>>>>> >>>>>> In the case where the ledger _does_ care about the condition and >>>>>> fulfillment, the argument in favor of separating >>>>>> condition/fulfillment/expiry from the rest of the packet is similar. >>>>>> Because we don't control the features of all ledgers, we'll need our >>>>>> plugins or ledger adapters to be aware of ILP. This makes it hard to >>>>>> interact with any events that don't involve ILP packets, and impossi= ble to >>>>>> handle features that extend beyond what we support in the ILP packet= . We >>>>>> could pass details about non-ILP ledger features (like a crypto cond= ition) >>>>>> in the side data, but in the event of any redundancy we have to chec= k the >>>>>> ledger-supplied info, not the info in the ILP packet. >>>>>> >>>>> >>>>> Comparing the condition in the local transfer and the one in the ILP >>>>> packet should be part of the routing logic. >>>>> >>>>> >>>>>> >>>>>> Basically, condition/fulfillment/expiry are used for accounting loca= l >>>>>> transfers (even if they aren't being "ledger" enforced) in addition = to >>>>>> their role as every-hop information. By putting them in the ILP pack= et, we >>>>>> limit the special features that ledgers can support and make our sof= tware >>>>>> abstractions harder to separate cleanly. By putting them in the loca= l >>>>>> transfer alongside the ILP packet but not inside it, we do separate = the >>>>>> data a little more, but we have more freedom in what the underlying >>>>>> accounting and ledger logic can do, and our software modules will ha= ve more >>>>>> clearly separated domains. >>>>>> >>>>> >>>>> They should be in both the local transfer AND the ILP packet if they >>>>> are needed by the local transfer protocol. This allows the flexibilit= y you >>>>> desire because the local transfer protocol can do ANYTHING including = using >>>>> the condition from the ILP packet as-is, not at all or enhanced for >>>>> something like atomic mode. >>>>> >>>>> >>>>> >>>>>> >>>>>> On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie < >>>>>> adrian@hopebailie.com> wrote: >>>>>> >>>>>>> Exactly =F0=9F=91=8D >>>>>>> >>>>>>> On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian >>>>>>> wrote: >>>>>>> >>>>>>>> Ok, I think I have a better idea of what you're saying. >>>>>>>> >>>>>>>> It sounds like you're saying the ILP layer contains all informatio= n >>>>>>>> that is common between every hop (destination, destination amount,= opaque >>>>>>>> data, condition, fulfillment, expiry). The lower level would then = be used >>>>>>>> for all the transfer-local details (source amount, next connector = account, >>>>>>>> custom/local data). >>>>>>>> >>>>>>>> If the lower level wanted to do anything related to the every-hop >>>>>>>> payment, i.e. escrow funds until the receipt has been produced, it= would >>>>>>>> look into the ILP layer for that information. If the lower level d= idn't do >>>>>>>> any escrow or expiries that require every-hop details, it would si= mply >>>>>>>> function as a communication method. >>>>>>>> >>>>>>>> Is that right? >>>>>>>> >>>>>>>> On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie < >>>>>>>> adrian@hopebailie.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 15 August 2017 at 16:00, Ben Sharafian >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> In that case, the plugin or whatever is doing the accounting is >>>>>>>>>>>>> the ledger. Digital value is always tracked in ledgers, so I = think it does >>>>>>>>>>>>> make sense to think of this as the base layer. The reason to = abstract the >>>>>>>>>>>>> functionality you expect from the ledger layer is precisely s= o you can >>>>>>>>>>>>> handle it in different ways, depending on what the underlying= systems >>>>>>>>>>>>> provide. >>>>>>>>>>>> >>>>>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>>>>> >>>>>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities >>>>>>>>>>>> and some type of HTLA >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1. There are separate plugins for messaging and for >>>>>>>>>>>> transfers and when you peer with someone you have to agree = on a plugin for >>>>>>>>>>>> each >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 1. We standardize the messaging part and say that all goes >>>>>>>>>>>> over IP and then just have more minimal plugins for the on-= ledger >>>>>>>>>>>> settlements >>>>>>>>>>>> >>>>>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>>>>> sense. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I think you're confusing implementation details and defining of >>>>>>>>>>> interfaces with definition of a protocol stack. The only differ= ences >>>>>>>>>>> between the tree examples you have above is in implementation. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I had to scroll up after reading this to make sure it was @adria= n >>>>>>>>>> talking, because that seems like the opposite of what you were a= rguing for. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I don't think so. But I think that is part of the problem. We are >>>>>>>>> not all focused on the same thing. I am actually not very interes= ted in CLP >>>>>>>>> at all. It is one of potentially many protocols that may exist be= low the >>>>>>>>> ILP layer. All we're doing by defining CLP is bootstrapping the n= etwork by >>>>>>>>> defining a protocol for everyone to use to get started. >>>>>>>>> >>>>>>>>> In designing the ILP layer properly we should try and forget >>>>>>>>> everything we know about the lower layers other than what feature= s we >>>>>>>>> require of them. >>>>>>>>> >>>>>>>>> There is a misconception that ILP requires the lower layers to >>>>>>>>> support conditional transfers, that is not true. >>>>>>>>> >>>>>>>>> All we actually need from a lower layer protocol is to transfer >>>>>>>>> data back and forth and provide a way to reliably map requests to= responses. >>>>>>>>> >>>>>>>>> What ILP provides lower layers is a way to reward your peer for >>>>>>>>> passing on the packet. The Internetworking layer defines a condit= ion, a >>>>>>>>> reward that must be paid to the receiver for the fulfillment and = the time >>>>>>>>> allowed to claim this reward. >>>>>>>>> >>>>>>>>> Because of this, within lower-layer protocols that offer the basi= c >>>>>>>>> request/response features we need, we could add conditional payme= nt >>>>>>>>> semantics that use the condition, expiry and fulfillment provided= by ILP. >>>>>>>>> This would allow a node to offer a reward to their next peer to = for >>>>>>>>> delivering the packet they send them and to make the local financ= ial >>>>>>>>> transaction contingent on the end-to-end transaction. >>>>>>>>> >>>>>>>>> But crucially, adding that semantic to the lower layer protocol >>>>>>>>> provides nothing extra to the ILP layer. The value is purely deri= ved from >>>>>>>>> the two peers who use that protocol and can now use conditional p= ayments to >>>>>>>>> protect themselves from their peers. >>>>>>>>> >>>>>>>>> >>>>>>>>>> The proposal that you're arguing for is basically asserting that >>>>>>>>>> we're going to be using CLP, because it makes the assumption tha= t the >>>>>>>>>> connectors (who understand ILP) are managing the HTLA logic. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Not at all. I am asserting that it doesn't matter what protocol >>>>>>>>> you use below the ILP layer because it shouldn't matter. All of t= his talk >>>>>>>>> about ILP being different because money is more important than da= ta is >>>>>>>>> nonsense. >>>>>>>>> >>>>>>>>> The difference between ILP and IP that makes ILP suitable for >>>>>>>>> value transfer and IP not is at the internetworking layer. ILP re= quires >>>>>>>>> that all packets are either a request or response and that the re= sponses >>>>>>>>> follow the same path as the requests. Further ILP defines a signa= ture >>>>>>>>> scheme that gives the sender a way to be certain the request was = received >>>>>>>>> by the receiver. >>>>>>>>> >>>>>>>>> *This could be done entirely without money* but then there would >>>>>>>>> be little incentive to sign the receipt or deliver the signature = back to >>>>>>>>> the original sender. >>>>>>>>> >>>>>>>>> So, if you add money then you add economic incentives to the mix. >>>>>>>>> At each hop the sender promises the next upstream peer a payment = if they >>>>>>>>> can return the receipt. The net effect is that this can be used t= o transfer >>>>>>>>> money from the sender to the receiver by simply defining up front= the >>>>>>>>> amount that the receiver must get to produce the signature. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> In the current model, the CLP/trustline model and the direct >>>>>>>>>> ledger model both work without having to treat anything on the I= LP layer >>>>>>>>>> differently. We're favoring on-ledger messaging because of our >>>>>>>>>> implementation, yes, but we've been able to switch most all of o= ur plugins >>>>>>>>>> from on-ledger messaging to RPC-based messaging without changing= the ILP >>>>>>>>>> layer at all. >>>>>>>>>> >>>>>>>>>> With the ledger-level abstraction, we were able to switch from >>>>>>>>>> our ledger-based mode of thinking to the CLP/trustline based way= without >>>>>>>>>> changing anything other than the plugin. Your argument comes fro= m an >>>>>>>>>> assumption of a CLP-style ledger protocol with some underlying l= edger, >>>>>>>>>> which we can't assume is always the case. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I'm not sure what any of that proves tbh. These are all >>>>>>>>> implementation concerns. They don't change the fact that the cond= ition, >>>>>>>>> expiry and fulfillment are part of ILP not the lower layer protoc= ols. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From the perspective of the Interledger Protocol the >>>>>>>>>>> implementation of the lower layers is not important, that's the= whole point >>>>>>>>>>> of layering. By forcing important aspects of ILP like the condi= tion, >>>>>>>>>>> fulfillment and expiry down into those layers you muddy the wat= ers and we >>>>>>>>>>> now have to standardize those protocols too. Instead we should = just be >>>>>>>>>>> defining the functions they must provide and then leave it up t= o >>>>>>>>>>> implementations to provide those functions. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't agree with this point; the condition and fulfillment hav= e >>>>>>>>>> actual meaning to the ledger layer. >>>>>>>>>> >>>>>>>>> >>>>>>>>> NO THEY DON'T! They have meaning to SOME ledgers that implement >>>>>>>>> SOME lower layer protocols, IF they choose to use them. >>>>>>>>> >>>>>>>>> Excuse the shouting but this is the crux of the issue. We need to >>>>>>>>> all agree that it is entirely possible for a transfer to be done = that >>>>>>>>> doesn't use the condition and fulfillment and that if this was in= the >>>>>>>>> middle of a 10-hop ILP payment it would have no effect on the sen= der and >>>>>>>>> receiver. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> You've said that the ledger often doesn't care about fulfillment >>>>>>>>>> and condition, but the ledger _layer_'s (where transfers are don= e) role is >>>>>>>>>> to take in condition and fulfillment and make a transfer which s= atisfies >>>>>>>>>> its HTLA. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No, the ledger's role is to keep a tab of net financial positions >>>>>>>>> between two peers. It MAY use conditions and fulfillments that it= pulls >>>>>>>>> from the ILP layer to help it do that in a way both peers agree o= n. >>>>>>>>> >>>>>>>>> Note that a "layer" doesn't have a role. I think there is some >>>>>>>>> confusion about the difference between layering the protocol and >>>>>>>>> abstracting functionality into different components. >>>>>>>>> >>>>>>>>> >>>>>>>>>> If the ledger layer has to look into the ILP packet to do so, >>>>>>>>>> that is a blatant breaking of layering. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Not at all! The module acting at the layers *below* the >>>>>>>>> internetworking layer shouldn't modify anything inside the packet= s of the >>>>>>>>> higher layers but they can definitely inspect them and adjust the= ir >>>>>>>>> behavior based on what they to find. >>>>>>>>> >>>>>>>>> In fact the prevalence of this is the subject of a lot of debate >>>>>>>>> at the IETF currently because endpoints are often encrypting thei= r payloads >>>>>>>>> and in some cases this makes it difficult for middle-boxes to be = effective >>>>>>>>> at their jobs. >>>>>>>>> >>>>>>>>> By putting the condition, fulfillment, and expiry on the ledger >>>>>>>>>> layer, we leave it open for any ledger type to work, rather than= forcing >>>>>>>>>> all ledger-layer software to understand ILP. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Actually you do the opposite. You make it a requirement of every >>>>>>>>> protocol below the ILP layer to define a way to carry these data = elements >>>>>>>>> and encode and decode them, even if they don't use them >>>>>>>>> >>>>>>>>> Ledger layer components don't have to understand ILP unless they >>>>>>>>> choose to re-use the condition for their own local transfer. Ledg= ers >>>>>>>>> themselves *never* have to understand ILP. >>>>>>>>> >>>>>>>>> Remember a ledger layer protocol could use a completely different >>>>>>>>> conditional payments scheme, like atomic mode ILP, where it takes= the >>>>>>>>> end-to-end condition and creates a new compound condition that de= pends on >>>>>>>>> the fulfillment and some notary signature. >>>>>>>>> >>>>>>>>> There will be a component in a connector's stack that must pass >>>>>>>>> the ILP packet to the next peer. If it does this using a transfer= protocol >>>>>>>>> that uses conditional transfers and wants to use the same conditi= on as the >>>>>>>>> ILP packet then it must decode the packet. >>>>>>>>> >>>>>>>>> But, it will likely do something with that condition before >>>>>>>>> sending the transfer to the ledger like encoding it differently o= r >>>>>>>>> rehashing it (lightning?) so that it's in the form expected by th= e ledger. >>>>>>>>> >>>>>>>>> That's an implementation decision of the lower layer protocol use= d >>>>>>>>> between those two peers. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I agree that Interledger defines how conditions, fulfillments, >>>>>>>>>> and expiries should be chained together, but it makes no asserti= ons about >>>>>>>>>> their data format. >>>>>>>>>> >>>>>>>>> >>>>>>>>> ILP doesn't define how anything is chained together. From the >>>>>>>>> perspective of ILP the condition and fulfillment are end-to-end d= ata. They >>>>>>>>> are agreed by the two endpoints who don't care how they get from = Alice to >>>>>>>>> Bob and back. >>>>>>>>> >>>>>>>>> The design of ILP is such that it facilitates the design of lower >>>>>>>>> level protocols that can be used to carry the ILP packets across = multiple >>>>>>>>> hops (networks) using economic incentives such that the sender pa= ys enough >>>>>>>>> for the first hop to ensure that all nodes in between can extract= the fee >>>>>>>>> they want and the receiver will still get the amount they expecte= d.. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> ILP says you should send your outgoing transfer with the same >>>>>>>>>> condition as the incoming one, and a lower expiry. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No it doesn't. An internetworking protocol can't prescribe that >>>>>>>>> kind of thing to lower level protocols. An incoming and outgoing = transfer >>>>>>>>> could be sent using completely different protocols and the financ= ial >>>>>>>>> agreement with the peers on those two routes could be vastly diff= erent too. >>>>>>>>> >>>>>>>>> The only service ILP requires of lower level protocols is that >>>>>>>>> they can map a response to an original request. This requirement = is okay >>>>>>>>> because it is isolated to a single route/link at a time not a req= uirement >>>>>>>>> that crosses the inter-network boundary that ILP crosses. >>>>>>>>> >>>>>>>>> >>>>>>>>>> But because ILP allows for many different types of ledgers, it >>>>>>>>>> doesn't make sense to assert how these are encoded. >>>>>>>>>> >>>>>>>>> >>>>>>>>> By putting them in the ILP packet you do the opposite. You make n= o >>>>>>>>> assertions about how they are encoded if they are used at lower l= ayers, or >>>>>>>>> how they may be combined with other conditions or even used to de= rive new >>>>>>>>> conditions. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> IP doesn't tell you how to encode an ethernet packet. It doesn't >>>>>>>>>> even know whether it's going over a computer or a hand-written l= etter >>>>>>>>>> carried by a pigeon. IP takes for granted that you can send data= over one >>>>>>>>>> connection by putting it in a lower level. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Correct, but if a link layer protocol wanted to look into the IP >>>>>>>>> packet headers of a packet it wants to transfer and use some data= from >>>>>>>>> there in its internal logic (or even reuse data in it's own frame= ) that >>>>>>>>> would be totally fine. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Even though IP tells you how to chain these connections together= , >>>>>>>>>> it doesn't have to put the things it's chaining on the internetw= orking >>>>>>>>>> level. >>>>>>>>>> >>>>>>>>> >>>>>>>>> IP doesn't tell you how to chain things together. IP simply >>>>>>>>> defines the end-to end data envelope and address space. Because o= f this >>>>>>>>> nodes that implement the multiple lower layer protocols are able = to push IP >>>>>>>>> packets down a link and expect the node on the other side to unde= rstand the >>>>>>>>> headers and route it onward on another link. >>>>>>>>> >>>>>>>>> Everything needed by the IP module to decide what to do with the >>>>>>>>> packet is in the IP packet headers. i.e. Has it exceeded a TTL? I= s there a >>>>>>>>> route for this destination? Is it corrupted (checksum fails)? But= also, >>>>>>>>> everything that is needed by the endpoint (like the source addres= s) is also >>>>>>>>> in there. >>>>>>>>> >>>>>>>>> There is no dependency on nodes to be good citizens and always >>>>>>>>> pass certain other data from the lower layers into the next link.= That >>>>>>>>> would be breaking the layering. >>>>>>>>> >>>>>>>>> >>>>>>>>>> IP also assumes that if you get some incoming data on a >>>>>>>>>> connection you can copy it and send it out on the next connectio= n. Because >>>>>>>>>> you can already send data over a connection, all IP adds is the = missing >>>>>>>>>> piece: a packet that tells you where to go. >>>>>>>>>> >>>>>>>>>> With ILP, we assume that there is a way to prepare a conditional >>>>>>>>>> transfer, expire a conditional transfer, and fulfill a condition= al >>>>>>>>>> transfer. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No we don't! We assume that if we deliver the packet as intended >>>>>>>>> we'll get back a response packet with a signature that matches th= e >>>>>>>>> condition in the packet. So, if we have an agreement with someone= that they >>>>>>>>> will pay us when we present that signature then we are prepared t= o enter a >>>>>>>>> similar agreement with the next peer because we expect that signa= ture to >>>>>>>>> come all the way back along the interledger layer route.. >>>>>>>>> >>>>>>>>> >>>>>>>>>> We also assume that if you get an incoming transfer you can >>>>>>>>>> create an outgoing transfer with the same condition. The abstrac= tion we >>>>>>>>>> made means that conditions and fulfillments are already carried = in the >>>>>>>>>> lower levels. >>>>>>>>>> >>>>>>>>> >>>>>>>>> That is a bad assumption that comes from the broken layering. Wha= t >>>>>>>>> if my outgoing link doesn't support conditional transfers? So now= where do >>>>>>>>> I put the condition? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We could have assumed that no ledgers ever support conditional >>>>>>>>>> transfers, and said the only thing ILP gets from lower levels is= the >>>>>>>>>> ability to send a transfer. But if we want to support the case w= here any of >>>>>>>>>> them do, we have to keep the conditions and fulfillments in the = layer where >>>>>>>>>> they're actually used. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I don't follow that logic at all. If we want to support the case >>>>>>>>> where any of them do then we must ensure the condition and expiry= are >>>>>>>>> always carried in a consistent place at the internetworking layer= so that >>>>>>>>> if they do want to use them they know where to find them. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie < >>>>>>>>>> adrian@hopebailie.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 14 August 2017 at 22:03, Evan Schwartz >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I think this thread is going to get extremely unwieldy but her= e >>>>>>>>>>>> goes: >>>>>>>>>>>> >>>>>>>>>>>> > - All interledger layer messages should be ILP packets >>>>>>>>>>>> (including fulfillments) and be capable of carrying higher lay= er protocol >>>>>>>>>>>> payloads. >>>>>>>>>>>> >>>>>>>>>>>> Interledger has higher requirements than ILP for the lowest >>>>>>>>>>>> layer, specifically because we are carrying money and not just= data. One of >>>>>>>>>>>> the requirements is being able to transmit a 32-byte fulfillme= nt back along >>>>>>>>>>>> the same path that carried the payment originally. If we expec= t this of the >>>>>>>>>>>> lower layer, I don't see a point in putting the fulfillment in= to an ILP >>>>>>>>>>>> packet and transmitting it as Interledger data along the same = path. All >>>>>>>>>>>> ledger-layer protocols will need to interpret the fulfillment = passed in >>>>>>>>>>>> their protocol, not the one passed through the Interledger lay= er. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is not correct. There is no requirement on ledger layer >>>>>>>>>>> protocols to transmit or understand the fulfillment. You are lo= oking at >>>>>>>>>>> this through the lens of existing implementations from the bott= om up >>>>>>>>>>> instead of starting at the interledger layer. >>>>>>>>>>> >>>>>>>>>>> The primary function of the condition and fulfillment is as a >>>>>>>>>>> signed end-to-end receipt. If the sender agrees a condition wit= h a receiver >>>>>>>>>>> and then gets back the valid fulfillment they don't care what h= appened in >>>>>>>>>>> the middle. The receiver has signed a receipt saying they have = their money. >>>>>>>>>>> >>>>>>>>>>> The value of using a standard for the receipt and signature is >>>>>>>>>>> that each transfer along the way CAN re-use it. One the one han= d you can >>>>>>>>>>> have a transfer between two peers that have zero trust and the = ledger they >>>>>>>>>>> use supports conditional payments completely. On the other extr= eme you can >>>>>>>>>>> have two peers that have a full trust and ignore the condition = and >>>>>>>>>>> fulfillment completely. >>>>>>>>>>> >>>>>>>>>>> The ledger layer protocols carry ILP packets. Payment requests >>>>>>>>>>> and either fulfillment or error responses. If a ledger layer pr= otocol wants >>>>>>>>>>> to use the condition and fulfillment for their own operations t= hey can >>>>>>>>>>> extract these from the ILP packets and use them. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> > - While it may make sense to split the interledger payment >>>>>>>>>>>> and interledger quoting protocols into new higher level protoc= ols that >>>>>>>>>>>> seems like an unnecessary abstraction. Instead the packet defi= nitions >>>>>>>>>>>> should just have some consistency and probably a common base/h= eader. >>>>>>>>>>>> >>>>>>>>>>>> The current protocols effectively have this header but it isn'= t >>>>>>>>>>>> separated out. There are two fields in the request header: typ= e and >>>>>>>>>>>> destination address. There is one field in the response header= : type. I >>>>>>>>>>>> don't think it makes that much of a big difference to separate= these fields >>>>>>>>>>>> if all of the fields in that packet need to be interpreted tog= ether (for >>>>>>>>>>>> example, you can't understand a quote request if you strip off= the >>>>>>>>>>>> destination address). >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I agree that we don't HAVE to explicitly separate them out but = I >>>>>>>>>>> think ti would make it clearer how the stack is architected if = there was a >>>>>>>>>>> header that was consistent across all packets. Currently the on= ly thing >>>>>>>>>>> that is consitent across all ILP packets is that they are defin= ed int he >>>>>>>>>>> same file. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > - We should define two base ILP packet types: request and >>>>>>>>>>>> response. >>>>>>>>>>>> >>>>>>>>>>>> Unless this adds some substantive benefit or new fields I don'= t >>>>>>>>>>>> think it's worth breaking all of the formats we have just to r= earrange >>>>>>>>>>>> things. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The goal of this exercise is to tease out the best design and >>>>>>>>>>> ignore the cost of change until we can compare the results with= the current >>>>>>>>>>> design. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > - ILP is not about ledgers, it is about trustlines between >>>>>>>>>>>> nodes/hosts. >>>>>>>>>>>> >>>>>>>>>>>> A ledger is any system that tracks accounts and balances. When >>>>>>>>>>>> you use a trustline all of your messages still need to go thro= ugh an >>>>>>>>>>>> accounting system (such as the plugin in the JS implementation= ) and then on >>>>>>>>>>>> to the other program logic. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As above, this is incorrect. There is no requirement for "all >>>>>>>>>>> messages to go through an accounting system". >>>>>>>>>>> >>>>>>>>>>> Since designing the first implementation of 5-bells ledger we >>>>>>>>>>> have assumed that passing the ILP packet MUST be done by the le= dger because >>>>>>>>>>> that is how we implemented it. But that is not true. It is perf= ectly valid >>>>>>>>>>> for the passing of an ILP packet from one peer to another to be= simply an >>>>>>>>>>> exchange of data. >>>>>>>>>>> >>>>>>>>>>> The receiving peer makes a decision about whether or not to >>>>>>>>>>> forward the packet based on the current financial position they= have with >>>>>>>>>>> the sending peer. >>>>>>>>>>> >>>>>>>>>>> It is convenient if the ledger that records the net positions o= f >>>>>>>>>>> the peers also forwards the messaging and even better if it nat= ively >>>>>>>>>>> supports conditional payments and can use the condition and the= fulfillment >>>>>>>>>>> from the ILP packet for those but that's all it is, convenient. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> In that case, the plugin or whatever is doing the accounting i= s >>>>>>>>>>>> the ledger. Digital value is always tracked in ledgers, so I t= hink it does >>>>>>>>>>>> make sense to think of this as the base layer. The reason to a= bstract the >>>>>>>>>>>> functionality you expect from the ledger layer is precisely so= you can >>>>>>>>>>>> handle it in different ways, depending on what the underlying = systems >>>>>>>>>>>> provide. >>>>>>>>>>>> >>>>>>>>>>>> I see 3 ways to think of the layer(s) underpinning ILP: >>>>>>>>>>>> >>>>>>>>>>>> 1. The "Ledger Layer" provides both messaging capabilities >>>>>>>>>>>> and some type of HTLA >>>>>>>>>>>> >>>>>>>>>>>> 2. There are separate plugins for messaging and for >>>>>>>>>>>> transfers and when you peer with someone you have to agree = on a plugin for >>>>>>>>>>>> each >>>>>>>>>>>> 3. We standardize the messaging part and say that all goes >>>>>>>>>>>> over IP and then just have more minimal plugins for the on-= ledger >>>>>>>>>>>> settlements >>>>>>>>>>>> >>>>>>>>>>>> Number 1 is what we have and I think that still makes the most >>>>>>>>>>>> sense. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I think you're confusing implementation details and defining of >>>>>>>>>>> interfaces with definition of a protocol stack. The only differ= ences >>>>>>>>>>> between the tree examples you have above is in implementation. >>>>>>>>>>> >>>>>>>>>>> From the perspective of the Interledger Protocol the >>>>>>>>>>> implementation of the lower layers is not important, that's the= whole point >>>>>>>>>>> of layering. By forcing important aspects of ILP like the condi= tion, >>>>>>>>>>> fulfillment and expiry down into those layers you muddy the wat= ers and we >>>>>>>>>>> now have to standardize those protocols too. Instead we should = just be >>>>>>>>>>> defining the functions they must provide and then leave it up t= o >>>>>>>>>>> implementations to provide those functions. >>>>>>>>>>> >>>>>>>>>>> I know we want to define a standard to bootstrap the system >>>>>>>>>>> (CLP) but that's misleading us into thinking it's an essential = part of the >>>>>>>>>>> stack. It's perfectly valid for two peers to not use CLP and st= ill be part >>>>>>>>>>> of the Interledger. >>>>>>>>>>> >>>>>>>>>>> That said, you raise an interesting consideration about the >>>>>>>>>>> layers below ILP and actually I think it makes sense to split t= hese. >>>>>>>>>>> >>>>>>>>>>> We keep trying to force messaging through the ledger layer and >>>>>>>>>>> actually that's the wrong place to put it if we can split the l= edger layer >>>>>>>>>>> into a messaging layer and a ledger layer. That way we can stop= trying to >>>>>>>>>>> think of all HLTAs as ledgers. >>>>>>>>>>> >>>>>>>>>>> A thought, why not use sub-layers as is common in other stacks: >>>>>>>>>>> >>>>>>>>>>> 1. Link layer: Layer upon which two peers that have a direct >>>>>>>>>>> link, or participate in the same payment network, communicate >>>>>>>>>>> 2. Transfer/ ledger: Layer on which financial positions between >>>>>>>>>>> two peers are recorded >>>>>>>>>>> >>>>>>>>>>> This reflects the already emerging HTLA model and many of our >>>>>>>>>>> existing plugins and ledger integrations. >>>>>>>>>>> Link Layer: XRP Paychan, Lightning >>>>>>>>>>> Ledger Layer: XRP Ledger, Bitcoin >>>>>>>>>>> >>>>>>>>>>> This doesn't prevent us from defining a standard binary protoco= l >>>>>>>>>>> that defines all of the operations for both layers (like CLP) b= ut I see >>>>>>>>>>> value in distinguishing between these two. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > - The protocol should differentiate between the operation of >>>>>>>>>>>> preparing a transfer on a ledger and the operation of passing = an ILP packet >>>>>>>>>>>> from one peer to another. >>>>>>>>>>>> >>>>>>>>>>>> The protocol assumes your conditional transfer is underpinned >>>>>>>>>>>> by some HTLA >>>>>>>>>>>> . >>>>>>>>>>>> It doesn't care whether that's on-ledger or not. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> What do you mean when you say "the protocol"? In my statement I >>>>>>>>>>> am referring to ILP. >>>>>>>>>>> My point above being that ILP expects ILP packets to be passed >>>>>>>>>>> from peer to peer but has no expectations about transfers. >>>>>>>>>>> >>>>>>>>>>> It's perfectly legal (from an ILP perspective) for two peers to >>>>>>>>>>> exchange ILP packets with no transfers. Clearly if a node route= s a packet >>>>>>>>>>> on and has no incoming transfer it's going to lose money but th= at's a >>>>>>>>>>> consideration for that node. It doesn't affect anyone else in t= he chain. >>>>>>>>>>> >>>>>>>>>>> ILP doesn't assume anything about transfers at all, let alone >>>>>>>>>>> conditional transfers. It provides useful semantics for conditi= onal >>>>>>>>>>> transfers to be used by two peers to transact as part of a larg= er ILP >>>>>>>>>>> payment. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > - The condition and timeout should be included in the ILP >>>>>>>>>>>> payment packet. >>>>>>>>>>>> >>>>>>>>>>>> I strongly disagree with this. We had this debate a year ago >>>>>>>>>>>> and I was on your side but was convinced that this is not a go= od idea. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes, I recall this and I'm sorry I didn't push harder on this >>>>>>>>>>> point. Unfortunately I think the decision to pull it out of the= packet is >>>>>>>>>>> mostly driven by how our prototypes were implemented rather tha= n good >>>>>>>>>>> architecture. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The layer below ILP must be capable of doing conditional >>>>>>>>>>>> transfers based on sha256 hashlocks with 32-byte preimages. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is not true and I think it would be useful for us to agree >>>>>>>>>>> on this as this seems to be the argument I am coming up against= most often. >>>>>>>>>>> The peers participating in a transfer that is part of an ILP pa= yment may >>>>>>>>>>> wish to use conditional transfers as a way to enforce their agr= eement but >>>>>>>>>>> this is not a requirement of the protocol. >>>>>>>>>>> >>>>>>>>>>> The agreement between any two peers is: "I will pay you X if yo= u >>>>>>>>>>> can provide a receipt that Y was paid Z before T". >>>>>>>>>>> ILP provides a standard for expressing this agreement so that >>>>>>>>>>> these can be chained together BUT it is not a requirement that = every >>>>>>>>>>> agreement in the chain uses the condition, and fulfillment prov= ided at the >>>>>>>>>>> ILP layer. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As a result, the original condition and the corresponding >>>>>>>>>>>> preimage MUST be expressed in that layer. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As I have shown above, this is not true. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Then the question is whether we should also include it in the >>>>>>>>>>>> packet that is forwarded. What ultimately convinced me is the = following: >>>>>>>>>>>> All connectors MUST ignore the condition if it is in the packe= t, because >>>>>>>>>>>> they are only guaranteed their money back if they use the same= condition >>>>>>>>>>>> from the incoming transfer they got. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Here is where the layering is being corrupted. >>>>>>>>>>> >>>>>>>>>>> All connectors MUST inspect the condition in the ILP packet as >>>>>>>>>>> part of their decision to route the packet or not. >>>>>>>>>>> When the local transfer module of the connectors stack passes >>>>>>>>>>> the ILP packet up to the ILP module it should indicate the prop= erties of >>>>>>>>>>> the incoming transfer that carried the packet. >>>>>>>>>>> This is essential firstly so that the routing logic in the ILP >>>>>>>>>>> module can record the incoming transfer identifier so it is abl= e to use the >>>>>>>>>>> correct response id when it passes back the fulfillment or erro= r. >>>>>>>>>>> The other properties that the ILP module should look at are the >>>>>>>>>>> condition and expiry on the incoming transfer. >>>>>>>>>>> >>>>>>>>>>> If the incoming route uses conditional transfers and these are >>>>>>>>>>> supposed to match the condition and expiry in the ILP packet th= en the ILP >>>>>>>>>>> module should compare them and reject the packet if: >>>>>>>>>>> a) the conditions don't match OR >>>>>>>>>>> b) the expiry is too short >>>>>>>>>>> >>>>>>>>>>> We should still discuss if the expiry should be set by the >>>>>>>>>>> sender and left unchanged or used like a TTL and decremented by= each node. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Also, the receiver will need to take out the condition in orde= r >>>>>>>>>>>> to hash the packet for PSK or IPR. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is completely normal. Zeroing a checksum field in a header >>>>>>>>>>> before calculating the checksum is VERY common precisely becaus= e it's long >>>>>>>>>>> been accepted that the right place to put that data is in the h= eaders and >>>>>>>>>>> the work of zero'ing it out to calculate the checksum (or signa= ture in our >>>>>>>>>>> case) is not material. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> So basically, no one wants the condition in there. It feels >>>>>>>>>>>> like it ought to be in there, but literally none of the partie= s want the >>>>>>>>>>>> extra 32 bytes in there. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> "Nobody wants it there" is a terrible reason to abandon the >>>>>>>>>>> correct design. The whole purpose of a good architecture is you= accept that >>>>>>>>>>> there may be cases in future that haven't been considered now s= o designing >>>>>>>>>>> just for the known cases is a bad idea. >>>>>>>>>>> >>>>>>>>>>> Good architecture is not the same as optimization. Taking stuff >>>>>>>>>>> out (even when it feels wrong) to save a few bytes is a good si= gn that it's >>>>>>>>>>> a bad idea. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The reason the timeout should not be in there is that there >>>>>>>>>>>> isn't a single timeout for the payment. There are multiple sep= arate >>>>>>>>>>>> timeouts for each of the bilateral transfers. Those must go in= the >>>>>>>>>>>> individual transfers and there is no sensible value to put in = the >>>>>>>>>>>> Interledger packet. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As above, this is somewhat equivalent to the TTL in an IP >>>>>>>>>>> packet. I'm open to discussing if it should be a fixed value se= t by the >>>>>>>>>>> sender where each node uses their own value but has the sender-= defined >>>>>>>>>>> value as a reference or it is actually decremented at each hop. >>>>>>>>>>> >>>>>>>>>>> Either way, this is part of ILP not the ledger layer just like >>>>>>>>>>> the condition and fulfillment. It may be used by the ledger lay= er but >>>>>>>>>>> that's implementation specific. It belongs in the ILP packet. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>> Sent from a mobile device, please excuse any typos >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > --001a11442d84b177bc05570df5f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    My point is that it goes beyond that. ILP doesn= 9;t care if the layer below even has a concept of HTLAs. I can do ILP over = Bitcoin without the overlay layer if I want to but I need to find a peer th= at is prepared to do that with me.

    Because that's not how you build a protocol stack. A protocol stack i= s not defined through interfaces. It's defined through layers of data w= here each layer has a standard packet format with headers carrying data for= that layer and encapsulates the data of layer(s) above in the payload.

    I guess we're just using the term &= quot;doing ILP" differently. When I say it I'm referring to the fl= ow with prepare/fulfill/reject on a sha256 condition. If I'm understand= ing you correctly, you mean it to refer to the data format; anything that g= ets the ILP packet to the destination via peering or ledger connections cou= nts as ILP.

    On Fri, Aug 18, 2017 at 10:07 PM, Adrian Hope-Bailie <adrian@hop= ebailie.com> wrote:


    On 18 August 2017 at 15:09, Ben Sharafian &= lt;sharafian@ripp= le.com> wrote:
    What you're describing is an implementation of a loc= al transfer service that doesn't (or can't) take advantage of Inter= ledger. In fact, this will be the norm for most existing payment networks t= hat we want to add to the Interledger and this is where your work on paymen= t channels and HTLAs comes in to play.=C2=A0
    =C2=A0=

    If you have a local transfer c= hannel that doesn't support conditions natively or supports them in a w= ay that requires some adaption you can create an overlay network that does = what's needed. Example: Bitcoin is not a suitable network to use for IL= P so we use a payment channel between the peers that is underwritten by Bit= coin.

    Exactly, when I say you= need a to handle the condition and fulfillment via a clearing layer, this = "overlay network" is what I'm referring to. The whole point o= f an HTLA is that from ILP's point of view it's just a lower-level = protocol that can commit conditional transfers and fulfill them. ILP doesn&= #39;t care how the ledger/HTLA works under the hood, whether it's a cle= aring/overlay layer or a "real" ledger.
    <= div>
    My point is that it goes beyond that. ILP doesn&#= 39;t care if the layer below even has a concept of HTLAs. I can do ILP over= Bitcoin without the overlay layer if I want to but I need to find a peer t= hat is prepared to do that with me.

    In that case all I ha= ve to do is send them the ILP packet in a message that says I owe them some= Bitcoin. the "owe them some Bitcoin" isn't being enforced an= ywhere using an HTLA.
    =C2=A0

    You're equating this &qu= ot;overlay network," which is a type of ledger, with the ILP layer.

    Not at all. I agree with = what you have below. It's a layer that exists below ILP but above the a= ctual ledger. But crucially it's not a requirement for ILP to work so t= he protocol should depend on it existing.
    = =C2=A0
    If there i= s an overlay network that handles the condition and fulfillment, that means= you _are_ using a ledger, because the overlay network _is_ a ledger. The I= LP layer is a layer above this.

    Agreed.
    <= div dir=3D"ltr">

    If we assume the ILP packet is= well defined with all the ILP-required data elements then when a lower lay= er wants to use that data it can but should do it in a way that doesn't= break the ILP layer for everyone else. How that is implemented in practice= will depend on the lower layer protocol.

    That's one way to see it, but what I'm wondering is wh= y that's a better model than saying there's a clearly defined inter= face that the ledger-layer exposes, and then building the ILP layer on top = of that.

    Bec= ause that's not how you build a protocol stack. A protocol stack is not= defined through interfaces. It's defined through layers of data where = each layer has a standard packet format with headers carrying data for that= layer and encapsulates the data of layer(s) above in the payload.

    <= /div>
    The condition, fulfillment and expiry are part of ILP= so they belong in the ILP packet. If there are lower layers that want to u= se those things then they can but ILP shouldn't depend on that.
    =C2= =A0

    =
    Unless the next hop is backwards

    =
    There's no reason to send a backwards hop. If you don't= want to forward a payment you reject it.

    =
    That's what I mean by a backwards hop. I was illustra= ting my point that validating a packet is part of the routing decision.
    =
    =C2=A0

    Not at all. You're assuming= that there is no expiry on the local transfer. As a receiving node I have = an incoming transfer with an expiry and it carries an ILP packet that also = has an expiry.

    If that's = what you're talking about, the ILP packet already has an expiry. It'= ;s implemented in the PSK details so the receiver knows whether the packet = it issued is still valid. But that's an application layer concern, beca= use it's only the receiver who looks at the ILP packet's expiry. Th= e connectors only need to know the expiries of the local transfers.

    There is a big misconception in your= statement. The expiry is an end-to-end concern, or as you put it the sende= r sets and "the receiver looks at the ILP packet's expiry". T= hat's why it's in the ILP packet.

    The idea = that anything to be exchanged end-to-end must be in higher layers is comple= tely wrong. The reason you'd put something in a higher layer payload is= because the endpoints have agreed to use a higher layer protocol that requ= ires it to be there.

    <= br>
    On Fri, Aug 18, 2017 at 3:21 PM, Adrian Hope-= Bailie <adrian@hopebailie.com> wrote:


    On 18 August 2017 at 10:38, Ben Sharafian <sh= arafian@ripple.com> wrote:
    =
    Two connectors exchanging a transfer only ca= re about the data that is relevant to them for that transfer. It's quit= e possible for two connectors to perform a transfer that has no conditions = or fulfillments or a transfer that has a different condition and fulfillmen= t (such as an atomic mode transfer where the condition is a compound one th= at has multiple sub-conditions).

    <= div>Yes, two connectors could absolutely send an unconditional transfer on = an underlying ledger in order to settle an Interledger payment. But in orde= r to benefit from any of Interledger's guarantees (trustless connectors= , retry-ability, etc.), they MUST keep a conditional local transfer, at lea= st for clearing. If the local transfer cannot time out, it cannot be safely= retried. If the local transfer clears without a fulfillment, it loses the = "receipt or your money back" property. Yes, two parties in the ch= ain could eschew these benefits but that is no longer a correct implementat= ion of Interledger.

    Aha!= That is where I disagree! Interledger is not implemented at the local tran= sfer layer, it is implemented at the Interledger layer. The whole point is = that it an Interledger payment can travel over payment networks that know n= othing about ILP but the greatest value comes from using ones that do.
    <= br>What you're describing is an implementation of a local transfer serv= ice that doesn't (or can't) take advantage of Interledger. In fact,= this will be the norm for most existing payment networks that we want to a= dd to the Interledger and this is where your work on payment channels and H= TLAs comes in to play.

    If you have a local transfer channel that do= esn't support conditions natively or supports them in a way that requir= es some adaption you can create an overlay network that does what's nee= ded. Example: Bitcoin is not a suitable network to use for ILP so we use a = payment channel between the peers that is underwritten by Bitcoin.
    =C2=A0

    If a protocol at a lower layer wants to use that = data then it must replicate it. That seems inefficient but it's the cor= rect way to do it.

    What's= the actual reasoning behind this, and why is it considered the correct app= roach? If there's some IETF document that says this I'd like to see= it, because it intuitively feels wrong to have lower level abstractions lo= oking into higher levels.

    The data in the ILP layer is there for a specific reason. It's part o= f an end-to-end exchange between the sender and receiver.

    Side no= te: It's unusual to be designing the whole stack at once so we keep bei= ng tempted to move things around but in reality we should look at the ILP l= ayer in isolation and make sure it is complete. Alternatively we should try= to test our design against a number of lower and upper layer protocols to = make sure our thinking is sound.

    If we assume the ILP packet is = well defined with all the ILP-required data elements then when a lower laye= r wants to use that data it can but should do it in a way that doesn't = break the ILP layer for everyone else. How that is implemented in practice = will depend on the lower layer protocol.
    =C2=A0

    Routing r= equires looking at the condition, expiry and amount. A connector's rout= ing logic shouldn't forward a packet if the expiry is too low or if the= condition is obviously corrupted.

    Those are validity checks and you're right that they are performe= d in the connector, but the destination account, destination amount, and da= ta are enough to figure out what the best next hop is.

    Unless the next hop is backwards
    =C2=A0
    <= br>
    The ILP Packet's purpose is to describe where a payment i= s going.

    Not only that.= For comparison, an IP packet does a lot more than just describe where a pa= cket is going. All end-to-end concerns need to be in there too.
    =C2=A0
    T= he data it carries is only for the purpose of making sure the receiver can = identify that payment.

    = No, the condition is there so the receiver can ensure it is sending back th= e correct fulfillment and the expiry to give the receiver some assurance th= at the packet is still worth processing.
    =C2=A0
    In that context, the exp= iry has no bearing on where it will be routed nor on how much to route, onl= y on whether or not an individual connector will take the risk of forwardin= g it.

    The ILP packet just contains the en= d-to-end condition (always a SHA-256 hash) and then the local transfer can = have a different condition that is derived from the condition in the ILP pa= cket.

    Fair enough; in your ca= se you can transmit the condition twice and verify the structure of the com= plex local condition, and in the no-condition-in-ILP version you can verify= the structure of the local condition and extract the SHA256 condition to p= ass on.

    I think the expiry should always be the = expiry set by the sender. It won't be changed.=C2=A0
    <= br>
    That increases connector risk enormously, allowing any= body to cause a connector to lose money by submitting a fulfillment at the = last moment.

    Not at all. You're assuming that there is no expiry on the local tran= sfer. As a receiving node I have an incoming transfer with an expiry and it= carries an ILP packet that also has an expiry.

    My routin= g logic should look at both and decide a) if this is safe to route on (i.e.= put some of my own capital at risk) and b) what expiry to set on the next = hop.

    There is no incentive to change the expiry in the pa= cket as this can only be targeted at upstream connectors and the result wil= l simply be that the payment is declined and the upstream local transfer ro= lls back.
    =C2=A0
    <= div>If an attacker knows enough about latency in the chain, they could even= target this attack at somebody many hops away. Staggering expiries (giving= you a minimum amount of time to fulfill a source transfer) is an easy miti= gation against this attack; we shouldn't take it out.
    =

    I agree. We would still have = the local expiry.
    =C2=A0
    <= div>
    Comparing the condition in the local transfer and the= one in the ILP packet should be part of the routing logic.

    Sure, it can be done as an extra validity ch= eck, but it's just more code and more attack surface.=C2=A0I still don't see any tangible benefit from doing= the layering in this way, aside from your assertion that it's the corr= ect way to do it. If you've read any documents that explain why this is= the correct way to do layering, I think I'd understand you better.


    On Thu, Aug 17, 2017 at 7:32 PM, Adrian Hope-Bailie <adrian@ho= pebailie.com> wrote:


    On 16 August 2017 at 10:22, Ben Sharafian <sharafian@ripple.com= > wrote:
    OK, I think in that case we'= re mostly disagreeing over where the condition/fulfillment/expiry actually = go in the data.

    That's one way to look at it but that's ultimately what the archit= ecting the layering is. Deciding at which layer (and therefor encapsulated = in what packet) certain data should be.
    =C2=A0
    The reason I don't agree with your position is based = on which parties I think should be aware of ILP.

    I don't think that's the right wa= y to look at it. The connector needs to be able to understand at least the = ILP layer data AND the lower layer data. Normally the way the processing st= ack is implemented is that there is a module for each layer that processes = the data from that layer and then passes the payload and any other importan= t information up to the next layer.
    =C2=A0
    In order to track the balance between each other accur= ately, the two connectors have to keep track of conditions, fulfillments, a= nd expiries on each of the transfers.

    This is where I disagree with you. Two connectors exchangin= g a transfer only care about the data that is relevant to them for that tra= nsfer. It's quite possible for two connectors to perform a transfer tha= t has no conditions or fulfillments or a transfer that has a different cond= ition and fulfillment (such as an atomic mode transfer where the condition = is a compound one that has multiple sub-conditions).
    = =C2=A0
    =
    That means the connectors' accounting l= ogic that handles the conditions, fulfillments, and expiries is going to be= using some information inside the ILP packet and some information outside = of it in order to perform these transfers.
    <= div>
    It will only use info inside the packet if it use= s conditional transfers that use that same condition. This is the most like= ly scenario but that is not a protocol requirement.
    =C2= =A0

    I th= ink it's cleaner to say everything required to make these local transfe= rs should go in one protocol, so the accounting logic of these connectors d= oesn't have to deal with ILP directly.
    =

    I strongly disagree with that. That's entire= ly the wrong reason to put data into a specific layer. The data in the ILP = layer is there because it's "end-to-end" data.

    <= div>If a protocol at a lower layer wants to use that data then it must repl= icate it. That seems inefficient but it's the correct way to do it.
    =
    One could define a lower layer protocol that doesn't rep= licate the data but the rules of the protocol are "Get the condition f= rom the ILP packet". In that case, that specific lower level protocol = is forcing implementations to understand the ILP packet format, that's = an implementation detail.

    Another lower layer protocol mi= ght take the condition from the ILP packet and re-encode it in a different = form (like a base64ulr string or NI: uri)
    =C2=A0
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    Then the connectors' ILP-packet-related behavior can= all be routing related.

    Routing requires looking at the condition, expiry and amount. A co= nnector's routing logic shouldn't forward a packet if the expiry is= too low or if the condition is obviously corrupted.

    If t= he protocols were designed correctly as I am proposing then another routing= decision would be, is the condition that was used in the incoming transfer= the same as the one used in the ILP packet?

    =C2=A0
    This would add a few benefits; two co= nnectors could perform non-ILP conditional transfers between one another (w= hich would be useful for reconciliation and settlement), and could also all= ow two connectors to use more complex condition types (i.e. signatures for = atomic mode) without forcing us to support that in the ILP packet.

    You seem to have this ba= ckwards. Both of these things are supported if the condition and expiry ARE= in the ILP packet. Atomic mode is not supported in the ILP protocol it is = supported in the lower layer transfer protocol. The ILP packet just contain= s the end-to-end condition (always a SHA-256 hash) and then the local trans= fer can have a different condition that is derived from the condition in th= e ILP packet.
    =C2=A0
    It also k= eeps the integrity of the ILP packet as something lower levels don't mo= dify; the connector has to modify the expiry in order to pass along an ILP = payment (they may not modify the expiry if they're using something like= atomic mode, but then we have the issue with advanced condition types not = being supported in the ILP packet).
    I think the expiry should always be the expiry set by the sen= der. It won't be changed.

    In the case whe= re the ledger _does_ care about the condition and fulfillment, the argument= in favor of separating condition/fulfillment/expiry from the rest of the p= acket is similar. Because we don't control the features of all ledgers,= we'll need our plugins or ledger adapters to be aware of ILP. This mak= es it hard to interact with any events that don't involve ILP packets, = and impossible to handle features that extend beyond what we support in the= ILP packet. We could pass details about non-ILP ledger features (like a cr= ypto condition) in the side data, but in the event of any redundancy we hav= e to check the ledger-supplied info, not the info in the ILP packet.
    <= /div>

    Comparing the condition= in the local transfer and the one in the ILP packet should be part of the = routing logic.
    =C2=A0

    Basically, condition/fulfillment/expiry a= re used for accounting local transfers (even if they aren't being "= ;ledger" enforced) in addition to their role as every-hop information.= By putting them in the ILP packet, we limit the special features that ledg= ers can support and make our software abstractions harder to separate clean= ly. By putting them in the local transfer alongside the ILP packet but not = inside it, we do separate the data a little more, but we have more freedom = in what the underlying accounting and ledger logic can do, and our software= modules will have more clearly separated domains.

    They should be in both the local transfer= AND the ILP packet if they are needed by the local transfer protocol. This= allows the flexibility you desire because the local transfer protocol can = do ANYTHING including using the condition from the ILP packet as-is, not at= all or enhanced for something like atomic mode.

    =C2=A0

    On Tue, Aug 15, 2017 at 10:24 AM, Adrian Hope-Bailie <adrian@h= opebailie.com> wrote:
    =
    Exactly =F0=9F=91=8D

    On Tue, Aug 15, 2017 at 6:52 PM Ben Sharafian <sharafian@ripple.com> wrote:<= br>
    Ok, I think I have a better id= ea of what you're saying.

    It sounds like you're = saying the ILP layer contains all information that is common between every = hop (destination, destination amount, opaque data, condition, fulfillment, = expiry). The lower level would then be used for all the transfer-local deta= ils (source amount, next connector account, custom/local data).
    <= br>
    If the lower level wanted to do anything related to the every= -hop payment, i.e. escrow funds until the receipt has been produced, it wou= ld look into the ILP layer for that information. If the lower level didn= 9;t do any escrow or expiries that require every-hop details, it would simp= ly function as a communication method.

    Is that rig= ht?

    On= Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    On 15 August 2017 at 16:00, Be= n Sharafian <sharafian@ripple.com> wrote:
    In= that case, the plugin or whatever is doing the accounting is the ledger. D= igital value is always tracked in ledgers, so I think it does make sense to= think of this as the base layer. The reason to abstract the functionality = you expect from the ledger layer is precisely so you can handle it in diffe= rent ways, depending on what the underlying systems provide.
    I = see 3 ways to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both me= ssaging capabilities and some type of=C2=A0HTLA
    1. There are separate plugins for messaging and for tra= nsfers and when you peer with someone you have to agree on a plugin for eac= h
    1. We standardize the messaging = part and say that all goes over IP and then just have more minimal plugins = for the on-ledger settlements
    Number 1 is what we have and I think= that still makes the most sense.

    I think you're confusing implementation details and defining o= f interfaces with definition of a protocol stack. The only differences betw= een the tree examples you have above is in implementation.

    I had to scroll up after reading this to make= sure it was @adrian talking, because that seems like the opposite of what = you were arguing for.

    I= don't think so. But I think that is part of the problem. We are not al= l focused on the same thing. I am actually not very interested in CLP at al= l. It is one of potentially many protocols that may exist below the ILP lay= er. All we're doing by defining CLP is bootstrapping the network by def= ining a protocol for everyone to use to get started.

    In d= esigning the ILP layer properly we should try and forget everything we know= about the lower layers other than what features we require of them.
    There is a misconception that ILP requires the lower layers to = support conditional transfers, that is not true.

    All we a= ctually need from a lower layer protocol is to transfer data back and forth= and provide a way to reliably map requests to responses.

    What ILP provides lower layers is a way to reward your peer for passing on= the packet. The Internetworking layer defines a condition, a reward that m= ust be paid to the receiver for the fulfillment and the time allowed to cla= im this reward.

    Because of this, within lower-= layer protocols that offer the basic request/response features we need, we = could add conditional payment semantics that use the condition, expiry and = fulfillment provided by ILP. This would allow a node to offer a reward to= =C2=A0 their next peer to for delivering the packet they send them and to m= ake the local financial transaction contingent on the end-to-end transactio= n.

    But crucially, adding that semantic to the lower layer= protocol provides nothing extra to the ILP layer. The value is purely deri= ved from the two peers who use that protocol and can now use conditional pa= yments to protect themselves from their peers.
    =C2=A0
    The proposa= l that you're arguing for is basically asserting that we're going t= o be using CLP, because it makes the assumption that the connectors (who un= derstand ILP) are managing the HTLA logic.
    Not at all. I am asserting that it doesn't matter wh= at protocol you use below the ILP layer because it shouldn't matter. Al= l of this talk about ILP being different because money is more important th= an data is nonsense.

    The difference between ILP and IP that ma= kes ILP suitable for value transfer and IP not is at the internetworking la= yer. ILP requires that all packets are either a request or response and tha= t the responses follow the same path as the requests. Further ILP defines a= signature scheme that gives the sender a way to be certain the request was= received by the receiver.

    This = could be done entirely without money but then there would be little inc= entive to sign the receipt or deliver the signature back to the original se= nder.

    So, if you add money then you= add economic incentives to the mix. At each hop the sender promises the ne= xt upstream peer a payment if they can return the receipt. The net effect i= s that this can be used to transfer money from the sender to the receiver b= y simply defining up front the amount that the receiver must get to produce= the signature.
    =C2=A0

    In the current model, the CLP/trustline model and= the direct ledger model both work without having to treat anything on the = ILP layer differently. We're favoring on-ledger messaging because of ou= r implementation, yes, but we've been able to switch most all of our pl= ugins from on-ledger messaging to RPC-based messaging without changing the = ILP layer at all.

    With the ledger-level abstractio= n, we were able to switch from our ledger-based mode of thinking to the CLP= /trustline based way without changing anything other than the plugin. Your = argument comes from an assumption of a CLP-style ledger protocol with some = underlying ledger, which we can't assume is always the case.

    I'm not sure what any of that prove= s tbh. These are all implementation concerns. They don't change the fac= t that the condition, expiry and fulfillment are part of ILP not the lower = layer protocols.
    =C2=A0

    From the perspec= tive of the Interledger Protocol the implementation of the lower layers is = not important, that's the whole point of layering. By forcing important= aspects of ILP like the condition, fulfillment and expiry down into those = layers you muddy the waters and we now have to standardize those protocols = too. Instead we should just be defining the functions they must provide and= then leave it up to implementations to provide those functions.

    I don't agree with this point; the = condition and fulfillment have actual meaning to the ledger layer.

    NO THEY DON'T! They have me= aning to SOME ledgers that implement SOME lower layer protocols, IF they ch= oose to use them.

    Excuse the shouting but this is the cru= x of the issue. We need to all agree that it is entirely possible for a tra= nsfer to be done that doesn't use the condition and fulfillment and tha= t if this was in the middle of a 10-hop ILP payment it would have no effect= on the sender and receiver.
    =C2=A0
    You've said that the ledger often do= esn't care about fulfillment and condition, but the ledger _layer_'= s (where transfers are done) role is to take in condition and fulfillment a= nd make a transfer which satisfies its HTLA.
    =
    No, the ledger's role is to keep a tab of net financia= l positions between two peers. It MAY use conditions and fulfillments that = it pulls from the ILP layer to help it do that in a way both peers agree on= .

    Note that a "layer" doe= sn't have a role. I think there is some confusion about the difference = between layering the protocol and abstracting functionality into different = components.
    =C2=A0
    If the ledger layer has to look into the ILP packet to do so, that = is a blatant breaking of layering.

    =
    Not at all! The module acting at the layers below the in= ternetworking layer shouldn't modify anything inside the packets of the= higher layers but they can definitely inspect them and adjust their behavi= or based on what they to find.

    In fact the prevalence of this = is the subject of a lot of debate at the IETF currently because endpoints a= re often encrypting their payloads and in some cases this makes it difficul= t for middle-boxes to be effective at their jobs.

    By putting the condition, fulfillment, and expiry on the ledger lay= er, we leave it open for any ledger type to work, rather than forcing all l= edger-layer software to understand ILP.

    Actually you do the opposite. You make it a requirement of = every protocol below the ILP layer to define a way to carry these data elem= ents and encode and decode them, even if they don't use them

    Ledger layer components don't have to understand ILP unless the= y choose to re-use the condition for their own local transfer. Ledgers them= selves never have to understand ILP.

    Remember a ledger layer= protocol could use a completely different conditional payments scheme, lik= e atomic mode ILP, where it takes the end-to-end condition and creates a ne= w compound condition that depends on the fulfillment and some notary signat= ure.

    There will be a component in a connector's stack= that must pass the ILP packet to the next peer. If it does this using a tr= ansfer protocol that uses conditional transfers and wants to use the same c= ondition as the ILP packet then it must decode the packet.

    But, it will likely do something with that condition before sending the t= ransfer to the ledger like encoding it differently or rehashing it (lightni= ng?) so that it's in the form expected by the ledger.
    That's an implementation decision of the lower layer protoc= ol used between those two peers.
    =C2=A0

    I agree th= at Interledger defines how conditions, fulfillments, and expiries should be= chained together, but it makes no assertions about their data format.

    ILP doesn't define how = anything is chained together. From the perspective of ILP the condition and= fulfillment are end-to-end data. They are agreed by the two endpoints who = don't care how they get from Alice to Bob and back.

    T= he design of ILP is such that it facilitates the design of lower level prot= ocols that can be used to carry the ILP packets across multiple hops (netwo= rks) using economic incentives such that the sender pays enough for the fir= st hop to ensure that all nodes in between can extract the fee they want an= d the receiver will still get the amount they expected..

    =C2=A0
    ILP says you should send your outgoing transfer with the same condition = as the incoming one, and a lower expiry.

    =
    No it doesn't. An internetworking protocol can't = prescribe that kind of thing to lower level protocols. An incoming and outg= oing transfer could be sent using completely different protocols and the fi= nancial agreement with the peers on those two routes could be vastly differ= ent too.

    The only service ILP requires of lower level protocols is t= hat they can map a response to an original request. This requirement is oka= y because it is isolated to a single route/link at a time not a requirement= that crosses the inter-network boundary that ILP crosses.
    <= div>=C2=A0
    But because ILP allows for many different types of ledgers, it doesn't= make sense to assert how these are encoded.
    <= br>
    By putting them in the ILP packet you do the opposite.= You make no assertions about how they are encoded if they are used at lowe= r layers, or how they may be combined with other conditions or even used to= derive new conditions.

    IP doesn't tell you how to encod= e an ethernet packet. It doesn't even know whether it's going over = a computer or a hand-written letter carried by a pigeon. IP takes for grant= ed that you can send data over one connection by putting it in a lower leve= l.

    Correct, but if a li= nk layer protocol wanted to look into the IP packet headers of a packet it = wants to transfer and use some data from there in its internal logic (or ev= en reuse data in it's own frame) that would be totally fine.
    <= span>
    =C2=A0
    Even though IP tells you how to chain these connections together, it= doesn't have to put the things it's chaining on the internetworkin= g level.

    IP doesn't= tell you how to chain things together. IP simply defines the end-to end da= ta envelope and address space. Because of this nodes that implement the mul= tiple lower layer protocols are able to push IP packets down a link and exp= ect the node on the other side to understand the headers and route it onwar= d on another link.

    Everything needed by the IP module to = decide what to do with the packet is in the IP packet headers. i.e. Has it = exceeded a TTL? Is there a route for this destination? Is it corrupted (che= cksum fails)? But also, everything that is needed by the endpoint (like the= source address) is also in there.

    There is no dependency= on nodes to be good citizens and always pass certain other data from the l= ower layers into the next link. That would be breaking the layering.
    =C2=A0
    IP also assumes that if you get some incoming data on a connecti= on you can copy it and send it out on the next connection. Because you can = already send data over a connection, all IP adds is the missing piece: a pa= cket that tells you where to go.

    With ILP, we assu= me that there is a way to prepare a conditional transfer, expire a conditio= nal transfer, and fulfill a conditional transfer.
    =

    No we don't! We assume that if we deliver th= e packet as intended we'll get back a response packet with a signature = that matches the condition in the packet. So, if we have an agreement with = someone that they will pay us when we present that signature then we are pr= epared to enter a similar agreement with the next peer because we expect th= at signature to come all the way back along the interledger layer route..
    =C2=A0
    We also assume that if you get an incoming transfer you can= create an outgoing transfer with the same condition. The abstraction we ma= de means that conditions and fulfillments are already carried in the lower = levels.

    That is a bad as= sumption that comes from the broken layering. What if my outgoing link does= n't support conditional transfers? So now where do I put the condition?=
    =C2=A0

    We could have assumed that no ledgers ever support co= nditional transfers, and said the only thing ILP gets from lower levels is = the ability to send a transfer. But if we want to support the case where an= y of them do, we have to keep the conditions and fulfillments in the layer = where they're actually used.

    I don't follow that logic at all. If we want to support the ca= se where any of them do then we must ensure the condition and expiry are al= ways carried in a consistent place at the internetworking layer so that if = they do want to use them they know where to find them.
    =C2=A0

    On Tue= , Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:


    On 14 August 2= 017 at 22:03, Evan Schwartz <evan@ripple.com> wrote:
    I think this thread is going to get e= xtremely unwieldy but here goes:

    >=C2=A0- All interledger layer messages should be ILP= packets (including fulfillments) and be capable of carrying higher layer p= rotocol payloads.

    Interledger has hi= gher requirements than ILP for the lowest layer, specifically because we ar= e carrying money and not just data. One of the requirements is being able t= o transmit a 32-byte fulfillment back along the same path that carried the = payment originally. If we expect this of the lower layer, I don't see a= point in putting the fulfillment into an ILP packet and transmitting it as= Interledger data along the same path. All ledger-layer protocols will need= to interpret the fulfillment passed in their protocol, not the one passed = through the Interledger layer.

    This is not correct. There is no requirement on ledger layer protocols to= transmit or understand the fulfillment. You are looking at this through th= e lens of existing implementations from the bottom up instead of starting a= t the interledger layer.

    The prima= ry function of the condition and fulfillment is as a signed end-to-end rece= ipt. If the sender agrees a condition with a receiver and then gets back th= e valid fulfillment they don't care what happened in the middle. The re= ceiver has signed a receipt saying they have their money.

    The value of using a standard for the receipt and si= gnature is that each transfer along the way CAN re-use it. One the one hand= you can have a transfer between two peers that have zero trust and the led= ger they use supports conditional payments completely. On the other extreme= you can have two peers that have a full trust and ignore the condition and= fulfillment completely.
    =C2=A0
    The ledger layer protocols carry ILP packets. Payment requests and either= fulfillment or error responses. If a ledger layer protocol wants to use th= e condition and fulfillment for their own operations they can extract these= from the ILP packets and use them.

    >=C2=A0- While it may make sense to split the interledger payment and= interledger quoting protocols into new higher level protocols that seems l= ike an unnecessary abstraction. Instead the packet definitions should just = have some consistency and probably a common base/header.
    <= span style=3D"color:rgb(33,33,33)">
    The current protocols effectively have this header= but it isn't separated out. There are two fields in the request header= : type and destination address. There is one field in the response header: = type. I don't think it makes that much of a big difference to separate = these fields if all of the fields in that packet need to be interpreted tog= ether (for example, you can't understand a quote request if you strip o= ff the destination address).

    =
    I agree that we don't HAVE to explicitly separate them out = but I think ti would make it clearer how the stack is architected if there = was a header that was consistent across all packets. Currently the only thi= ng that is consitent across all ILP packets is that they are defined int he= same file.
    =C2=A0

    =
    >=C2=A0- We should define two base ILP packet type= s: request and response.

    Unless this = adds some substantive benefit or new fields I don't think it's wort= h breaking all of the formats we have just to rearrange things.
    =

    The goal of this exercise is to tea= se out the best design and ignore the cost of change until we can compare t= he results with the current design.
    =C2=A0

    &= gt;=C2=A0- ILP is not about ledgers, it= is about trustlines between nodes/hosts.

    A ledger is any system that tracks accounts and ba= lances. When you use a trustline all of your messages still need to go thro= ugh an accounting system (such as the plugin in the JS implementation) and = then on to the other program logic.

    As above, this is incorrect. There is no requirement for "= ;all messages to go through an accounting system".

    S= ince designing the first implementation of 5-bells ledger we have assumed t= hat passing the ILP packet MUST be done by the ledger because that is how w= e implemented it. But that is not true. It is perfectly valid for the passi= ng of an ILP packet from one peer to another to be simply an exchange of da= ta.

    The receiving peer makes a decision about whether or = not to forward the packet based on the current financial position they have= with the sending peer.

    It is convenient if th= e ledger that records the net positions of the peers also forwards the mess= aging and even better if it natively supports conditional payments and can = use the condition and the fulfillment from the ILP packet for those but tha= t's all it is, convenient.

    =C2=A0
    In that case, the plugi= n or whatever is doing the accounting is the ledger. Digital value is alway= s tracked in ledgers, so I think it does make sense to think of this as the= base layer. The reason to abstract the functionality you expect from the l= edger layer is precisely so you can handle it in different ways, depending = on what the underlying systems provide.

    I see 3 wa= ys to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messaging capabilities an= d some type of HTLA
    2. There are separate plugins for messagin= g and for transfers and when you peer with someone you have to agree on a p= lugin for each
    3. We standardize the messaging part and say that all g= oes over IP and then just have more minimal plugins for the on-ledger settl= ements
    Number 1 is what we have and I think that still makes = the most sense.

    I think you're= confusing implementation details and defining of interfaces with definitio= n of a protocol stack. The only differences between the tree examples you h= ave above is in implementation.

    From the perspective of the Interled= ger Protocol the implementation of the lower layers is not important, that&= #39;s the whole point of layering. By forcing important aspects of ILP like= the condition, fulfillment and expiry down into those layers you muddy the= waters and we now have to standardize those protocols too. Instead we shou= ld just be defining the functions they must provide and then leave it up to= implementations to provide those functions.

    I know we want to define a standard to bootstrap the system (CLP)= but that's misleading us into thinking it's an essential part of t= he stack. It's perfectly valid for two peers to not use CLP and still b= e part of the Interledger.

    That said, you raise an interesting considera= tion about the layers below ILP and actually I think it makes sense to spli= t these.

    We keep trying to force messaging through the le= dger layer and actually that's the wrong place to put it if we can spli= t the ledger layer into a messaging layer and a ledger layer. That way we c= an stop trying to think of all HLTAs as ledgers.

    A though= t, why not use sub-layers as is common in other stacks:

    1= . Link layer: Layer upon which two peers that have a direct link, or partic= ipate in the same payment network, communicate
    2. Transfer/ l= edger: Layer on which financial positions between two peers are recorded
    This reflects the already emerging HTLA model and many of our existing= plugins and ledger integrations.
    Link Layer: XRP Paychan, Li= ghtning
    Ledger Layer: XRP Ledger, Bitcoin

    <= /div>
    This doesn't prevent us from defining a standard binary proto= col that defines all of the operations for both layers (like CLP) but I see= value in distinguishing between these two.
    =C2=A0

    >=C2=A0- The protocol should = differentiate between the operation of preparing a transfer on a ledger and= the operation of passing an ILP packet from one peer to another.
    The protocol assumes your = conditional transfer is underpinned by some HTLA. It doesn't care whethe= r that's on-ledger or not.

    What do you mean when you say "the protocol"? In my statement I= am referring to ILP.
    My point above being that ILP expects ILP packets= to be passed from peer to peer but has no expectations about transfers.
    It's perfectly legal (from an ILP= perspective) for two peers to exchange ILP packets with no transfers. Clea= rly if a node routes a packet on and has no incoming transfer it's goin= g to lose money but that's a consideration for that node. It doesn'= t affect anyone else in the chain.

    = ILP doesn't assume anything about transfers at all, let alone condition= al transfers. It provides useful semantics for conditional transfers to be = used by two peers to transact as part of a larger ILP payment.
    =C2=A0

    >=C2=A0- The condition and timeout should be included in the ILP = payment packet.

    I strongly disagree = with this. We had this debate a year ago and I was on your side but was con= vinced that this is not a good idea.

    Yes, I recall this and I'm sorry I didn't push harder = on this point. Unfortunately I think the decision to pull it out of the pac= ket is mostly driven by how our prototypes were implemented rather than goo= d architecture.

    The layer below ILP must be capable of doing= conditional transfers based on sha256 hashlocks with 32-byte preimages.

    This is not true and I th= ink it would be useful for us to agree on this as this seems to be the argu= ment I am coming up against most often. The peers participating in a transf= er that is part of an ILP payment may wish to use conditional transfers as = a way to enforce their agreement but this is not a requirement of the proto= col.

    The agreement between any two peers is: "I will= pay you X if you can provide a receipt that Y was paid Z before T".
    ILP provides a standard for expressing this agreement so that = these can be chained together BUT it is not a requirement that every agreem= ent in the chain uses the condition, and fulfillment provided at the ILP la= yer.

    =C2=A0
    As a result, the original condition and the corresponding pr= eimage MUST be expressed in that layer.

    <= /div>
    As I have shown above, this is not true.
    =C2=A0
    = Then the question is whether we should also include it in the packet that i= s forwarded. What ultimately convinced me is the following: All connectors = MUST ignore the condition if it is in the packet, because they are only gua= ranteed their money back if they use the same condition from the incoming t= ransfer they got.

    Here is where the layering is being corrupted.

    All = connectors MUST inspect the condition in the ILP packet as part of their de= cision to route the packet or not.
    When= the local transfer module of the connectors stack passes the ILP packet up= to the ILP module it should indicate the properties of the incoming transf= er that carried the packet.
    This is ess= ential firstly so that the routing logic in the ILP module can record the i= ncoming transfer identifier so it is able to use the correct response id wh= en it passes back the fulfillment or error.
    The other properties that th= e ILP module should look at are the condition and expiry on the incoming tr= ansfer.

    If the inco= ming route uses conditional transfers and these are supposed to match the c= ondition and expiry in the ILP packet then the ILP module should compare th= em and reject the packet if:
    a) the conditions don't matc= h OR
    b) the expiry is too short

    We should s= till discuss if the expiry should be set by the sender and left unchanged o= r used like a TTL and decremented by each node.
    =C2=A0<= /div>
    Also, the = receiver will need to take out the condition in order to hash the packet fo= r PSK or IPR.

    This is c= ompletely normal. Zeroing a checksum field in a header before calculating t= he checksum is VERY common precisely because it's long been accepted th= at the right place to put that data is in the headers and the work of zero&= #39;ing it out to calculate the checksum (or signature in our case) is not = material.
    =C2=A0
    So basically, no one wants the condition in ther= e. It feels like it ought to be in there, but literally none of the parties= want the extra 32 bytes in there.

    <= /span>
    "Nobody wants it there" is a terrible reason to abando= n the correct design. The whole purpose of a good architecture is you accep= t that there may be cases in future that haven't been considered now so= designing just for the known cases is a bad idea.

    Good a= rchitecture is not the same as optimization. Taking stuff out (even when it= feels wrong) to save a few bytes is a good sign that it's a bad idea.<= br>
    =C2=A0

    The reason the timeout should not be in the= re is that there isn't a single timeout for the payment. There are mult= iple separate timeouts for each of the bilateral transfers. Those must go i= n the individual transfers and there is no sensible value to put in the Int= erledger packet.
    =C2=A0
    As ab= ove, this is somewhat equivalent to the TTL in an IP packet. I'm open t= o discussing if it should be a fixed value set by the sender where each nod= e uses their own value but has the sender-defined value as a reference or i= t is actually decremented at each hop.

    Either way, this i= s part of ILP not the ledger layer just like the condition and fulfillment.= It may be used by the ledger layer but that's implementation specific.= It belongs in the ILP packet.
    =C2=A0





    --
    Sent from a mobile device, please excuse any typos







    --001a11442d84b177bc05570df5f4-- From nobody Fri Aug 18 15:05:17 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A19F132027 for ; Fri, 18 Aug 2017 14:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 TezSGB04LZ1u for ; Fri, 18 Aug 2017 14:58:21 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 B13F71321BF for ; Fri, 18 Aug 2017 14:58:21 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id z18so59895640qka.4 for ; Fri, 18 Aug 2017 14:58:21 -0700 (PDT) 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=Gf9qRFknikmQu+dwRKe5KoE+oDoemQrFLByhXgVeqXE=; b=l8JLcdsOoUOp0dUY/RP5TWupsiiNHVMLGm/daUjduxQueyjpdawIJ4Pl5A5/9Qvpes nVXK5qg9/U2cOdYeJWed5Pq1cTgA2DOQwdQoHv6kWdG+aSm/FZbipzPiIiMFpU7TaW6a p9Etk1Rf9WTqS/eN4C02NAmsjKRd+LfosTrMgNrpMrxXjVL7XLQrZ+LEC48N37W96nwR B42we/+89KmpMn9xoM7cePVjL66ncdeea40YC9UZiyX+KpM30DGgv1KFvgEjag/upNKP BVlQBdys6zBmNO8Th4P2vz98euwnlRa4HbL3lh9EypkSSULVWbKdGxrRzFBe4m07Hhhb tpiQ== 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=Gf9qRFknikmQu+dwRKe5KoE+oDoemQrFLByhXgVeqXE=; b=Pla6bI+Lim7HD3pgJ/B5HwdZrCKnpsI40uO4WJJOohzV4idkAx4GJHNXmN712RC4b/ CqBpKcB9G1DNUPIkMvngqkOVZjjUScEsZnhFOHghw00gviGwQUyGUFYkV9vyt11tlJPg 30wq8e+ROjPM1zGA//PgKsvdcK3VqeFTRqIBgiJgyh2C4ENW2dl+GIfOSnLWO72L0OE3 /cmnSptudr+/PGNamPyEox+Z7l8eNgGDGJ108n/SC6g+op3C4vF6OhXx+fzlwQlKoFza Ze4BkzRlXYb0asV76x73G+F2rzXA0SEEvxYItzwL9eWsL+lKkDbpbW567QQez0aeEwBS jALQ== X-Gm-Message-State: AHYfb5i4or27y1hnRJmn/c38Zmv/nRQPCBJi/sUXE4YlTRW4IJaT/yvW VnU2cQUkUlbbBVXBlWH5uHZENhBR1A== X-Received: by 10.55.197.145 with SMTP id k17mr14269843qkl.354.1503093500950; Fri, 18 Aug 2017 14:58:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.38 with HTTP; Fri, 18 Aug 2017 14:58:20 -0700 (PDT) In-Reply-To: References: From: David Nicol Date: Fri, 18 Aug 2017 16:58:20 -0500 Message-ID: To: Adrian Hope-Bailie Cc: Ben Sharafian , Evan Schwartz , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a11466b34303fb705570e3a5c" Archived-At: X-Mailman-Approved-At: Fri, 18 Aug 2017 15:05:15 -0700 Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2017 21:58:23 -0000 --001a11466b34303fb705570e3a5c Content-Type: text/plain; charset="UTF-8" On Fri, Aug 18, 2017 at 3:07 PM, Adrian Hope-Bailie wrote: > > Because that's not how you build a protocol stack. A protocol stack is not > defined through interfaces. It's defined through layers of data where each > layer has a standard packet format with headers carrying data for that > layer and encapsulates the data of layer(s) above in the payload. > Also: defining a protocol stack informs the design of more robust and maintainable interfaces. That is, interfaces designed to an explicit protocol stack are more maintainable and robust than interfaces designed without one. Hoping my generalities are useful dln --001a11466b34303fb705570e3a5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Fri, Aug 18, 2017 at 3:07 PM, Adrian Hope-Bailie &= lt;adrian@hopeba= ilie.com> wrote:
    B= ecause that's not how you build a protocol stack. A protocol stack is n= ot defined through interfaces. It's defined through layers of data wher= e each layer has a standard packet format with headers carrying data for th= at layer and encapsulates the data of layer(s) above in the payload.

    =C2=A0Also: defining = a protocol stack informs the design of more robust and maintainable interfa= ces. That is, interfaces designed to an explicit protocol stack are more ma= intainable and robust than interfaces designed without one.

    <= /div>
    Hoping my generalities are useful

    dln

    --001a11466b34303fb705570e3a5c-- From nobody Tue Aug 22 15:18:33 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B26132A6E for ; Tue, 22 Aug 2017 15:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.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 nSOtYHtPvAFE for ; Tue, 22 Aug 2017 15:18:30 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 EEBDE132A93 for ; Tue, 22 Aug 2017 15:18:29 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id s199so229745vke.1 for ; Tue, 22 Aug 2017 15:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=OHrgYEqxtSQd2izW7GgmXNPp6fn9KzyQOFs4cT3cjtM=; b=hn/kpNtXpq16fNYUk+1N2GLe2/Hw6LvLmfb0gbUcA2pS5KtE27SXrGWZxsYSZMFHIu J5D21nZ+bKxb/6i4jKP63OYPJd1HqB/mP0lfTQA0hlLzQCHmAc5sAOL9gEMTNKD+4Ut6 EaQKw0aJoa9B9N9CJzEecbzKagxxGFtwg69TA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OHrgYEqxtSQd2izW7GgmXNPp6fn9KzyQOFs4cT3cjtM=; b=ChjrV00ml/ksKP/bjuO60j6wLV04fc4pRwCZi7r+ECer0WddW1fZd44qKqxrGTVPCu ivtfIed4593zwwGW74Z9Mh0VI4Uc5FcIOLfWWWYjEBdcYKU0FDn5buMqYpasM9FtW9A2 SYcisJ9/PgnxFEW8+7yOBo/zVaPbGBH5jhcXJl+SNh72kO48Byhn2uHUZclrvu2v93xD p/90UkLykwk1241QtXhPsaqykQUDAZR9pUGykdlvs4H6lSaoGEXLMAzwxtZU3VuN6p1M PbO5lOZGpdBUVxLN+2gJ3k1Kph0dxbobyzWPWaDbFH5JwqVyO6IvCHcO6wVnm/qwQBJ2 Ulrw== X-Gm-Message-State: AHYfb5jfwBZ0zm92CqWQncbZpgiI4E3O9j4QPleUfuAe1VUbMpyh3wb4 tSl0Ue62XwDlawtUxZZXNnaTDDhD75LF X-Received: by 10.31.128.144 with SMTP id b138mr488936vkd.22.1503440308826; Tue, 22 Aug 2017 15:18:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.62.90 with HTTP; Tue, 22 Aug 2017 15:18:28 -0700 (PDT) From: Adrian Hope-Bailie Date: Wed, 23 Aug 2017 00:18:28 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a1142a1d08c8d5305575ef9be" Archived-At: Subject: [Ledger] AGENDA - 23 August - 3pm UTC X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 22:18:32 -0000 --001a1142a1d08c8d5305575ef9be Content-Type: text/plain; charset="UTF-8" Hey all, Lets continue the discussion from our last call around the protocol stack architecture and a common ledger layer protocol. To join or start the meeting, go to: https://bluejeans.com/795795755 (Also works on iPhone or Android phone) To connect directly from a room system? 1) Dial: 199.48.152.152 or bjn.vc 2) Enter Meeting ID: 795795755 -or- use the pairing code Dial-in numbers: http://bluejeans.com/numbers (use Meeting ID: 795795755) --001a1142a1d08c8d5305575ef9be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hey all,

    Lets continue the discussi= on from our last call around the protocol stack architecture and a common l= edger layer protocol.

    To join or start the meeting, go to= :
    (Also works on iPhone or = Android phone)

    To connect directly from a room sys= tem?
    1) Dial: 199.48.152.152 or bjn.vc
    2) Enter Meeting ID: 795795755 -or- use th= e pairing code

    Dial-in numbers: http://bluejeans.com/numbers (= use Meeting ID: 795795755)
    --001a1142a1d08c8d5305575ef9be-- From nobody Thu Aug 24 12:26:42 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3EB13213D for ; Thu, 24 Aug 2017 12:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ripple.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 6fKRzIv4ZfDP for ; Thu, 24 Aug 2017 12:26:36 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 22747132113 for ; Thu, 24 Aug 2017 12:26:35 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id p67so2255984qkd.2 for ; Thu, 24 Aug 2017 12:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Olut7vSxsXva1cRzQJq+MfVr+toGyQdqCnke8Asn7Vg=; b=XzvWzuWS9DlE4tmhtosUNccQi1A83Bk0iE0hQi+lBmGnVV5qZkQdw01+1fefh4LY9E neCP9KepO5ZrQmr5aGurBuk707ckKqWJ4VPMeShFisUr+9LKJSxm6T0nnD9TC7r29oEE f5b0jDl3y44cknVTyR9fjvMIZhPpEtkbK3mJI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Olut7vSxsXva1cRzQJq+MfVr+toGyQdqCnke8Asn7Vg=; b=ERg6W8kBdpcMKqcvthhD0IEhMQ/ubd5xfCQWzsrPrnIlIWTPaOYGEQcbf2umkQcByU 5gCT57B/OKK6JppohwaPnIsuUiEa6r28g8AsLUFN6aXzfX2i8/PN8rFtw3jpadqgJok4 CFPclFLEMSy/ZVxFlQrvzcQiZSToJFbis0ONhAyfDYrT0mkYqES+64GwYlfiUC05f19h CPrlKPMQlriN4ukHxsJl8R/vP4jU51ilkYy9VlBsWLkkkDfURxDQelx1mdwGKsYqdVyd 8a88tpe6JKWGawr5h3sQMpImTzHfgVwf7M3AL9zkUC2XcPJGj8HxDhMZjzWpz5B8rD+W q4BQ== X-Gm-Message-State: AHYfb5jeLgv+DcKfVSJohmirZpnqfVAGwFDmEYHEjxB+1gXOkhCpQzbj vPIFgs5Shk3kR5lR35lowCnq0miGPI8r X-Received: by 10.55.91.135 with SMTP id p129mr9687879qkb.32.1503602794760; Thu, 24 Aug 2017 12:26:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Evan Schwartz Date: Thu, 24 Aug 2017 19:26:24 +0000 Message-ID: To: David Nicol , Adrian Hope-Bailie Cc: Ben Sharafian , Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary="001a114ea65e772e9d055784cec0" Archived-At: Subject: Re: [Ledger] An attempt to clean up the protocol architecture X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of interledger, originally a protocol stack for moving digital assets \(making payments\) between accounts operating on different payment networks or ledgers." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 19:26:40 -0000 --001a114ea65e772e9d055784cec0 Content-Type: text/plain; charset="UTF-8" I have to echo Ben's question about where this conception of layering comes from. In RFC 1122: Requirements for Internet Hosts -- Communication Layers , it says: > Protocol layering, which is generally used as an organizing principle in implementing network software, has also been used to organize this document...strict layering is an imperfect model, both for the protocol suite and for recommended implementation approaches. Protocols in different layers interact in complex and sometimes subtle ways, and particular functions often involve multiple layers. There are many design choices in an implementation, many of which involve creative "breaking" of strict layering...*This document describes the conceptual service interface between layers using a functional ("procedure call") notation*, like that used in the TCP specification [TCP:1]. A host implementation must support the logical information flow. implied by these calls, but need not literally implement the calls themselves. > In general, each major section of this document is organized into the following subsections:...*(4) Interfaces -- discusses the service interface to the next higher layer.*... As far as I understand it, the idea is that each layer provides a set of functionality or interface to the layer above. Each layer SHOULD NOT (in the RFC sense, meaning it's wrong to do it but implementations may do it anyway if they think they know better) inspect or try to understand the data of higher-level protocols. > From the perspective of the Interledger Protocol the implementation of the lower layers is not important, that's the whole point of layering. I'm pretty sure this is incorrect. Layers are defined by what functions they provide to the layer above them. *How* they provide that functionality is an implementation detail but not *what* functionality they provide. > ILP doesn't care if the layer below even has a concept of HTLAs. I can do ILP over Bitcoin without the overlay layer if I want to but I need to find a peer that is prepared to do that with me. I think you're missing the point of the HTLA idea. It is precisely the functionality that Interledger requires. When you say you need to "find a peer that is prepared to do that with me", the "that" means "use a pre or post-funded trustline with Bitcoin settlement" (also using a specific method and protocol for communication). Interledger doesn't care how you implement HTLAs but that is the interface it expects from the layer below it (+ request/response-based messaging). We could have defined ILP differently to have lower requirements on the layer below it. We could have said that all messaging goes over IP and is thus part of the Interledger layer implemented by connectors. We also could have said that we assume only that ledgers can do simple transfers so that connectors are also the ones that implement the conditional transfer semantic and always use simple ledger transfers for settlement. There is no one right place to put this functionality. Where it should go depends on the benefits it brings. By abstracting both the messaging and the implementation of conditional transfers we have allowed for implementations of the ledger layer to vary from nothing being provided by a ledger to everything. If Interledger is successful, I would expect future networks to be built with it in mind. I think it's better to build for the assumption that ledgers will implement whatever Interledger needs from them and create a way to overlay that on existing ledgers that don't, rather than assuming ledgers will always be built in the least useful way possible. > *we should try to test our design against a number of lower and upper layer protocols to make sure our thinking is sound.* As Ben mentioned, we have. The current design has allowed Ledger Layer implementations to change dramatically without affecting higher levels (going from on-ledger transfers to trustlines and payment channels). It has also allowed higher level protocols to change dramatically (going from IPR to PSK). On Fri, Aug 18, 2017 at 5:58 PM David Nicol wrote: > On Fri, Aug 18, 2017 at 3:07 PM, Adrian Hope-Bailie > wrote: >> >> Because that's not how you build a protocol stack. A protocol stack is >> not defined through interfaces. It's defined through layers of data where >> each layer has a standard packet format with headers carrying data for that >> layer and encapsulates the data of layer(s) above in the payload. >> > > Also: defining a protocol stack informs the design of more robust and > maintainable interfaces. That is, interfaces designed to an explicit > protocol stack are more maintainable and robust than interfaces designed > without one. > > Hoping my generalities are useful > > dln > > -- Evan Schwartz Software Engineer Managing Director of Ripple Luxembourg --001a114ea65e772e9d055784cec0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I have to echo Ben's question about where this concept= ion of layering comes from.


    > Prot= ocol layering, which is generally used as an organizing principle in implem= enting network software, has also been used to organize this document...str= ict layering is an imperfect model, both for the protocol suite and for rec= ommended implementation approaches. Protocols in different layers interact = in complex and sometimes subtle ways, and particular functions often involv= e multiple layers.=C2=A0 There are many design choices in an implementation= , many of which involve creative "breaking" of strict layering...= This document describes the conceptual service interface between layers = using a functional ("procedure call") notation, like that use= d in the TCP specification [TCP:1]. A host implementation must support the = logical information flow. implied by these calls, but need not literally im= plement the calls themselves.
    > In general, each major section= of this document is organized into the following subsections:...(4) =C2= =A0Interfaces -- discusses the service interface to the next higher layer.<= /b>...

    As far as I understand it, the idea is that= each layer provides a set of functionality or interface to the layer above= . Each layer SHOULD NOT (in the RFC sense, meaning it's wrong to do it = but implementations may do it anyway if they think they know better) inspec= t or try to understand the data of higher-level protocols.

    >=C2=A0From = the perspective of the Interledger Protocol the implementation of the lower= layers is not important, that's the whole point of layering.

    I'm pretty sur= e this is incorrect. Layers are defined by what functions they provide to t= he layer above them. How they provide that functionality is an imple= mentation detail but not what functionality they provide.

    >=C2=A0ILP doesn't care if the layer below even has a concept of HTLAs= . I can do ILP over Bitcoin without the overlay layer if I want to but I ne= ed to find a peer that is prepared to do that with me.

    I think you're missing th= e point of the HTLA idea. It is precisely the functionality that Interledge= r requires. When you say you need to "find a peer that is prepared to = do that with me", the "that" means "use a pre or post-f= unded trustline with Bitcoin settlement" (also using a specific method= and protocol for communication).=C2=A0

    Interledger doesn't care how you impleme= nt HTLAs but that is the interface it expects from the layer below it (+ re= quest/response-based messaging).

    We could have defined ILP differently to have lower= requirements on the layer below it. We could have said that all messaging = goes over IP and is thus part of the Interledger layer implemented by conne= ctors. We also could have said that we assume only that ledgers can do simp= le transfers so that connectors are also the ones that implement the condit= ional transfer semantic and always use simple ledger transfers for settleme= nt. There is no one right place to put this functionality. Where it should = go depends on the benefits it brings.

    By abstracting both the messaging and the impl= ementation of conditional transfers we have allowed for implementations of = the ledger layer to vary from nothing being provided by a ledger to everyth= ing. If Interledger is successful, I would expect future networks to be bui= lt with it in mind. I think it's better to build for the assumption tha= t ledgers will implement whatever Interledger needs from them and create a = way to overlay that on existing ledgers that don't, rather than assumin= g ledgers will always be built in the least useful way possible.

    >=C2=A0we should try to test our design against a number of lower = and upper layer protocols to make sure our thinking is sound.

    As Ben mentioned, we have. The current design has allowed = Ledger Layer implementations to change dramatically without affecting highe= r levels (going from on-ledger transfers to trustlines and payment channels= ). It has also allowed higher level protocols to change dramatically (going= from IPR to PSK).

    On Fri, Aug 18, 2017 at 5:58 PM David Nicol <davidnicol@gmail.com> wrote:
    On Fri, Aug 18, 2017 at 3:07 PM, Adrian Hope-Bailie <adr= ian@hopebailie.com> wrote:
    Because that's not how you build a protocol stack. A protocol = stack is not defined through interfaces. It's defined through layers of= data where each layer has a standard packet format with headers carrying d= ata for that layer and encapsulates the data of layer(s) above in the paylo= ad.

    =C2=A0Also: defining a protocol stack informs the design of more robust = and maintainable interfaces. That is, interfaces designed to an explicit pr= otocol stack are more maintainable and robust than interfaces designed with= out one.

    Hoping my generalities are useful

    dln

    --

    Evan Schwartz

    =
    Software Engineer
    Managing Director of Ripple = Luxembourg
    --001a114ea65e772e9d055784cec0--

    On Tue, Aug 15, 2017 at 7:24 PM, Adrian Hope-Bailie <= adrian@hopebailie.com> wrote:
    Exactly =F0=9F=91=8D
    =
    On Tue, Aug 15, 2017 at 6:52 PM Ben Sha= rafian <sharaf= ian@ripple.com> wrote:
    = Ok, I think I have a better idea of what you're saying.

    <= div>It sounds like you're saying the ILP layer contains all information= that is common between every hop (destination, destination amount, opaque = data, condition, fulfillment, expiry). The lower level would then be used f= or all the transfer-local details (source amount, next connector account, c= ustom/local data).

    If the lower level wanted to do= anything related to the every-hop payment, i.e. escrow funds until the rec= eipt has been produced, it would look into the ILP layer for that informati= on. If the lower level didn't do any escrow or expiries that require ev= ery-hop details, it would simply function as a communication method.
    <= div>
    Is that right?
    On Tue, Aug 15, 2017 at 6:35 PM, Adrian Hope-Ba= ilie <a= drian@hopebailie.com> wrote:

    = On 15 August 2017 at 16:00, Ben Sharafian <sharafian@ripple.com> wrot= e:
    In th= at case, the plugin or whatever is doing the accounting is the ledger. Digi= tal value is always tracked in ledgers, so I think it does make sense to th= ink of this as the base layer. The reason to abstract the functionality you= expect from the ledger layer is precisely so you can handle it in differen= t ways, depending on what the underlying systems provide.
    I see= 3 ways to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both messa= ging capabilities and some type of=C2=A0HTLA
    1. There are separate plugins for messaging and for tran= sfers and when you peer with someone you have to agree on a plugin for each=
    1. We standardize the messaging p= art and say that all goes over IP and then just have more minimal plugins f= or the on-ledger settlements
    Number 1 is what we have and I think = that still makes the most sense.

    =
    I think you're confusing implementation details and defining of= interfaces with definition of a protocol stack. The only differences betwe= en the tree examples you have above is in implementation.

    I had to scroll up after reading this to make = sure it was @adrian talking, because that seems like the opposite of what y= ou were arguing for.

    I = don't think so. But I think that is part of the problem. We are not all= focused on the same thing. I am actually not very interested in CLP at all= . It is one of potentially many protocols that may exist below the ILP laye= r. All we're doing by defining CLP is bootstrapping the network by defi= ning a protocol for everyone to use to get started.

    In de= signing the ILP layer properly we should try and forget everything we know = about the lower layers other than what features we require of them.

    =
    There is a misconception that ILP requires the lower layers to s= upport conditional transfers, that is not true.

    All we ac= tually need from a lower layer protocol is to transfer data back and forth = and provide a way to reliably map requests to responses.

    = What ILP provides lower layers is a way to reward your peer for passing on = the packet. The Internetworking layer defines a condition, a reward that mu= st be paid to the receiver for the fulfillment and the time allowed to clai= m this reward.

    Because of this, within lower-l= ayer protocols that offer the basic request/response features we need, we c= ould add conditional payment semantics that use the condition, expiry and f= ulfillment provided by ILP. This would allow a node to offer a reward to=C2= =A0 their next peer to for delivering the packet they send them and to make= the local financial transaction contingent on the end-to-end transaction.<= br>
    But crucially, adding that semantic to the lower layer pr= otocol provides nothing extra to the ILP layer. The value is purely derived= from the two peers who use that protocol and can now use conditional payme= nts to protect themselves from their peers.
    =C2=A0
    The proposal t= hat you're arguing for is basically asserting that we're going to b= e using CLP, because it makes the assumption that the connectors (who under= stand ILP) are managing the HTLA logic.

    Not at all. I am asserting that it doesn't matter what = protocol you use below the ILP layer because it shouldn't matter. All o= f this talk about ILP being different because money is more important than = data is nonsense.

    The difference between ILP and IP that makes= ILP suitable for value transfer and IP not is at the internetworking layer= . ILP requires that all packets are either a request or response and that t= he responses follow the same path as the requests. Further ILP defines a si= gnature scheme that gives the sender a way to be certain the request was re= ceived by the receiver.

    This cou= ld be done entirely without money but then there would be little incent= ive to sign the receipt or deliver the signature back to the original sende= r.

    So, if you add money then you ad= d economic incentives to the mix. At each hop the sender promises the next = upstream peer a payment if they can return the receipt. The net effect is t= hat this can be used to transfer money from the sender to the receiver by s= imply defining up front the amount that the receiver must get to produce th= e signature.
    =C2=A0

    In the current model, the CLP/trustline model and th= e direct ledger model both work without having to treat anything on the ILP= layer differently. We're favoring on-ledger messaging because of our i= mplementation, yes, but we've been able to switch most all of our plugi= ns from on-ledger messaging to RPC-based messaging without changing the ILP= layer at all.

    With the ledger-level abstraction, = we were able to switch from our ledger-based mode of thinking to the CLP/tr= ustline based way without changing anything other than the plugin. Your arg= ument comes from an assumption of a CLP-style ledger protocol with some und= erlying ledger, which we can't assume is always the case.

    I'm not sure what any of that proves t= bh. These are all implementation concerns. They don't change the fact t= hat the condition, expiry and fulfillment are part of ILP not the lower lay= er protocols.
    =C2=A0

    From the perspective of the Interledger Protocol the implementation of th= e lower layers is not important, that's the whole point of layering. By= forcing important aspects of ILP like the condition, fulfillment and expir= y down into those layers you muddy the waters and we now have to standardiz= e those protocols too. Instead we should just be defining the functions the= y must provide and then leave it up to implementations to provide those fun= ctions.

    I don't agree wit= h this point; the condition and fulfillment have actual meaning to the ledg= er layer.

    NO THEY DON&#= 39;T! They have meaning to SOME ledgers that implement SOME lower layer pro= tocols, IF they choose to use them.

    Excuse the shouting b= ut this is the crux of the issue. We need to all agree that it is entirely = possible for a transfer to be done that doesn't use the condition and f= ulfillment and that if this was in the middle of a 10-hop ILP payment it wo= uld have no effect on the sender and receiver.
    =C2=A0
    You've said that t= he ledger often doesn't care about fulfillment and condition, but the l= edger _layer_'s (where transfers are done) role is to take in condition= and fulfillment and make a transfer which satisfies its HTLA.
    =

    No, the ledger's role is to keep a t= ab of net financial positions between two peers. It MAY use conditions and = fulfillments that it pulls from the ILP layer to help it do that in a way b= oth peers agree on.

    Note that a &qu= ot;layer" doesn't have a role. I think there is some confusion abo= ut the difference between layering the protocol and abstracting functionali= ty into different components.
    =C2=A0
    If the ledger layer has to look into the ILP packe= t to do so, that is a blatant breaking of layering.

    Not at all! The module acting at the layers below the internetworking layer shouldn't modify anything inside t= he packets of the higher layers but they can definitely inspect them and ad= just their behavior based on what they to find.

    In fact the pr= evalence of this is the subject of a lot of debate at the IETF currently be= cause endpoints are often encrypting their payloads and in some cases this = makes it difficult for middle-boxes to be effective at their jobs.

    By putting the condition, fulfillment, and expiry on= the ledger layer, we leave it open for any ledger type to work, rather tha= n forcing all ledger-layer software to understand ILP.

    Actually you do the opposite. You make it a = requirement of every protocol below the ILP layer to define a way to carry = these data elements and encode and decode them, even if they don't use = them

    Ledger layer components don't have to understand= ILP unless they choose to re-use the condition for their own local transfe= r. Ledgers themselves never have to understand ILP.

    Remember= a ledger layer protocol could use a completely different conditional payme= nts scheme, like atomic mode ILP, where it takes the end-to-end condition a= nd creates a new compound condition that depends on the fulfillment and som= e notary signature.

    There will be a component in a connec= tor's stack that must pass the ILP packet to the next peer. If it does = this using a transfer protocol that uses conditional transfers and wants to= use the same condition as the ILP packet then it must decode the packet.
    But, it will likely do something with that condition befor= e sending the transfer to the ledger like encoding it differently or rehash= ing it (lightning?) so that it's in the form expected by the ledger.

    That's an implementation decision of the low= er layer protocol used between those two peers.
    =C2=A0<= /div>

    =
    I agree that Interledger defines how conditions, fulfillments, and exp= iries should be chained together, but it makes no assertions about their da= ta format.

    ILP doesn= 9;t define how anything is chained together. From the perspective of ILP th= e condition and fulfillment are end-to-end data. They are agreed by the two= endpoints who don't care how they get from Alice to Bob and back.
    <= br>
    The design of ILP is such that it facilitates the design of l= ower level protocols that can be used to carry the ILP packets across multi= ple hops (networks) using economic incentives such that the sender pays eno= ugh for the first hop to ensure that all nodes in between can extract the f= ee they want and the receiver will still get the amount they expected..
    =
    =C2=A0
    ILP says you should send your outgoing transfer with the = same condition as the incoming one, and a lower expiry.

    No it doesn't. An internetworking prot= ocol can't prescribe that kind of thing to lower level protocols. An in= coming and outgoing transfer could be sent using completely different proto= cols and the financial agreement with the peers on those two routes could b= e vastly different too.

    The only service ILP requires of lower level= protocols is that they can map a response to an original request. This req= uirement is okay because it is isolated to a single route/link at a time no= t a requirement that crosses the inter-network boundary that ILP crosses.
    =C2=A0
    But because ILP allows for many different types of ledgers,= it doesn't make sense to assert how these are encoded.

    By putting them in the ILP packet you d= o the opposite. You make no assertions about how they are encoded if they a= re used at lower layers, or how they may be combined with other conditions = or even used to derive new conditions.

    IP doesn't tell y= ou how to encode an ethernet packet. It doesn't even know whether it= 9;s going over a computer or a hand-written letter carried by a pigeon. IP = takes for granted that you can send data over one connection by putting it = in a lower level.

    Corre= ct, but if a link layer protocol wanted to look into the IP packet headers = of a packet it wants to transfer and use some data from there in its intern= al logic (or even reuse data in it's own frame) that would be totally f= ine.
    =C2=A0
    Even though IP tells you how to chain these connectio= ns together, it doesn't have to put the things it's chaining on the= internetworking level.

    IP doesn't tell you how to chain things together. IP simply defines th= e end-to end data envelope and address space. Because of this nodes that im= plement the multiple lower layer protocols are able to push IP packets down= a link and expect the node on the other side to understand the headers and= route it onward on another link.

    Everything needed by th= e IP module to decide what to do with the packet is in the IP packet header= s. i.e. Has it exceeded a TTL? Is there a route for this destination? Is it= corrupted (checksum fails)? But also, everything that is needed by the end= point (like the source address) is also in there.

    There i= s no dependency on nodes to be good citizens and always pass certain other = data from the lower layers into the next link. That would be breaking the l= ayering.
    =C2=A0
    IP also assumes that if you get some incoming dat= a on a connection you can copy it and send it out on the next connection. B= ecause you can already send data over a connection, all IP adds is the miss= ing piece: a packet that tells you where to go.

    Wi= th ILP, we assume that there is a way to prepare a conditional transfer, ex= pire a conditional transfer, and fulfill a conditional transfer.

    No we don't! We assume that i= f we deliver the packet as intended we'll get back a response packet wi= th a signature that matches the condition in the packet. So, if we have an = agreement with someone that they will pay us when we present that signature= then we are prepared to enter a similar agreement with the next peer becau= se we expect that signature to come all the way back along the interledger = layer route..
    =C2=A0
    We also assume that if you get an incoming t= ransfer you can create an outgoing transfer with the same condition. The ab= straction we made means that conditions and fulfillments are already carrie= d in the lower levels.

    T= hat is a bad assumption that comes from the broken layering. What if my out= going link doesn't support conditional transfers? So now where do I put= the condition?
    =C2=A0

    We could have assumed that no ledgers = ever support conditional transfers, and said the only thing ILP gets from l= ower levels is the ability to send a transfer. But if we want to support th= e case where any of them do, we have to keep the conditions and fulfillment= s in the layer where they're actually used.

    I don't follow that logic at all. If we want to= support the case where any of them do then we must ensure the condition an= d expiry are always carried in a consistent place at the internetworking la= yer so that if they do want to use them they know where to find them.
    = =C2=A0

    On= Tue, Aug 15, 2017 at 12:04 PM, Adrian Hope-Bailie <adrian@hopebailie.com><= /span> wrote:

    On 14 Augu= st 2017 at 22:03, Evan Schwartz <evan@ripple.com> wrote:
    I think this thread is going to ge= t extremely unwieldy but here goes:

    >=C2=A0- All interledger layer messages should be = ILP packets (including fulfillments) and be capable of carrying higher laye= r protocol payloads.

    Interledger has= higher requirements than ILP for the lowest layer, specifically because we= are carrying money and not just data. One of the requirements is being abl= e to transmit a 32-byte fulfillment back along the same path that carried t= he payment originally. If we expect this of the lower layer, I don't se= e a point in putting the fulfillment into an ILP packet and transmitting it= as Interledger data along the same path. All ledger-layer protocols will n= eed to interpret the fulfillment passed in their protocol, not the one pass= ed through the Interledger layer.

    This is not correct. There is no requirement on ledger layer protocols= to transmit or understand the fulfillment. You are looking at this through= the lens of existing implementations from the bottom up instead of startin= g at the interledger layer.

    The pr= imary function of the condition and fulfillment is as a signed end-to-end r= eceipt. If the sender agrees a condition with a receiver and then gets back= the valid fulfillment they don't care what happened in the middle. The= receiver has signed a receipt saying they have their money.

    <= div class=3D"gmail_quote">The value of using a standard for the receipt and= signature is that each transfer along the way CAN re-use it. One the one h= and you can have a transfer between two peers that have zero trust and the = ledger they use supports conditional payments completely. On the other extr= eme you can have two peers that have a full trust and ignore the condition = and fulfillment completely.
    =C2=A0
    The ledger layer protocols carry ILP packets. Payment requests and eit= her fulfillment or error responses. If a ledger layer protocol wants to use= the condition and fulfillment for their own operations they can extract th= ese from the ILP packets and use them.
    =

    >=C2=A0- While it may make sense to split the interledger payment an= d interledger quoting protocols into new higher level protocols that seems = like an unnecessary abstraction. Instead the packet definitions should just= have some consistency and probably a common base/header.
    =
    The current protocols effectively have this heade= r but it isn't separated out. There are two fields in the request heade= r: type and destination address. There is one field in the response header:= type. I don't think it makes that much of a big difference to separate= these fields if all of the fields in that packet need to be interpreted to= gether (for example, you can't understand a quote request if you strip = off the destination address).

    I agree that we don't HAVE to explicitly separate them out= but I think ti would make it clearer how the stack is architected if there= was a header that was consistent across all packets. Currently the only th= ing that is consitent across all ILP packets is that they are defined int h= e same file.
    =C2=A0
    >=C2=A0- We should define two base ILP packet typ= es: request and response.

    Unless this adds some substantive benefit or new fields I don'= ;t think it's worth breaking all of the formats we have just to rearran= ge things.

    The goal of t= his exercise is to tease out the best design and ignore the cost of change = until we can compare the results with the current design.
    =C2=A0

    >=C2=A0- ILP is= not about ledgers, it is about trustlines between nodes/hosts.
    A ledger is any system that = tracks accounts and balances. When you use a trustline all of your messages= still need to go through an accounting system (such as the plugin in the J= S implementation) and then on to the other program logic.

    As above, this is incorrect. There is no= requirement for "all messages to go through an accounting system"= ;.

    Since designing the first implementation of 5-bells le= dger we have assumed that passing the ILP packet MUST be done by the ledger= because that is how we implemented it. But that is not true. It is perfect= ly valid for the passing of an ILP packet from one peer to another to be si= mply an exchange of data.

    The receiving peer makes a deci= sion about whether or not to forward the packet based on the current financ= ial position they have with the sending peer.

    = It is convenient if the ledger that records the net positions of the peers = also forwards the messaging and even better if it natively supports conditi= onal payments and can use the condition and the fulfillment from the ILP pa= cket for those but that's all it is, convenient.
    =C2=A0
    I= n that case, the plugin or whatever is doing the accounting is the ledger. = Digital value is always tracked in ledgers, so I think it does make sense t= o think of this as the base layer. The reason to abstract the functionality= you expect from the ledger layer is precisely so you can handle it in diff= erent ways, depending on what the underlying systems provide.
    I see 3 ways to think of the layer(s) underpinning ILP:
    1. The "Ledger Layer" provides both mess= aging capabilities and some type of HTLA
    2. There are separate p= lugins for messaging and for transfers and when you peer with someone you h= ave to agree on a plugin for each
    3. We standardize the messaging part= and say that all goes over IP and then just have more minimal plugins for = the on-ledger settlements
    Number 1 is what we have and I thin= k that still makes the most sense.

    I think you're confusing implementation details and defining of interf= aces with definition of a protocol stack. The only differences between the = tree examples you have above is in implementation.

    From the perspect= ive of the Interledger Protocol the implementation of the lower layers is n= ot important, that's the whole point of layering. By forcing important = aspects of ILP like the condition, fulfillment and expiry down into those l= ayers you muddy the waters and we now have to standardize those protocols t= oo. Instead we should just be defining the functions they must provide and = then leave it up to implementations to provide those functions.

    I know we want to define a standard to bootstr= ap the system (CLP) but that's misleading us into thinking it's an = essential part of the stack. It's perfectly valid for two peers to not = use CLP and still be part of the Interledger.

    That said, you raise an in= teresting consideration about the layers below ILP and actually I think it = makes sense to split these.

    We keep trying to force messa= ging through the ledger layer and actually that's the wrong place to pu= t it if we can split the ledger layer into a messaging layer and a ledger l= ayer. That way we can stop trying to think of all HLTAs as ledgers.

    =
    A thought, why not use sub-layers as is common in other stacks:<= br>
    1. Link layer: Layer upon which two peers that have a dir= ect link, or participate in the same payment network, communicate
    =
    2. Transfer/ ledger: Layer on which financial positions between two pe= ers are recorded

    This reflects the already emerging HTLA model and m= any of our existing plugins and ledger integrations.
    Link Lay= er: XRP Paychan, Lightning
    Ledger Layer: XRP Ledger, Bitcoin<= br>

    This doesn't prevent us from defining a st= andard binary protocol that defines all of the operations for both layers (= like CLP) but I see value in distinguishing between these two.
    =C2=A0
    =

    >=C2=A0- T= he protocol should differentiate between the operation of preparing a trans= fer on a ledger and the operation of passing an ILP packet from one peer to= another.

    The pro= tocol assumes your conditional transfer is underpinned by some HTLA. It does= n't care whether that's on-ledger or not.
    <= div>
    What do you mean when you say "the protocol"= ? In my statement I am referring to ILP.
    My point above being that ILP = expects ILP packets to be passed from peer to peer but has no expectations = about transfers.

    It's perfectly= legal (from an ILP perspective) for two peers to exchange ILP packets with= no transfers. Clearly if a node routes a packet on and has no incoming tra= nsfer it's going to lose money but that's a consideration for that = node. It doesn't affect anyone else in the chain.

    ILP doesn't assume anything about transfers at all= , let alone conditional transfers. It provides useful semantics for conditi= onal transfers to be used by two peers to transact as part of a larger ILP = payment.
    =C2=A0

    >=C2= =A0- The condition and timeout should b= e included in the ILP payment packet.

    I strongly disagree with this. We had this debate a year ago and I was on= your side but was convinced that this is not a good idea.

    Yes, I recall this and I'm sorry I d= idn't push harder on this point. Unfortunately I think the decision to = pull it out of the packet is mostly driven by how our prototypes were imple= mented rather than good architecture.

    The layer below ILP mu= st be capable of doing conditional transfers based on sha256 hashlocks with= 32-byte preimages.

    Thi= s is not true and I think it would be useful for us to agree on this as thi= s seems to be the argument I am coming up against most often. The peers par= ticipating in a transfer that is part of an ILP payment may wish to use con= ditional transfers as a way to enforce their agreement but this is not a re= quirement of the protocol.

    The agreement between any two = peers is: "I will pay you X if you can provide a receipt that Y was pa= id Z before T".
    ILP provides a standard for expressing t= his agreement so that these can be chained together BUT it is not a require= ment that every agreement in the chain uses the condition, and fulfillment = provided at the ILP layer.

    =C2=A0
    As a result, the original condition an= d the corresponding preimage MUST be expressed in that layer.
    <= /blockquote>

    As I have shown above, this is not t= rue.
    =C2=A0
    Then the question is whether we should also include i= t in the packet that is forwarded. What ultimately convinced me is the foll= owing: All connectors MUST ignore the condition if it is in the packet, bec= ause they are only guaranteed their money back if they use the same conditi= on from the incoming transfer they got.

    <= /div>
    Here is where the layering is being = corrupted.

    All connectors MUST inspect the condition in the ILP pack= et as part of their decision to route the packet or not.
    When the local transfer module of the connectors stack pa= sses the ILP packet up to the ILP module it should indicate the properties = of the incoming transfer that carried the packet.
    This is essential firstly so that the routing logic in the ILP m= odule can record the incoming transfer identifier so it is able to use the = correct response id when it passes back the fulfillment or error.
    The ot= her properties that the ILP module should look at are the condition and exp= iry on the incoming transfer.

    =
    If the incoming route uses conditional transfers and these are s= upposed to match the condition and expiry in the ILP packet then the ILP mo= dule should compare them and reject the packet if:
    a) the con= ditions don't match OR
    b) the expiry is too short

    =
    We should still discuss if the expiry should be set by the sende= r and left unchanged or used like a TTL and decremented by each node.
    =C2=A0
    So basically, no one wants= the condition in there. It feels like it ought to be in there, but literal= ly none of the parties want the extra 32 bytes in there.

    "Nobody wants it there" is a ter= rible reason to abandon the correct design. The whole purpose of a good arc= hitecture is you accept that there may be cases in future that haven't = been considered now so designing just for the known cases is a bad idea.
    Good architecture is not the same as optimization. Taking s= tuff out (even when it feels wrong) to save a few bytes is a good sign that= it's a bad idea.
    =C2=A0

    The reason the timeou= t should not be in there is that there isn't a single timeout for the p= ayment. There are multiple separate timeouts for each of the bilateral tran= sfers. Those must go in the individual transfers and there is no sensible v= alue to put in the Interledger packet.
    =C2=A0<= /div>
    As above, this is somewhat equivalent to the TTL in an IP = packet. I'm open to discussing if it should be a fixed value set by the= sender where each node uses their own value but has the sender-defined val= ue as a reference or it is actually decremented at each hop.

    <= div>Either way, this is part of ILP not the ledger layer just like the cond= ition and fulfillment. It may be used by the ledger layer but that's im= plementation specific. It belongs in the ILP packet.
    =C2=A0