From nobody Tue Aug 2 14:46:41 2016 Return-Path: X-Original-To: ledger@ietf.org Delivered-To: ledger@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E355512B054; Tue, 2 Aug 2016 14:41:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" Cc: ledger@ietf.org, adam@nostrum.com, mamille2@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160802214122.27776.75792.idtracker@ietfa.amsl.com> Date: Tue, 02 Aug 2016 14:41:22 -0700 Archived-At: X-Mailman-Approved-At: Tue, 02 Aug 2016 14:46:39 -0700 Subject: [Ledger] New Non-WG Mailing List: Ledger -- Discussion of interledger, originally a protocol stack for moving digital assets between accounts operating on different payment networks or ledgers X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 02 Aug 2016 21:41:23 -0000 A new IETF non-working group email list has been created. List address: ledger@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=ledger To subscribe: https://www.ietf.org/mailman/listinfo/ledger Purpose: Moving digital assets (making payments) between accounts operating on different payment networks or ledgers is not possible in an open, interoperable way. Interledger is a protocol stack for doing this (transferring digital assets) over the Internet. It defines a set of formats for representing digital asset transactions and protocols for executing those transactions in a secure and verifiable manner. The project was started within a W3C community group in October 2015. There was a non-WG forming LEDGER BoF at IETF 96. The purpose of this list is to provide a venue for ongoing conversations about the interledger work and its relevance to the IETF. For additional information, please contact the list administrators. From nobody Thu Aug 4 13:51:50 2016 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 147F512D819 for ; Thu, 4 Aug 2016 13:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4yiVEQjiUX-y for ; Thu, 4 Aug 2016 13:51:47 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B68E12DB1A for ; Thu, 4 Aug 2016 13:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1607; q=dns/txt; s=iport; t=1470343905; x=1471553505; h=to:from:subject:message-id:date:mime-version; bh=z+RjzgJi0eEsrCkJCOzXdvLYZUzJ8ISP1o0zI9mdAjs=; b=GPxsCA+s9JaiP5hwesoBwS8hRaqDPTU0dQ8+hidSfyCUV+br9/VRwqvS XLd4TkUg0wed6eSlcgQs9vwKgVN/+jXOoDF46Lcr90ayey5baAtYdN+ip UL8Vv6STRZQc4BOvMu5nAekQIv2W8k54wv2r+hqAXXvLjCclDVb92s++g 8=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWCgAcqqNX/5ldJa1dg0VWKlKkHQEBA?= =?us-ascii?q?QEBBnWWBSSHQzwQAQEBAQEBAV0nhQhLaAJsBgIBAYgtDp56j2OQCyMJBYVigkA?= =?us-ascii?q?Ih1mCNYJaBY8MiiYCgzqBcolWgVUBFYRbgw6FbJAoNR+EGR0yhysBAQE?= X-IronPort-AV: E=Sophos;i="5.28,471,1464652800"; d="asc'?scan'208";a="306999606" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2016 20:51:44 +0000 Received: from [10.129.24.61] ([10.129.24.61]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u74KpirZ031707 for ; Thu, 4 Aug 2016 20:51:44 GMT To: ledger@ietf.org From: Matt Miller Message-ID: <2befcfe5-4248-b030-175a-1f3a9e565b97@cisco.com> Date: Thu, 4 Aug 2016 14:51:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wnTnIN9Kfx43Vi9jpnSicru7LFq5lrh9e" Archived-At: Subject: [Ledger] BoF Minutes Posted X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 04 Aug 2016 20:51:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wnTnIN9Kfx43Vi9jpnSicru7LFq5lrh9e Content-Type: multipart/mixed; boundary="42LRVqDaTbgnNxITJjxLHsqCWXN4woncj" From: Matt Miller To: ledger@ietf.org Message-ID: <2befcfe5-4248-b030-175a-1f3a9e565b97@cisco.com> Subject: BoF Minutes Posted --42LRVqDaTbgnNxITJjxLHsqCWXN4woncj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello all, The minutes for the Ledger BoF have been posted at < https://www.ietf.org/proceedings/96/minutes/minutes-96-ledger >. Please send any corrections to the mailing list < ledger@ietf.org > or to the Chairs < ledger-chairs@ietf.org > as soon as possible. Thanks again to our minute takers and Jabber scribes! -- - Adam and Matt --42LRVqDaTbgnNxITJjxLHsqCWXN4woncj-- --wnTnIN9Kfx43Vi9jpnSicru7LFq5lrh9e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXo6rgAAoJEDWi+S0W7cO1LKQH/jlgDc0LfbVxtrVWhykilV3V 6ed94D0K9VTlooudbbFN7AYsSCelTNrb2gdEQ+Jl4AH8hqnsX2oYAY6ffI9VzW11 PhGVvRhQNaoE9kgdZoAKT0ya9VmqUKs9PzC2H8HqYMGZTPe/Eja1sLq82Hxb9WO/ Vmmqlyh3NZunCfoFMr6TD8OLg5noaSSkQYwIElxFVXKnungADRdlXB0NL/NALzJj h8zfGRZvZbqSwBjTVmaJuRvXrgsEHkHOgcyFU8TNFeo9TOw7Jr6urIL1NFQmMDZ2 1+07i5mZl7vxbvEuuFAPCeuXwgC+0egqwcSPWGTRA/88SyByRdSdc0ziVx8AYmM= =gZN9 -----END PGP SIGNATURE----- --wnTnIN9Kfx43Vi9jpnSicru7LFq5lrh9e-- From nobody Wed Aug 17 06:18:35 2016 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 2E4A812D80F for ; Wed, 17 Aug 2016 06:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32Q5c7KDhzeu for ; Wed, 17 Aug 2016 06:18:32 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1399D12D90E for ; Wed, 17 Aug 2016 06:18:27 -0700 (PDT) Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 6F5D1A80ED for ; Wed, 17 Aug 2016 15:18:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id DrlW0kiK2FeO for ; Wed, 17 Aug 2016 15:18:24 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.13] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 88C6BA80BE for ; Wed, 17 Aug 2016 15:18:24 +0200 (CEST) From: Alexander Pelov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5EEEE7E3-01F4-44C9-905F-05C7F19D9993@ackl.io> Date: Wed, 17 Aug 2016 15:18:23 +0200 To: ledger@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Ledger] Question on Ledger and Sidechains X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 17 Aug 2016 13:18:34 -0000 Dear all, I was unable to attend the BoF, so please excuse me if the question = I=E2=80=99d like to address has been discussed (it was not in the = minutes).=20 How does the concept of Interchain relate to Sidechains, e.g. as the = ones introduced in https://www.blockstream.com/sidechains.pdf ? Is there any convergence? Possibly using Interchains to enable = Sidechains? Best, Alexander From nobody Wed Aug 17 06:33:15 2016 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 5442012D7E2 for ; Wed, 17 Aug 2016 06:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.286 X-Spam-Level: X-Spam-Status: No, score=-1.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 1kZMYEh-doI6 for ; Wed, 17 Aug 2016 06:33:12 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 5A89312D7CE for ; Wed, 17 Aug 2016 06:33:12 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id f189so138080152oig.3 for ; Wed, 17 Aug 2016 06:33:12 -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=UjO2nJ3wiiwerSyi8MgBLncSS4BYg/jWLsXdCSvhdCY=; b=bCM5292jJ0f6/Tu0uhoKxj0G4954+sO9cSs7kKBbf6PUsSMTKvg9j6D2E8G5nhM3jZ VJ0rO3xj0eMpmZkortBmVmdJZVHv7WH46E75pykKY2tJ/rZyvyJe2iQh0hNIShU7m/oB I2in+gvsO0y/v+e3482Axj1/ZZX31SIJsD3qg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UjO2nJ3wiiwerSyi8MgBLncSS4BYg/jWLsXdCSvhdCY=; b=Aty9wSl1pJOW11ts2GCuPJr4Oj2prixcDdmqj+ijdR0r8ZRfS/QYc2FxGwHC+mx8EX /qSDmIaodCtfNSl23wkXwTczyCZVFMXaYWIkZTN5AYe+ZKNBlmNakkcpmg7y5JRmW2TV +FxV4zy78O9zabFiGCAE6NTpL2tQ6Gqot8qzPLyhv+CAgIWd9cm2da1s3OWzuIY90oX+ C7vFElm+t3fhZpV65YED2EpRr3+vmQnHQEjcIAvLdmGWWR+l7octz1+dVE0MfcBOaD+K qijWDtxayEEjhPPz9OLm09RP5gxwiNZq6ASkw7Iqp95x+RUMOElOh+5J1/4O70pYcsAZ d0LQ== X-Gm-Message-State: AEkooutJeLdmx4etarjZxQfuvh7TSe+lZuXlr5cGfYvp9rin8Wlpaxmm7kIKqwMqom0pALNBlK3ZMQAZDqEInLmN X-Received: by 10.202.114.79 with SMTP id p76mr23208056oic.183.1471440791633; Wed, 17 Aug 2016 06:33:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.3.77 with HTTP; Wed, 17 Aug 2016 06:32:48 -0700 (PDT) In-Reply-To: <5EEEE7E3-01F4-44C9-905F-05C7F19D9993@ackl.io> References: <5EEEE7E3-01F4-44C9-905F-05C7F19D9993@ackl.io> From: Evan Schwartz Date: Wed, 17 Aug 2016 15:32:48 +0200 Message-ID: To: Alexander Pelov Content-Type: multipart/alternative; boundary=001a1134f972b199b5053a4481db Archived-At: Cc: ledger@ietf.org Subject: Re: [Ledger] Question on Ledger and Sidechains X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 17 Aug 2016 13:33:14 -0000 --001a1134f972b199b5053a4481db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alexander, Sidechains is a method for making new versions of the Bitcoin blockchain where the value of the token on the new chain is pegged to the value of Bitcoin. The primary purpose is enabling new features to be developed for Bitcoin more easily. In theory some of the ideas from the paper could be used to transfer other types of assets between ledgers but it depends on a fairly deep integration between the ledgers (the core concept is that one blockchain is able to verify the state of the other). Interledger is an attempt at developing the most minimal protocol you would need to enable assets to be transferred across any type of ledger (blockchains and central ledgers alike) using cryptographic holds and third party "connectors". You probably could use Interledger to create a two-way peg between two blockchains but thus far we've been thinking more about creating competitive markets with variable exchange rates between ledgers. Best, Evan On Wed, Aug 17, 2016 at 3:18 PM, Alexander Pelov wrote: > Dear all, > > I was unable to attend the BoF, so please excuse me if the question I=E2= =80=99d > like to address has been discussed (it was not in the minutes). > > How does the concept of Interchain relate to Sidechains, e.g. as the ones > introduced in https://www.blockstream.com/sidechains.pdf ? > > Is there any convergence? Possibly using Interchains to enable Sidechains= ? > > Best, > Alexander > > _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger > --=20 Evan Schwartz | Software Architect | Ripple [image: ripple.com] --001a1134f972b199b5053a4481db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alexander,

Sidechains is a method fo= r making new versions of the Bitcoin blockchain where the value of the toke= n on the new chain is pegged to the value of Bitcoin. The primary purpose i= s enabling new features to be developed for Bitcoin more easily. In theory = some of the ideas from the paper could be used to transfer other types of a= ssets between ledgers but it depends on a fairly deep integration between t= he ledgers (the core concept is that one blockchain is able to verify the s= tate of the other).

Interledger is an attempt at d= eveloping the most minimal protocol you would need to enable assets to be t= ransferred across any type of ledger (blockchains and central ledgers alike= ) using cryptographic holds and third party "connectors". You pro= bably could use Interledger to create a two-way peg between two blockchains= but thus far we've been thinking more about creating competitive marke= ts with variable exchange rates between ledgers.

B= est,
Evan

On Wed, Aug 17, 2016 at 3:18 PM, Alexander Pelov <a@ackl.io><= /span> wrote:
Dear all,

I was unable to attend the BoF, so please excuse me if the question I=E2=80= =99d like to address has been discussed (it was not in the minutes).

How does the concept of Interchain relate to Sidechains, e.g. as the ones i= ntroduced in https://www.blockstream.com/sidechains.p= df ?

Is there any convergence? Possibly using Interchains to enable Sidechains?<= br>
Best,
Alexander

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



--
Evan Schwartz | Software Architect | Ripple
3D"ripple.com"
--001a1134f972b199b5053a4481db-- From nobody Wed Aug 17 07:01:50 2016 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 8C7EF12DACF for ; Wed, 17 Aug 2016 07:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EvjwI0StMA9 for ; Wed, 17 Aug 2016 07:01:44 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A750112DA99 for ; Wed, 17 Aug 2016 07:01:25 -0700 (PDT) Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 0A349FB8A7; Wed, 17 Aug 2016 16:01:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Flz3cqOYSrCK; Wed, 17 Aug 2016 16:01:20 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.13] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id CE3E4FB89F; Wed, 17 Aug 2016 16:01:18 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_009B70D6-5766-4658-ADD9-C1F99CE25299" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Wed, 17 Aug 2016 16:01:18 +0200 Message-Id: <21A9421B-2011-4B03-8E59-99771BCCE417@ackl.io> References: <5EEEE7E3-01F4-44C9-905F-05C7F19D9993@ackl.io> To: Evan Schwartz X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ledger@ietf.org Subject: Re: [Ledger] Question on Ledger and Sidechains X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 17 Aug 2016 14:01:48 -0000 --Apple-Mail=_009B70D6-5766-4658-ADD9-C1F99CE25299 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Evan, Thanks for the explanation! I=E2=80=99d imagine that the principles behind the pegging to Bitcoin = can be extended to many of the blockchains, and in some way, it seems to = me the =C2=AB connectors =C2=BB play the role of intermediary to such =C2=AB= pegging =C2=BB.=20 Do you expect to have many inter-AS routing? Wouldn=E2=80=99t it be = simpler for a =C2=AB connector =C2=BB provider to provide connectors = between several ledgers, thus requiring one-hop only conversion? (this = question is of course purely hypothetical). Can we expect to have = any-to-bitcoin, and then have in the worst case a two-hop conversion? A think that I=E2=80=99m not clear about is what happens with = fluctuating exchange rates? Do you expect something RSVP-like to try to = guarantee some level of consistency? For example, a seller would request = 100 a-coins, and if I have a 2-route hop, it may take time until the two = transfers are complete.. so, I=E2=80=99m not going to be sure if I need = to send 1 b-coin, or 1.02 b-coins..=20 Best, Alexander > Le 17 ao=C3=BBt 2016 =C3=A0 15:32, Evan Schwartz a = =C3=A9crit : >=20 > Hi Alexander, >=20 > Sidechains is a method for making new versions of the Bitcoin = blockchain where the value of the token on the new chain is pegged to = the value of Bitcoin. The primary purpose is enabling new features to be = developed for Bitcoin more easily. In theory some of the ideas from the = paper could be used to transfer other types of assets between ledgers = but it depends on a fairly deep integration between the ledgers (the = core concept is that one blockchain is able to verify the state of the = other). >=20 > Interledger is an attempt at developing the most minimal protocol you = would need to enable assets to be transferred across any type of ledger = (blockchains and central ledgers alike) using cryptographic holds and = third party "connectors". You probably could use Interledger to create a = two-way peg between two blockchains but thus far we've been thinking = more about creating competitive markets with variable exchange rates = between ledgers. >=20 > Best, > Evan >=20 > On Wed, Aug 17, 2016 at 3:18 PM, Alexander Pelov > wrote: > Dear all, >=20 > I was unable to attend the BoF, so please excuse me if the question = I=E2=80=99d like to address has been discussed (it was not in the = minutes). >=20 > How does the concept of Interchain relate to Sidechains, e.g. as the = ones introduced in https://www.blockstream.com/sidechains.pdf = ? >=20 > Is there any convergence? Possibly using Interchains to enable = Sidechains? >=20 > Best, > Alexander >=20 > _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger = >=20 >=20 >=20 > --=20 > Evan Schwartz | Software Architect | Ripple > _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger --Apple-Mail=_009B70D6-5766-4658-ADD9-C1F99CE25299 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Evan,

Thanks for the explanation!

I=E2=80=99d imagine that = the principles behind the pegging to Bitcoin can be extended to many of = the blockchains, and in some way, it seems to me the = =C2=AB connectors =C2=BB play the role of intermediary to such = =C2=AB pegging =C2=BB. 

Do you expect to have many inter-AS = routing? Wouldn=E2=80=99t it be simpler for a =C2=AB connector =C2= =BB provider to provide connectors between several ledgers, thus = requiring one-hop only conversion? (this question is of course purely = hypothetical). Can we expect to have any-to-bitcoin, and then have in = the worst case a two-hop conversion?

A think that I=E2=80=99m not clear = about is what happens with fluctuating exchange rates? Do you expect = something RSVP-like to try to guarantee some level of consistency? For = example, a seller would request 100 a-coins, and if I have a 2-route = hop, it may take time until the two transfers are complete.. so, I=E2=80=99= m not going to be sure if I need to send 1 b-coin, or 1.02 = b-coins.. 

Best,
Alexander



Le = 17 ao=C3=BBt 2016 =C3=A0 15:32, Evan Schwartz <evan@ripple.com> a = =C3=A9crit :

Hi Alexander,

Sidechains is a method for making new = versions of the Bitcoin blockchain where the value of the token on the = new chain is pegged to the value of Bitcoin. The primary purpose is = enabling new features to be developed for Bitcoin more easily. In theory = some of the ideas from the paper could be used to transfer other types = of assets between ledgers but it depends on a fairly deep integration = between the ledgers (the core concept is that one blockchain is able to = verify the state of the other).

Interledger is an attempt at developing = the most minimal protocol you would need to enable assets to be = transferred across any type of ledger (blockchains and central ledgers = alike) using cryptographic holds and third party "connectors". You = probably could use Interledger to create a two-way peg between two = blockchains but thus far we've been thinking more about creating = competitive markets with variable exchange rates between = ledgers.

Best,
Evan

On Wed, = Aug 17, 2016 at 3:18 PM, Alexander Pelov <a@ackl.io> wrote:
Dear all,

I was unable to attend the BoF, so please excuse me if the question = I=E2=80=99d like to address has been discussed (it was not in the = minutes).

How does the concept of Interchain relate to Sidechains, e.g. as the = ones introduced in https://www.blockstream.com/sidechains.pdf = ?

Is there any convergence? Possibly using Interchains to enable = Sidechains?

Best,
Alexander

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



--
Evan Schwartz | = Software Architect | Ripple
3D"ripple.com"
_______________________________________________
Ledger = mailing list
Ledger@ietf.org
https://www.ietf.org/mailman/listinfo/ledger

= --Apple-Mail=_009B70D6-5766-4658-ADD9-C1F99CE25299-- From nobody Wed Aug 17 07:15:56 2016 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 44AAC12D7BB for ; Wed, 17 Aug 2016 07:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, T_REMOTE_IMAGE=0.01] 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 LpKMojFxfHZB for ; Wed, 17 Aug 2016 07:15:53 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 B9F1E12DC12 for ; Wed, 17 Aug 2016 07:15:32 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id f189so139584807oig.3 for ; Wed, 17 Aug 2016 07:15:32 -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=8RFESVXF/+KoVN+J67B7FLOI+fUS35cAOW5hBPqmEBk=; b=o8ixPbMtexMeOTIvlhgCOULQklwU4Ikvbh/Uo1AkrrNZaTsXCa3Voot/3EPSdaoFRp KrLt0sZNZOI20oQQG5+ssvsCZX6ugP9du6nPF/r1dy6F6H5PY8GfqV1rqi4u4WQyge0U walIBdreE7CVhLk55IZ455G4DOk8wvUp83Yws= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8RFESVXF/+KoVN+J67B7FLOI+fUS35cAOW5hBPqmEBk=; b=AhXR1X3CmJ92ZwbWKfFUwlc+f4/o6psmNbiA00UCNYZIk1/X5roKxPbyVXQfDJDkRT WdGENGs4pnXncLjN+wvY/tSCFWvYj5FI2WKeVOUjugmxGHKhqvSAbsRR3OIbUHvSWJmx 2rTfxI4BdpQM9/rFAZnL8A2wIKYmw9GPYPwuYi0ot5EhFj946cY5Zf7q4DYs/WtiHTYY hr8NJGo2+aCH/2fxlw2DF3G2JOgj3mQfuTbLy9fhw26iW7z3JuDcTWPu9zNNyngayhAp vHM8gjgqpi0wj3Lm0Jy+vJWFt+Es0jNrH2+mdv5liNazK6uYN9aO3IyRtSpWNZa92OwD wHQw== X-Gm-Message-State: AEkoouvZclb9T8FRjM/yzN8TJ2TgDjGk0jnbYVQsZZgzALGuWm0Itj+VGoHS5ONSh/VbFAHw6xilOoZVOOxQlzrO X-Received: by 10.157.27.151 with SMTP id z23mr20717036otd.72.1471443331965; Wed, 17 Aug 2016 07:15:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.3.77 with HTTP; Wed, 17 Aug 2016 07:15:30 -0700 (PDT) Received: by 10.157.3.77 with HTTP; Wed, 17 Aug 2016 07:15:30 -0700 (PDT) In-Reply-To: <21A9421B-2011-4B03-8E59-99771BCCE417@ackl.io> References: <5EEEE7E3-01F4-44C9-905F-05C7F19D9993@ackl.io> <21A9421B-2011-4B03-8E59-99771BCCE417@ackl.io> From: Evan Schwartz Date: Wed, 17 Aug 2016 16:15:30 +0200 Message-ID: To: Alexander Pelov Content-Type: multipart/alternative; boundary=001a113e20dc1c0c4c053a4519fb Archived-At: Cc: ledger@ietf.org Subject: Re: [Ledger] Question on Ledger and Sidechains X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 17 Aug 2016 14:15:55 -0000 --001a113e20dc1c0c4c053a4519fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The trade-off is that with sidechains you don't need any intermediary (because the ledgers understand one another) whereas with interledger you have an intermediary (that you don't need to trust because of the cryptographic holds) but you don't need the ledgers to be aware of one another at all. It might be simpler for one connector to make all the markets for all the ledgers but it wouldn't be very competitive unless inter-AS routing were the default. I don't think most people would be super happy with one company getting all the FX profits in the entire world. When the sender of a payment puts funds on hold the amount is fixed. The connector can either forward the payment or reject it if the rate has changed too much. In general though connectors have an incentive to appear reliable so they would likely build in some buffer to handle fluctuations and/or honor quotes that are a few seconds old even if the rate has changed a bit. On Aug 17, 2016 4:01 PM, "Alexander Pelov" wrote: > Hi Evan, > > Thanks for the explanation! > > I=E2=80=99d imagine that the principles behind the pegging to Bitcoin can= be > extended to many of the blockchains, and in some way, it seems to me the > =C2=AB connectors =C2=BB play the role of intermediary to such =C2=AB peg= ging =C2=BB. > > Do you expect to have many inter-AS routing? Wouldn=E2=80=99t it be simpl= er for a > =C2=AB connector =C2=BB provider to provide connectors between several le= dgers, thus > requiring one-hop only conversion? (this question is of course purely > hypothetical). Can we expect to have any-to-bitcoin, and then have in the > worst case a two-hop conversion? > > A think that I=E2=80=99m not clear about is what happens with fluctuating= exchange > rates? Do you expect something RSVP-like to try to guarantee some level o= f > consistency? For example, a seller would request 100 a-coins, and if I ha= ve > a 2-route hop, it may take time until the two transfers are complete.. so= , > I=E2=80=99m not going to be sure if I need to send 1 b-coin, or 1.02 b-co= ins.. > > Best, > Alexander > > > > Le 17 ao=C3=BBt 2016 =C3=A0 15:32, Evan Schwartz a =C3= =A9crit : > > Hi Alexander, > > Sidechains is a method for making new versions of the Bitcoin blockchain > where the value of the token on the new chain is pegged to the value of > Bitcoin. The primary purpose is enabling new features to be developed for > Bitcoin more easily. In theory some of the ideas from the paper could be > used to transfer other types of assets between ledgers but it depends on = a > fairly deep integration between the ledgers (the core concept is that one > blockchain is able to verify the state of the other). > > Interledger is an attempt at developing the most minimal protocol you > would need to enable assets to be transferred across any type of ledger > (blockchains and central ledgers alike) using cryptographic holds and thi= rd > party "connectors". You probably could use Interledger to create a two-wa= y > peg between two blockchains but thus far we've been thinking more about > creating competitive markets with variable exchange rates between ledgers= . > > Best, > Evan > > On Wed, Aug 17, 2016 at 3:18 PM, Alexander Pelov wrote: > >> Dear all, >> >> I was unable to attend the BoF, so please excuse me if the question I=E2= =80=99d >> like to address has been discussed (it was not in the minutes). >> >> How does the concept of Interchain relate to Sidechains, e.g. as the one= s >> introduced in https://www.blockstream.com/sidechains.pdf ? >> >> Is there any convergence? Possibly using Interchains to enable Sidechain= s? >> >> Best, >> Alexander >> >> _______________________________________________ >> Ledger mailing list >> Ledger@ietf.org >> https://www.ietf.org/mailman/listinfo/ledger >> > > > > -- > Evan Schwartz | Software Architect | Ripple > [image: ripple.com] > _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger > > > --001a113e20dc1c0c4c053a4519fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The trade-off is that with sidechains you don't need any= intermediary (because the ledgers understand one another) whereas with int= erledger you have an intermediary (that you don't need to trust because= of the cryptographic holds) but you don't need the ledgers to be aware= of one another at all.

It might be simpler for one connector to make all the market= s for all the ledgers but it wouldn't be very competitive unless inter-= AS routing were the default. I don't think most people would be super h= appy with one company getting all the FX profits in the entire world.

When the sender of a payment puts funds on hold the amount i= s fixed. The connector can either forward the payment or reject it if the r= ate has changed too much. In general though connectors have an incentive to= appear reliable so they would likely build in some buffer to handle fluctu= ations and/or honor quotes that are a few seconds old even if the rate has = changed a bit.


On Aug 17, 2016 4= :01 PM, "Alexander Pelov" <a@ackl= .io> wrote:
<= div style=3D"word-wrap:break-word">
Hi Evan,

T= hanks for the explanation!

I=E2=80=99d imagine tha= t the principles behind the pegging to Bitcoin can be extended to many of t= he blockchains, and in some way, it seems to me the =C2=AB=C2=A0connectors= =C2=A0=C2=BB play the role of intermediary to such =C2=AB=C2=A0pegging=C2= =A0=C2=BB.=C2=A0

Do you expect to have many inter-= AS routing? Wouldn=E2=80=99t it be simpler for a =C2=AB=C2=A0connector=C2= =A0=C2=BB provider to provide connectors between several ledgers, thus requ= iring one-hop only conversion? (this question is of course purely hypotheti= cal). Can we expect to have any-to-bitcoin, and then have in the worst case= a two-hop conversion?

A think that I=E2=80=99m no= t clear about is what happens with fluctuating exchange rates? Do you expec= t something RSVP-like to try to guarantee some level of consistency? For ex= ample, a seller would request 100 a-coins, and if I have a 2-route hop, it = may take time until the two transfers are complete.. so, I=E2=80=99m not go= ing to be sure if I need to send 1 b-coin, or 1.02 b-coins..=C2=A0

Best,
Alexander



Le 17 ao=C3=BBt 2016 =C3=A0 15:3= 2, Evan Schwartz <e= van@ripple.com> a =C3=A9crit :

Hi Ale= xander,

Sidechains is a method for making new versions o= f the Bitcoin blockchain where the value of the token on the new chain is p= egged to the value of Bitcoin. The primary purpose is enabling new features= to be developed for Bitcoin more easily. In theory some of the ideas from = the paper could be used to transfer other types of assets between ledgers b= ut it depends on a fairly deep integration between the ledgers (the core co= ncept is that one blockchain is able to verify the state of the other).

Interledger is an attempt at developing the most mini= mal protocol you would need to enable assets to be transferred across any t= ype of ledger (blockchains and central ledgers alike) using cryptographic h= olds and third party "connectors". You probably could use Interle= dger to create a two-way peg between two blockchains but thus far we've= been thinking more about creating competitive markets with variable exchan= ge rates between ledgers.

Best,
Evan

On Wed, A= ug 17, 2016 at 3:18 PM, Alexander Pelov <a@ackl.io> wrote:
Dear all,

I was unable to attend the BoF, so please excuse me if the question I=E2=80= =99d like to address has been discussed (it was not in the minutes).

How does the concept of Interchain relate to Sidechains, e.g. as the ones i= ntroduced in https://www.blockstream.com/sidechains.p= df ?

Is there any convergence? Possibly using Interchains to enable Sidechains?<= br>
Best,
Alexander

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



--
Evan Schwartz | S= oftware Architect | Ripple
3D"ripple.com"
_______________________________________________
Ledger mailing list=
Ledger@ietf.org
https://www.ietf.org/mailman/listinfo/ledger

--001a113e20dc1c0c4c053a4519fb-- From nobody Wed Aug 17 07:56:40 2016 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 A3A0C12DF74 for ; Wed, 17 Aug 2016 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTZs6DqVid64 for ; Wed, 17 Aug 2016 07:56:35 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CEC12D9FA for ; Wed, 17 Aug 2016 07:56:33 -0700 (PDT) Received: from mfilter42-d.gandi.net (mfilter42-d.gandi.net [217.70.178.172]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id BAB74C5A51; Wed, 17 Aug 2016 16:56:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter42-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter42-d.gandi.net (mfilter42-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id JQorXmQZPaRf; Wed, 17 Aug 2016 16:56:29 +0200 (CEST) X-Originating-IP: 109.8.208.86 Received: from [192.168.0.13] (86.208.8.109.rev.sfr.net [109.8.208.86]) (Authenticated sender: alex@ackl.io) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id C9CFFC5A50; Wed, 17 Aug 2016 16:56:27 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_8C8CDD73-FF4B-4B19-A499-10B42C62DC25" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alexander Pelov In-Reply-To: Date: Wed, 17 Aug 2016 16:56:27 +0200 Message-Id: <07632F56-C47C-40E5-876D-282469F4BC1F@ackl.io> References: <5EEEE7E3-01F4-44C9-905F-05C7F19D9993@ackl.io> <21A9421B-2011-4B03-8E59-99771BCCE417@ackl.io> To: Evan Schwartz X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ledger@ietf.org Subject: Re: [Ledger] Question on Ledger and Sidechains X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 17 Aug 2016 14:56:39 -0000 --Apple-Mail=_8C8CDD73-FF4B-4B19-A499-10B42C62DC25 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Evan, > Le 17 ao=C3=BBt 2016 =C3=A0 16:15, Evan Schwartz a = =C3=A9crit : >=20 > The trade-off is that with sidechains you don't need any intermediary = (because the ledgers understand one another) whereas with interledger = you have an intermediary (that you don't need to trust because of the = cryptographic holds) but you don't need the ledgers to be aware of one = another at all. >=20 > It might be simpler for one connector to make all the markets for all = the ledgers but it wouldn't be very competitive unless inter-AS routing = were the default. I don't think most people would be super happy with = one company getting all the FX profits in the entire world. >=20 As long as it=E2=80=99s cheap :) Otherwise, there could be competition = for all one-hop clearings.=20 I like the idea of having a standard way of querying the possible routes = and understanding the fees, then having the holds, even over one-hop. = Imagine that you have 5 big clearing companies which cover all ledgers, = and 30 smaller ones, that may have only partial ledger coverage.. My = worst-case fee is the min. of the fees of the 5 big clearing houses.=20 > When the sender of a payment puts funds on hold the amount is fixed. = The connector can either forward the payment or reject it if the rate = has changed too much. In general though connectors have an incentive to = appear reliable so they would likely build in some buffer to handle = fluctuations and/or honor quotes that are a few seconds old even if the = rate has changed a bit. >=20 If you have a one-hop transaction this would work. Then, it will all = depend on the time it takes for a transaction to be confirmed, and the = definition of what =C2=AB changed a bit =C2=BB is. If I remember = correctly, it takes about an hour to have a transaction in BitCoin. So, = if you do an A -> bitcoin -> B transaction, you=E2=80=99ll have your = money locked in the bitcoin for at least an hour. During this time the = fluctuations should be accepted by the (bitcoin -> B) connector. If you = add another hop, things could get even more unstable. And if any of the = connectors rejects the transaction, then the money on hold may actually = not be redeemable anymore (or at least, we should trust the connectors).=20= Maybe for the majority of the cases this would work. The users will = tell=E2=80=A6 In the protocol you are envisioning, is there a mechanism to include = information in the transaction, which sais: this is the route (A->B->C), = I=E2=80=99m using connectors AB and BC, I initiated the transaction at = time X, and at that time the exchange rate was 1:1.1 A->B, and 1.1:1 for = B:C. For the time X, AB takes fee of 0.001, and BC takes fee of 0.100 = per transaction. Thus, I, as a sender, know exactly how much A-coins I = need to send in order to get 100 B-coins (and pay the fees).=20 This, however, should be binding for the BC connector in some way. Maybe = announce this in the BGP routes, so I as a seller can decide if I prefer = a one-hop, single-player, or a multi-hop, stable connectors, or a = multi-hop, shoot-and-pray connector (with possibly much lower fee). And yet again, it all depends on the use-case and the real demand. Not = sure the goal is to build an overly complex protocol which no-one will = use. Best, Alexander > On Aug 17, 2016 4:01 PM, "Alexander Pelov" > wrote: > Hi Evan, >=20 > Thanks for the explanation! >=20 > I=E2=80=99d imagine that the principles behind the pegging to Bitcoin = can be extended to many of the blockchains, and in some way, it seems to = me the =C2=AB connectors =C2=BB play the role of intermediary to such =C2=AB= pegging =C2=BB.=20 >=20 > Do you expect to have many inter-AS routing? Wouldn=E2=80=99t it be = simpler for a =C2=AB connector =C2=BB provider to provide connectors = between several ledgers, thus requiring one-hop only conversion? (this = question is of course purely hypothetical). Can we expect to have = any-to-bitcoin, and then have in the worst case a two-hop conversion? >=20 > A think that I=E2=80=99m not clear about is what happens with = fluctuating exchange rates? Do you expect something RSVP-like to try to = guarantee some level of consistency? For example, a seller would request = 100 a-coins, and if I have a 2-route hop, it may take time until the two = transfers are complete.. so, I=E2=80=99m not going to be sure if I need = to send 1 b-coin, or 1.02 b-coins..=20 >=20 > Best, > Alexander >=20 >=20 >=20 >> Le 17 ao=C3=BBt 2016 =C3=A0 15:32, Evan Schwartz > a =C3=A9crit : >>=20 >> Hi Alexander, >>=20 >> Sidechains is a method for making new versions of the Bitcoin = blockchain where the value of the token on the new chain is pegged to = the value of Bitcoin. The primary purpose is enabling new features to be = developed for Bitcoin more easily. In theory some of the ideas from the = paper could be used to transfer other types of assets between ledgers = but it depends on a fairly deep integration between the ledgers (the = core concept is that one blockchain is able to verify the state of the = other). >>=20 >> Interledger is an attempt at developing the most minimal protocol you = would need to enable assets to be transferred across any type of ledger = (blockchains and central ledgers alike) using cryptographic holds and = third party "connectors". You probably could use Interledger to create a = two-way peg between two blockchains but thus far we've been thinking = more about creating competitive markets with variable exchange rates = between ledgers. >>=20 >> Best, >> Evan >>=20 >> On Wed, Aug 17, 2016 at 3:18 PM, Alexander Pelov > wrote: >> Dear all, >>=20 >> I was unable to attend the BoF, so please excuse me if the question = I=E2=80=99d like to address has been discussed (it was not in the = minutes). >>=20 >> How does the concept of Interchain relate to Sidechains, e.g. as the = ones introduced in https://www.blockstream.com/sidechains.pdf = ? >>=20 >> Is there any convergence? Possibly using Interchains to enable = Sidechains? >>=20 >> Best, >> Alexander >>=20 >> _______________________________________________ >> Ledger mailing list >> Ledger@ietf.org >> https://www.ietf.org/mailman/listinfo/ledger = >>=20 >>=20 >>=20 >> --=20 >> Evan Schwartz | Software Architect | Ripple >> _______________________________________________ >> Ledger mailing list >> Ledger@ietf.org >> https://www.ietf.org/mailman/listinfo/ledger = >=20 > _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger --Apple-Mail=_8C8CDD73-FF4B-4B19-A499-10B42C62DC25 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Evan,

Le 17 ao=C3=BBt 2016 =C3=A0 = 16:15, Evan Schwartz <evan@ripple.com> a =C3=A9crit :

The trade-off is that with sidechains you don't need any = intermediary (because the ledgers understand one another) whereas with = interledger you have an intermediary (that you don't need to trust = because of the cryptographic holds) but you don't need the ledgers to be = aware of one another at all.

It might be = simpler for one connector to make all the markets for all the ledgers = but it wouldn't be very competitive unless inter-AS routing were the = default. I don't think most people would be super happy with one company = getting all the FX profits in the entire = world.

As long as it=E2=80=99s cheap :) = Otherwise, there could be competition for all one-hop = clearings. 

I like the idea of = having a standard way of querying the possible routes and understanding = the fees, then having the holds, even over one-hop. Imagine that you = have 5 big clearing companies which cover all ledgers, and 30 smaller = ones, that may have only partial ledger coverage.. My worst-case fee is = the min. of the fees of the 5 big clearing houses. 

When the sender of a payment puts funds on hold = the amount is fixed. The connector can either forward the payment or = reject it if the rate has changed too much. In general though connectors = have an incentive to appear reliable so they would likely build in some = buffer to handle fluctuations and/or honor quotes that are a few seconds = old even if the rate has changed a bit.

If = you have a one-hop transaction this would work. Then, it will all depend = on the time it takes for a transaction to be confirmed, and the = definition of what =C2=AB changed a bit =C2=BB is. If I = remember correctly, it takes about an hour to have a transaction in = BitCoin. So, if you do an A -> bitcoin -> B transaction, you=E2=80=99= ll have your money locked in the bitcoin for at least an hour. During = this time the fluctuations should be accepted by the (bitcoin -> B) = connector. If you add another hop, things could get even more unstable. = And if any of the connectors rejects the transaction, then the money on = hold may actually not be redeemable anymore (or at least, we should = trust the connectors). 

Maybe = for the majority of the cases this would work. The users will = tell=E2=80=A6

In the protocol you = are envisioning, is there a mechanism to include information in the = transaction, which sais: this is the route (A->B->C), I=E2=80=99m = using connectors AB and BC, I initiated the transaction at time X, and = at that time the exchange rate was 1:1.1 A->B, and 1.1:1 for B:C. For = the time X, AB takes fee of 0.001, and BC takes fee of 0.100 per = transaction. Thus, I, as a sender, know exactly how much A-coins I need = to send in order to get 100 B-coins (and pay the = fees). 

This, however, should = be binding for the BC connector in some way. Maybe announce this in the = BGP routes, so I as a seller can decide if I prefer a one-hop, = single-player, or a multi-hop, stable connectors, or a multi-hop, = shoot-and-pray connector (with possibly much lower fee).


And yet again, it all = depends on the use-case and the real demand. Not sure the goal is to = build an overly complex protocol which no-one will use.

Best,
Alexander




On Aug 17, 2016 4:01 = PM, "Alexander Pelov" <a@ackl.io> wrote:
Hi = Evan,

Thanks = for the explanation!

I=E2=80=99d imagine that the principles behind the pegging to = Bitcoin can be extended to many of the blockchains, and in some way, it = seems to me the =C2=AB connectors =C2=BB play the role of = intermediary to such =C2=AB pegging =C2=BB. 

Do you expect to have = many inter-AS routing? Wouldn=E2=80=99t it be simpler for a = =C2=AB connector =C2=BB provider to provide connectors between = several ledgers, thus requiring one-hop only conversion? (this question = is of course purely hypothetical). Can we expect to have any-to-bitcoin, = and then have in the worst case a two-hop conversion?

A think that I=E2=80=99m = not clear about is what happens with fluctuating exchange rates? Do you = expect something RSVP-like to try to guarantee some level of = consistency? For example, a seller would request 100 a-coins, and if I = have a 2-route hop, it may take time until the two transfers are = complete.. so, I=E2=80=99m not going to be sure if I need to send 1 = b-coin, or 1.02 b-coins.. 

Best,
Alexander



Le 17 ao=C3=BBt 2016 =C3=A0 = 15:32, Evan Schwartz <evan@ripple.com> a =C3=A9crit = :

Hi = Alexander,

Sidechains = is a method for making new versions of the Bitcoin blockchain where the = value of the token on the new chain is pegged to the value of Bitcoin. = The primary purpose is enabling new features to be developed for Bitcoin = more easily. In theory some of the ideas from the paper could be used to = transfer other types of assets between ledgers but it depends on a = fairly deep integration between the ledgers (the core concept is that = one blockchain is able to verify the state of the other).

Interledger is an = attempt at developing the most minimal protocol you would need to enable = assets to be transferred across any type of ledger (blockchains and = central ledgers alike) using cryptographic holds and third party = "connectors". You probably could use Interledger to create a two-way peg = between two blockchains but thus far we've been thinking more about = creating competitive markets with variable exchange rates between = ledgers.

Best,
Evan

On Wed, = Aug 17, 2016 at 3:18 PM, Alexander Pelov <a@ackl.io> wrote:
Dear all,

I was unable to attend the BoF, so please excuse me if the question = I=E2=80=99d like to address has been discussed (it was not in the = minutes).

How does the concept of Interchain relate to Sidechains, e.g. as the = ones introduced in https://www.blockstream.com/sidechains.pdf = ?

Is there any convergence? Possibly using Interchains to enable = Sidechains?

Best,
Alexander

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



--
Evan Schwartz | = Software Architect | Ripple
3D"ripple.com"
_______________________________________________
Ledger mailing list
Ledger@ietf.org
https://www.ietf.org/mailman/listinfo/ledger

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

= --Apple-Mail=_8C8CDD73-FF4B-4B19-A499-10B42C62DC25-- From nobody Thu Aug 18 06:47:36 2016 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 6C5A612D776 for ; Thu, 18 Aug 2016 06:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 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, T_FILL_THIS_FORM_SHORT=0.01, T_REMOTE_IMAGE=0.01] 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 Gi1w_mLytRHG for ; Thu, 18 Aug 2016 06:47:32 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 0D23A12D74D for ; Thu, 18 Aug 2016 06:47:32 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id l203so22766890oib.1 for ; Thu, 18 Aug 2016 06:47:32 -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=4n2M4z3jvPU20IfxxSMkkr9271bIgBQhJ8tJLhCM9ao=; b=CUEfa/dqze7Tvs6WUpIG4vLhlopRv5k7RVv72yDMfDVvqhFRML6wSnhjXqH9lpDbet oZAzFnzaWvKLxuBPMfn7zxiNFBN2T4LPwyCjaLICo3N9YLBk8w8tIgoKZyExUQNI3c9s D3SjPexRrgCQZS/QHFt+OT/aMamvyw8lU4feY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4n2M4z3jvPU20IfxxSMkkr9271bIgBQhJ8tJLhCM9ao=; b=Q4ZA37Du8s2aXcriCG/Ho09DaH5aPQUrXgX5hkl7FxNOfoCztQZ5sIBD0tWcASI7qO vh4RN6nq68RPseE3Q6vXIU23IMP/WJTdIK9JYTC7QllVF2g7vR07HVA3hGu47SLl7TGd XhKPPH4Uqo8ELZPfsnm0BVdyR+I4x72OCe/7xg8M9zY289qJeQpFhfy33rFO9wFRismy 08Wy/zndxU05hy53DZNjdysPWhvg+s5aHjuyvIxOG7n6uCt9IxKV6wC2AdcbtjUrTHRV s4U/BPQQem/SX873dliGveMKFqlGLc+jtDKlXomF7uXXhML3mpHvH7TDCrUD/3tcCWMs Z/RQ== X-Gm-Message-State: AEkoouspz2My+NCtGb34wgoYtKUve8a1r5BEYoM7T+s51ybSgJVudrc8QMYb2LrpZfZMNBhOdfQLiDtK2mLH4bsL X-Received: by 10.157.19.1 with SMTP id f1mr1287519ote.53.1471528051319; Thu, 18 Aug 2016 06:47:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.3.77 with HTTP; Thu, 18 Aug 2016 06:47:10 -0700 (PDT) In-Reply-To: <07632F56-C47C-40E5-876D-282469F4BC1F@ackl.io> References: <5EEEE7E3-01F4-44C9-905F-05C7F19D9993@ackl.io> <21A9421B-2011-4B03-8E59-99771BCCE417@ackl.io> <07632F56-C47C-40E5-876D-282469F4BC1F@ackl.io> From: Evan Schwartz Date: Thu, 18 Aug 2016 15:47:10 +0200 Message-ID: To: Alexander Pelov Content-Type: multipart/alternative; boundary=001a1141f534c6c128053a58d279 Archived-At: Cc: ledger@ietf.org Subject: Re: [Ledger] Question on Ledger and Sidechains X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 18 Aug 2016 13:47:35 -0000 --001a1141f534c6c128053a58d279 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > I like the idea of having a standard way of querying the possible routes > and understanding the fees, then having the holds, even over one-hop Me too :) Regarding holding funds. You're right that the longer you hold funds (either because of multiple hops or because of slow ledgers), the more the connectors will need to account for price volatility in their fees. I would expect this to create quite an incentive to make ledgers more performant. This could be accomplished either by upgrading the ledger or by using payment channels like the Lightning team is working on to increase the speed of sending payments over a specific ledger= . Regarding carrying rate information with the payment. There's actually an easier way to ensure that connectors deliver the correct amount of money. The interledger packet has two key pieces of information: address and amount. The amount is the amount that must be delivered to the recipient. The source amount is set when the sender puts the first transfer (with a fixed amount) on hold. Each connector may pass on however much money they choose. However, if each connector (or even one) takes too much, the recipient will get a notification for a held transfer that has less money than the packet stipulates. They would refuse to produce the condition fulfillment, so all of the transfers would be rolled back. If this happens a lot with a particular connector you'd want to choose a different one. Now, the obvious question is what happens if someone tampers with the packet? The Interledger Payment Request spec provides a recommendation for how recipients can use a MAC of the packet details in the condition so the condition serves as an integrity check as well. There's a chance we will end up seeing different connectors offering different QoS, but I think building it in at this point would be premature optimization. Not sure the goal is to build an overly complex protocol which no-one will > use. Definitely hoping to avoid that. On Wed, Aug 17, 2016 at 4:56 PM, Alexander Pelov wrote: > Dear Evan, > > Le 17 ao=C3=BBt 2016 =C3=A0 16:15, Evan Schwartz a =C3= =A9crit : > > The trade-off is that with sidechains you don't need any intermediary > (because the ledgers understand one another) whereas with interledger you > have an intermediary (that you don't need to trust because of the > cryptographic holds) but you don't need the ledgers to be aware of one > another at all. > > It might be simpler for one connector to make all the markets for all the > ledgers but it wouldn't be very competitive unless inter-AS routing were > the default. I don't think most people would be super happy with one > company getting all the FX profits in the entire world. > > As long as it=E2=80=99s cheap :) Otherwise, there could be competition fo= r all > one-hop clearings. > > I like the idea of having a standard way of querying the possible routes > and understanding the fees, then having the holds, even over one-hop. > Imagine that you have 5 big clearing companies which cover all ledgers, a= nd > 30 smaller ones, that may have only partial ledger coverage.. My worst-ca= se > fee is the min. of the fees of the 5 big clearing houses. > > When the sender of a payment puts funds on hold the amount is fixed. The > connector can either forward the payment or reject it if the rate has > changed too much. In general though connectors have an incentive to appea= r > reliable so they would likely build in some buffer to handle fluctuations > and/or honor quotes that are a few seconds old even if the rate has chang= ed > a bit. > > If you have a one-hop transaction this would work. Then, it will all > depend on the time it takes for a transaction to be confirmed, and the > definition of what =C2=AB changed a bit =C2=BB is. If I remember correctl= y, it takes > about an hour to have a transaction in BitCoin. So, if you do an A -> > bitcoin -> B transaction, you=E2=80=99ll have your money locked in the bi= tcoin for > at least an hour. During this time the fluctuations should be accepted by > the (bitcoin -> B) connector. If you add another hop, things could get ev= en > more unstable. And if any of the connectors rejects the transaction, then > the money on hold may actually not be redeemable anymore (or at least, we > should trust the connectors). > > Maybe for the majority of the cases this would work. The users will tell= =E2=80=A6 > > In the protocol you are envisioning, is there a mechanism to include > information in the transaction, which sais: this is the route (A->B->C), > I=E2=80=99m using connectors AB and BC, I initiated the transaction at ti= me X, and > at that time the exchange rate was 1:1.1 A->B, and 1.1:1 for B:C. For the > time X, AB takes fee of 0.001, and BC takes fee of 0.100 per transaction. > Thus, I, as a sender, know exactly how much A-coins I need to send in ord= er > to get 100 B-coins (and pay the fees). > > This, however, should be binding for the BC connector in some way. Maybe > announce this in the BGP routes, so I as a seller can decide if I prefer = a > one-hop, single-player, or a multi-hop, stable connectors, or a multi-hop= , > shoot-and-pray connector (with possibly much lower fee). > > > And yet again, it all depends on the use-case and the real demand. Not > sure the goal is to build an overly complex protocol which no-one will us= e. > > Best, > Alexander > > > > > On Aug 17, 2016 4:01 PM, "Alexander Pelov" wrote: > >> Hi Evan, >> >> Thanks for the explanation! >> >> I=E2=80=99d imagine that the principles behind the pegging to Bitcoin ca= n be >> extended to many of the blockchains, and in some way, it seems to me the >> =C2=AB connectors =C2=BB play the role of intermediary to such =C2=AB pe= gging =C2=BB. >> >> Do you expect to have many inter-AS routing? Wouldn=E2=80=99t it be simp= ler for a >> =C2=AB connector =C2=BB provider to provide connectors between several l= edgers, thus >> requiring one-hop only conversion? (this question is of course purely >> hypothetical). Can we expect to have any-to-bitcoin, and then have in th= e >> worst case a two-hop conversion? >> >> A think that I=E2=80=99m not clear about is what happens with fluctuatin= g >> exchange rates? Do you expect something RSVP-like to try to guarantee so= me >> level of consistency? For example, a seller would request 100 a-coins, a= nd >> if I have a 2-route hop, it may take time until the two transfers are >> complete.. so, I=E2=80=99m not going to be sure if I need to send 1 b-co= in, or 1.02 >> b-coins.. >> >> Best, >> Alexander >> >> >> >> Le 17 ao=C3=BBt 2016 =C3=A0 15:32, Evan Schwartz a =C3= =A9crit : >> >> Hi Alexander, >> >> Sidechains is a method for making new versions of the Bitcoin blockchain >> where the value of the token on the new chain is pegged to the value of >> Bitcoin. The primary purpose is enabling new features to be developed fo= r >> Bitcoin more easily. In theory some of the ideas from the paper could be >> used to transfer other types of assets between ledgers but it depends on= a >> fairly deep integration between the ledgers (the core concept is that on= e >> blockchain is able to verify the state of the other). >> >> Interledger is an attempt at developing the most minimal protocol you >> would need to enable assets to be transferred across any type of ledger >> (blockchains and central ledgers alike) using cryptographic holds and th= ird >> party "connectors". You probably could use Interledger to create a two-w= ay >> peg between two blockchains but thus far we've been thinking more about >> creating competitive markets with variable exchange rates between ledger= s. >> >> Best, >> Evan >> >> On Wed, Aug 17, 2016 at 3:18 PM, Alexander Pelov wrote: >> >>> Dear all, >>> >>> I was unable to attend the BoF, so please excuse me if the question I= =E2=80=99d >>> like to address has been discussed (it was not in the minutes). >>> >>> How does the concept of Interchain relate to Sidechains, e.g. as the >>> ones introduced in https://www.blockstream.com/sidechains.pdf ? >>> >>> Is there any convergence? Possibly using Interchains to enable >>> Sidechains? >>> >>> Best, >>> Alexander >>> >>> _______________________________________________ >>> Ledger mailing list >>> Ledger@ietf.org >>> https://www.ietf.org/mailman/listinfo/ledger >>> >> >> >> >> -- >> Evan Schwartz | Software Architect | Ripple >> [image: ripple.com] >> _______________________________________________ >> Ledger mailing list >> Ledger@ietf.org >> https://www.ietf.org/mailman/listinfo/ledger >> >> >> _______________________________________________ > Ledger mailing list > Ledger@ietf.org > https://www.ietf.org/mailman/listinfo/ledger > > > --=20 Evan Schwartz | Software Architect | Ripple [image: ripple.com] --001a1141f534c6c128053a58d279 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like the idea of having a standard way of queryi= ng the possible routes and understanding the fees, then having the holds, e= ven over one-hop

Me too :)

Regarding holding funds. You're right that the longer y= ou hold funds (either because of multiple hops or because of slow ledgers),= the more the connectors will need to account for price volatility in their= fees. I would expect this to create quite an incentive to make ledgers mor= e performant. This could be accomplished either by upgrading the ledger or = by using payment channels like the Lig= htning team is working on to increase the speed of sending payments ove= r a specific ledger.

Regarding carrying rate infor= mation with the payment. There's actually an easier way to ensure that = connectors deliver the correct amount of money. The interledger packet has = two key pieces of information: address and amount. The amount is the amount= that must be delivered to the recipient. The source amount is set when the= sender puts the first transfer (with a fixed amount) on hold. Each connect= or may pass on however much money they choose. However, if each connector (= or even one) takes too much, the recipient will get a notification for a he= ld transfer that has less money than the packet stipulates. They would refu= se to produce the condition fulfillment, so all of the transfers would be r= olled back. If this happens a lot with a particular connector you'd wan= t to choose a different one. Now, the obvious question is what happens if s= omeone tampers with the packet? The Interledger Payment Request spec provides a recommendati= on for how recipients can use a MAC of the packet details in the condition = so the condition serves as an integrity check as well.

=
There's a chance we will end up seeing different connectors offeri= ng different QoS, but I think building it in at this point would be prematu= re optimization.

Not sure the goal is to build = an overly complex protocol which no-one will use.
<= br>
Definitely hoping to avoid that.=C2=A0

On Wed, Aug 17, 2016 at 4:5= 6 PM, Alexander Pelov <a@ackl.io> wrote:
Dear Evan,

Le 17 ao=C3=BBt 2016 =C3=A0 1= 6:15, Evan Schwartz <evan@ripple.com> a =C3=A9crit :

The t= rade-off is that with sidechains you don't need any intermediary (becau= se the ledgers understand one another) whereas with interledger you have an= intermediary (that you don't need to trust because of the cryptographi= c holds) but you don't need the ledgers to be aware of one another at a= ll.

It might be simpler for one connector to make all the= markets for all the ledgers but it wouldn't be very competitive unless= inter-AS routing were the default. I don't think most people would be = super happy with one company getting all the FX profits in the entire world= .

As long as it=E2=80=99s cheap :) Otherw= ise, there could be competition for all one-hop clearings.=C2=A0
=
I like the idea of having a standard way of querying the possible= routes and understanding the fees, then having the holds, even over one-ho= p. Imagine that you have 5 big clearing companies which cover all ledgers, = and 30 smaller ones, that may have only partial ledger coverage.. My worst-= case fee is the min. of the fees of the 5 big clearing houses.=C2=A0

When the sender= of a payment puts funds on hold the amount is fixed. The connector can eit= her forward the payment or reject it if the rate has changed too much. In g= eneral though connectors have an incentive to appear reliable so they would= likely build in some buffer to handle fluctuations and/or honor quotes tha= t are a few seconds old even if the rate has changed a bit.

If you have a one-hop transaction this would work. Then,= it will all depend on the time it takes for a transaction to be confirmed,= and the definition of what =C2=AB=C2=A0changed a bit=C2=A0=C2=BB is. If I = remember correctly, it takes about an hour to have a transaction in BitCoin= . So, if you do an A -> bitcoin -> B transaction, you=E2=80=99ll have= your money locked in the bitcoin for at least an hour. During this time th= e fluctuations should be accepted by the (bitcoin -> B) connector. If yo= u add another hop, things could get even more unstable. And if any of the c= onnectors rejects the transaction, then the money on hold may actually not = be redeemable anymore (or at least, we should trust the connectors).=C2=A0<= /div>

Maybe for the majority of the cases this would wor= k. The users will tell=E2=80=A6

In the protocol yo= u are envisioning, is there a mechanism to include information in the trans= action, which sais: this is the route (A->B->C), I=E2=80=99m using co= nnectors AB and BC, I initiated the transaction at time X, and at that time= the exchange rate was 1:1.1 A->B, and 1.1:1 for B:C. For the time X, AB= takes fee of 0.001, and BC takes fee of 0.100 per transaction. Thus, I, as= a sender, know exactly how much A-coins I need to send in order to get 100= B-coins (and pay the fees).=C2=A0

This, however, = should be binding for the BC connector in some way. Maybe announce this in = the BGP routes, so I as a seller can decide if I prefer a one-hop, single-p= layer, or a multi-hop, stable connectors, or a multi-hop, shoot-and-pray co= nnector (with possibly much lower fee).


=
And yet again, it all depends on the use-case and the real demand. Not= sure the goal is to build an overly complex protocol which no-one will use= .

Best,
Alexander




On Aug= 17, 2016 4:01 PM, "Alexander Pelov" <a@ackl.io> wrote:
Hi Eva= n,

Thanks for the explanation!

I=E2=80=99d imagine that the principles behind the pegging to Bitcoin= can be extended to many of the blockchains, and in some way, it seems to m= e the =C2=AB=C2=A0connectors=C2=A0=C2=BB play the role of intermediary to s= uch =C2=AB=C2=A0pegging=C2=A0=C2=BB.=C2=A0

Do you = expect to have many inter-AS routing? Wouldn=E2=80=99t it be simpler for a = =C2=AB=C2=A0connector=C2=A0=C2=BB provider to provide connectors between se= veral ledgers, thus requiring one-hop only conversion? (this question is of= course purely hypothetical). Can we expect to have any-to-bitcoin, and the= n have in the worst case a two-hop conversion?

A t= hink that I=E2=80=99m not clear about is what happens with fluctuating exch= ange rates? Do you expect something RSVP-like to try to guarantee some leve= l of consistency? For example, a seller would request 100 a-coins, and if I= have a 2-route hop, it may take time until the two transfers are complete.= . so, I=E2=80=99m not going to be sure if I need to send 1 b-coin, or 1.02 = b-coins..=C2=A0

Best,
Alexander



Le 17 ao= =C3=BBt 2016 =C3=A0 15:32, Evan Schwartz <evan@ripple.com> a =C3=A9crit :

Hi Alexander,

Sidechains is a method f= or making new versions of the Bitcoin blockchain where the value of the tok= en on the new chain is pegged to the value of Bitcoin. The primary purpose = is enabling new features to be developed for Bitcoin more easily. In theory= some of the ideas from the paper could be used to transfer other types of = assets between ledgers but it depends on a fairly deep integration between = the ledgers (the core concept is that one blockchain is able to verify the = state of the other).

Interledger is an attempt at = developing the most minimal protocol you would need to enable assets to be = transferred across any type of ledger (blockchains and central ledgers alik= e) using cryptographic holds and third party "connectors". You pr= obably could use Interledger to create a two-way peg between two blockchain= s but thus far we've been thinking more about creating competitive mark= ets with variable exchange rates between ledgers.

= Best,
Evan

On Wed, Aug 17, 2016 at 3:18 PM, Alexander Pelov <a@ackl.io&g= t; wrote:
Dear all,

I was unable to attend the BoF, so please excuse me if the question I=E2=80= =99d like to address has been discussed (it was not in the minutes).

How does the concept of Interchain relate to Sidechains, e.g. as the ones i= ntroduced in https://www.blockstream.com/sidechains.p= df ?

Is there any convergence? Possibly using Interchains to enable Sidechains?<= br>
Best,
Alexander

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



--
Evan Schwartz | S= oftware Architect | Ripple
3D"ripple.com"
_______________________________________________
Ledger mailing list=
Ledger@ietf.org
https://www.ietf.org/mailman/listinfo/ledger

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



=

--
<= div>
Evan Schwartz | Software Archite= ct | Ripple
--001a1141f534c6c128053a58d279-- From nobody Tue Aug 23 00:10:54 2016 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 D669D12B006 for ; Tue, 23 Aug 2016 00:10:52 -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 0y2iKkN4s-XP for ; Tue, 23 Aug 2016 00:10:51 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 E4859120727 for ; Tue, 23 Aug 2016 00:10:50 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id l203so184886953oib.1 for ; Tue, 23 Aug 2016 00:10:50 -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=Yjv3rQsOeOpmb6T3QWkPvGrN4RjeYHv8BPMCWOI1tog=; b=lh42Iz+UKGKRUPYe2cSu1V4aOjsSPPeX3vvnn1tlIj2XmAxmF5gkaYHMBh0fOqVjq8 MtyRV0Mq+prbBZ6DyrzKXiI1Mx3ji11weegQfn+BqAClHSB+1et3jQX+2N2ngUXWSFOt GI/3ha9B7GyQ4HkFMRZKgzWsablDbZHpz9Bgs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Yjv3rQsOeOpmb6T3QWkPvGrN4RjeYHv8BPMCWOI1tog=; b=EG3mf5QlD0mLuxqY3BIEzCVxpX4tEYtqJhKnn66EdiDu2iQD47cfTmNDnWRP9TQliV N3zexvObepubqZCDEaS6rSGrASzGKRWwtDqB2sCoQMI1gNRCoxwudipjnW/Mkcd28VNr kaLzKGjl8NmNDBg0BCDpRzdfNOFqHjvRV2Qw7ZdI5lzY8blp/Zp56sdBE4fd8HWwJELB 0+khFKMP1dfmRjhmh8lPn0r6Uob8Pc5PHuafSlBiZG4vqzNrQDEH/jGx+d1Rx6ofXLoQ 6lfa5meXRDNwDumO6Sq7BoUe//rZ9xO9aeutDQFs0VVjJy8QlCOBEvd8X/67kjD4Op9k OBbg== X-Gm-Message-State: AEkoouuNoDms4qPJ2PsV9XzBHq0A2pqkRECttvq7Y1Uc0flp16S+nX0vrb6fyXoe0aBxGliX9wdJ8sp7sDjwog== X-Received: by 10.157.29.217 with SMTP id w25mr14196003otw.36.1471936250174; Tue, 23 Aug 2016 00:10:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.172.212 with HTTP; Tue, 23 Aug 2016 00:10:49 -0700 (PDT) From: Adrian Hope-Bailie Date: Tue, 23 Aug 2016 09:10:49 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary=001a113e35da52f799053ab7dda5 Archived-At: Subject: [Ledger] AGENDA - Community Call - Wed 24 August - 3pm UTC X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 23 Aug 2016 07:10:53 -0000 --001a113e35da52f799053ab7dda5 Content-Type: text/plain; charset=UTF-8 Hi all, We have our bi-weekly community call this Wednesday. Dial in details at the bottom. *Community Updates* - Started using gitter: --> https://gitter.im/interledger/Lobby --> https://gitter.im/interledger/rfcs --> https://gitter.im/interledger/java-crypto-conditions --> https://gitter.im/interledger/java-ilp-core - IETF mailing list (ledger@ietf.org - https://www.ietf.org/mailman/ listinfo/ledger) *Proposed crypto-condition changes* - https://github.com/interledger/rfcs/issues/78 - https://github.com/interledger/rfcs/issues/86 - https://github.com/interledger/rfcs/issues/87 - Current plan is to keep the current CC stable and release a draft 01 representing the current state of all implementations. Then start work towards a draft 02 which includes the changes mentioned above. *Binary format status* - Plan to encapsulate most of it in ilp-core, so everyone else doesn't have to worry about it. - We had previously thought that we would reimplement ILP in every language. Now adopted a more nuanced view - need implementations in JavaScript (browsers, web), C (support most languages through bindings; embedded systems), Java (to support JVM), C# (to support .NET), Python (large amount of interest). But not much more for now. - Javascript and Java have started on GitHub looking for others To join the meeting, go to: https://bluejeans.com/795795755 (Try your iPhone or Android phone) Just want to dial in? (http://bluejeans.com/numbers) Enter Meeting ID: 795795755 Live scribe via IRC: irc.3w.org #interledger Adrian --001a113e35da52f799053ab7dda5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We have our bi-weekly commu= nity call this Wednesday.
Dial in details at the bottom.
=
Community Updates

Proposed crypto-condition changes
- Current plan is to keep = the current CC stable and release a draft 01=20 representing the current state of all implementations. Then start=20 work towards a draft 02 which includes the changes mentioned above.

Binary format status
- Plan to encapsula= te most of it in ilp-core, so everyone else doesn't have to worry about= it.
- We had previously thought that we would reimplement ILP in every language.= =20 Now adopted a more nuanced view - need implementations in JavaScript=20 (browsers, web), C (support most languages through bindings; embedded=20 systems), Java (to support JVM), C# (to support .NET), Python (large=20 amount of interest). But not much more for now.
- Javascript = and Java have started on GitHub looking for others

To joi= n the meeting, go to:
https://bluejeans.com/795795755
(Try your iPhone or= Android phone)

Just want to dial in? (http://bluejeans.com/numbers)
Enter Me= eting ID: 795795755

Live scribe via IRC: irc.3w.org #interledger

Adrian
--001a113e35da52f799053ab7dda5-- From nobody Wed Aug 24 06:31:21 2016 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 258D512D11F for ; Wed, 24 Aug 2016 06:31:20 -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 6l506yqGlz2B for ; Wed, 24 Aug 2016 06:31:18 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 5242412DD39 for ; Wed, 24 Aug 2016 06:31:18 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id f189so22089565oig.3 for ; Wed, 24 Aug 2016 06:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=a63SYHV+Tez3jiRe7SLIlcJpbvCRTvo2cU+eSTEbyVk=; b=CtpzXasV0NBJThdrAQTtUXGaiG+d0xcisqOVAttJYl1C/ECIwtmer2x04eqwVwbeJa sZzAX9seiwX/kzn1p/hJCHuc1e57hM/MVPQEMQqqZQUTUrLXraGH5QAWPbBLU4aYoeos hvJni/wKV9cF9htXGxVySpgPOyYlaiDQvoC189cwE/n+pSthevTOPBMqHtkRkORIoN9z aRYaEjSXJbE49i5ItvDHnPjax3ZsJn0DxjuaUCqCB6IQI85H+P5mcr2OKeb/qt6GsPlQ TWDjXmP6XczCK54Xx7wKMx6wQMN/6NnNCxMo+c1ywzwHuOqcLMOKx11Qgdbllvu2cJEw Ps4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=a63SYHV+Tez3jiRe7SLIlcJpbvCRTvo2cU+eSTEbyVk=; b=Wx9MOsJKYzC9XVklACLrI1gFR7oMzhTleJaeGkGIAm3XI9rTNZ6TQRV/6FNnDWXZA4 mte9BGZkdHlbqdH8AIS1vB+KlCxKPhPF7uBAOewRcgTi0fr+LODx4HapaOjAi77LLDUl SNp/u2gddnnPdNOpRfZH3ojj2X1vsqMlv8D68438dN6AiN0ysP5iDY9Zb2bOfSm/fYZT sx7LzI9LYgHUHwxgdf1o8GPz78BoIbFu21Ws76DNh6az1cdMWe2nO9fpSgyowxzPJY2o Pgv1WQ44XIihhOVr2o9IJegkuw1Iz5BQVpnmsDTX01NJD6BXljQuhQGTN87uzXYvgM55 eJWA== X-Gm-Message-State: AE9vXwNdXYLSJuXdEwbosN+/FPKkZ2GdWvwLIJ8GuDq8MrP6k2n8LnfKwrrXVITEPQzExQ== X-Received: by 10.157.45.101 with SMTP id v92mr1744218ota.192.1472045477579; Wed, 24 Aug 2016 06:31:17 -0700 (PDT) Received: from [172.18.133.61] (cowboy.intuit.com. [65.204.229.11]) by smtp.gmail.com with ESMTPSA id r38sm4060822ota.22.2016.08.24.06.31.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Aug 2016 06:31:15 -0700 (PDT) To: Adrian Hope-Bailie , Interledger Community Group , Interledger Mailing List - IETF References: From: Yaron Sheffer Message-ID: <58fa64dd-bccb-e42c-0f5b-b2c847a2d7c6@gmail.com> Date: Wed, 24 Aug 2016 16:31:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F76E02EA860F60AD9614B4CA" Archived-At: Subject: Re: [Ledger] AGENDA - Community Call - Wed 24 August - 3pm UTC X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 13:31:20 -0000 This is a multi-part message in MIME format. --------------F76E02EA860F60AD9614B4CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit *Binary format status* > - Plan to encapsulate most of it in ilp-core, so everyone else doesn't > have to worry about it. > - We had previously thought that we would reimplement ILP in every > language. Now adopted a more nuanced view - need implementations in > JavaScript (browsers, web), C (support most languages through > bindings; embedded systems), Java (to support JVM), C# (to support > .NET), Python (large amount of interest). But not much more for now. > - Javascript and Java have started on GitHub looking for others > > Hi Adrian, C is notoriously unsuitable for security-sensitive code. As an outside observer, I would suggest that you look at alternatives. My favorite would be Go with a thin C shim on top. A more realistic alternative would be C++ with a C interface. Thanks, Yaron --------------F76E02EA860F60AD9614B4CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Binary format status
- Plan to encapsulate most of it in ilp-core, so everyone else doesn't have to worry about it.
- We had previously thought that we would reimplement ILP in every language. Now adopted a more nuanced view - need implementations in JavaScript (browsers, web), C (support most languages through bindings; embedded systems), Java (to support JVM), C# (to support .NET), Python (large amount of interest). But not much more for now.
- Javascript and Java have started on GitHub looking for others


Hi Adrian,

C is notoriously unsuitable for security-sensitive code. As an outside observer, I would suggest that you look at alternatives. My favorite would be Go with a thin C shim on top. A more realistic alternative would be C++ with a C interface.

Thanks,
    Yaron
--------------F76E02EA860F60AD9614B4CA-- From nobody Wed Aug 24 06:39:33 2016 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 67A6512DD5A for ; Wed, 24 Aug 2016 06:39:32 -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 RovP3jdI3nkY for ; Wed, 24 Aug 2016 06:39:31 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 0622612D0DC for ; Wed, 24 Aug 2016 06:39:31 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id l203so22526793oib.1 for ; Wed, 24 Aug 2016 06:39:30 -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=8l9OwR/a+0SnhmEhSdm1cJfubwmlTQhtuGeICHfiGvU=; b=HRDiTkYyxO5B5PE1FZ0txs7ggT9VEWsDR5XfqxMxncJ7f9M2VbH563NZ6q610VzeeJ EZte9pdjKCPF0YYRKtomf3u5AnHWAqvuAovpg+JyVrIOoXEEClfnwVXGNjnZvl/2RjRj HG+zKHbRk8cMwi9PZO8pB9hLhf2G8jP9HHRgI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8l9OwR/a+0SnhmEhSdm1cJfubwmlTQhtuGeICHfiGvU=; b=CezYEg1svAgIGP58RzknBXYFRge3cAhtSVQHh0gf9SjZthn9NlUr1alUxiewLRmaZw da94fwuUJwszikkfgSrkJJpjviXmvGrewlLt9R+LurQ2wUMPFrdoWS/3k2YCIJnBp/Tc i3CbM+VDKchANAyyc8aQana8ntmY4d29Z6JoPItHOpck/OHjGyubQ2rM2hZhlZhoMbTG awm2qDzkjVBSonQfVhoQKZ0e1k9RUafP/WVsQFwewKZzb8P1uVun5z+udTsPAmn2chmh N5XMDxWajGn37zbwD2zYMgduV1PtZBSfFxt8WiW3wdIFmGzf3XCP1/Z866jicS6FC92l pRUw== X-Gm-Message-State: AEkoousqHb4P4R5P5tyXfIX2PnieVr+c/Br5pvrKvbZMkXLAv/g+I+xRozRfgE5eEO8/qPjCK1IxQtYRlxd1LQ== X-Received: by 10.157.22.243 with SMTP id s48mr2672260ots.43.1472045970378; Wed, 24 Aug 2016 06:39:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.172.212 with HTTP; Wed, 24 Aug 2016 06:39:29 -0700 (PDT) In-Reply-To: <58fa64dd-bccb-e42c-0f5b-b2c847a2d7c6@gmail.com> References: <58fa64dd-bccb-e42c-0f5b-b2c847a2d7c6@gmail.com> From: Adrian Hope-Bailie Date: Wed, 24 Aug 2016 15:39:29 +0200 Message-ID: To: Yaron Sheffer Content-Type: multipart/alternative; boundary=001a113e26de286f55053ad169bc Archived-At: Cc: Interledger Community Group , Interledger Mailing List - IETF Subject: Re: [Ledger] AGENDA - Community Call - Wed 24 August - 3pm UTC X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 13:39:32 -0000 --001a113e26de286f55053ad169bc Content-Type: text/plain; charset=UTF-8 Thanks Yaron! I believe there is a Go implementation in the works from someone in the community On 24 August 2016 at 15:31, Yaron Sheffer wrote: > *Binary format status* > > - Plan to encapsulate most of it in ilp-core, so everyone else doesn't > have to worry about it. > - We had previously thought that we would reimplement ILP in every > language. Now adopted a more nuanced view - need implementations in > JavaScript (browsers, web), C (support most languages through bindings; > embedded systems), Java (to support JVM), C# (to support .NET), Python > (large amount of interest). But not much more for now. > - Javascript and Java have started on GitHub looking for others > > > Hi Adrian, > > C is notoriously unsuitable for security-sensitive code. As an outside > observer, I would suggest that you look at alternatives. My favorite would > be Go with a thin C shim on top. A more realistic alternative would be C++ > with a C interface. > > Thanks, > Yaron > --001a113e26de286f55053ad169bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Yaron!

I believe there is a Go im= plementation in the works from someone in the community

On 24 August 2016 at 15:31,= Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
=20 =20 =20
Binary format status
- Plan to encapsulate most of it in ilp-core, so everyone else doesn't have to worry about it.
- We had previously thought that we would reimplement ILP in every language. Now adopted a more nuanced view - need implementations in JavaScript (browsers, web), C (support most languages through bindings; embedded systems), Java (to support JVM), C# (to support .NET), Python (large amount of interest). But not much more for now.
- Javascript and Java have started on GitHub looking for others


 Hi Adrian,

C is notoriously unsuitable for security-sensitive code. As an outside observer, I would suggest that you look at alternatives. My favorite would be Go with a thin C shim on top. A more realistic alternative would be C++ with a C interface.

Thanks,
=C2=A0=C2=A0=C2=A0 Yaron

--001a113e26de286f55053ad169bc-- From nobody Fri Aug 26 03:23:22 2016 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 ABFC212D5CC for ; Fri, 26 Aug 2016 03:23:20 -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 Z_zywlAwaUlm for ; Fri, 26 Aug 2016 03:23:18 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 8A61D12D1A3 for ; Fri, 26 Aug 2016 03:23:18 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id l203so104374102oib.1 for ; Fri, 26 Aug 2016 03:23:18 -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=VwT3wnPhUz7DysGUxS2bHmH7zLwD8Se7Bb63GqNCB6M=; b=Mf7xZMEa1JrAi7F2bViLslGsiI7o/wr3Vn7pp5MG/NFXzbvgUfY683RePcogL6TiAa WaX6YZNGF0KHfdj908+7EJ+2f0oY3KNQOTmnKxaTUciD8W4xOBnHCFIOglYd4UZE0Adv Ff3C8f2KXP6sZev/nMck0i903FpsURHmTVeD8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VwT3wnPhUz7DysGUxS2bHmH7zLwD8Se7Bb63GqNCB6M=; b=FKeFBOiiSt/ldYnuMbgzcYqrRLcTgFpLa4nojHbn+IrHqNwGRwWFEKvOnV1NTeRgW8 yZUDIKfXkN/cQ+GUIbCK4ibimG7AjfxArXhJ7OpKiRxa2c8NFZMbL2jRoMVsH0ETuMpV Qy0Bn7KEs6j76b0peuz//JgjC24W7VCn2j0LOjnHXV9SCP2k4YLZyOUjOgKfWVzr/s15 n/8V598c/bAEBY2VO+TjE0YGLJ6C3pwG/tmYyxm1RmzxhoLZSAnYvRHKqFxrCSfu1OAZ 2JyRCDpZcNht8xg8U3WriIBXFjK1wWB1AC1xvywlH6b6p6iCt0QMaMWOmZhGBWlprETU N5iw== X-Gm-Message-State: AE9vXwNI1M8Thf70K82ADUfzeRfe6ae7hC+6oopd9tOuzmncBAsPSxqw4ivvkLHcBbAr9aN7ns+ls+T40vohfQ== X-Received: by 10.157.42.75 with SMTP id t69mr1794018ota.6.1472206997547; Fri, 26 Aug 2016 03:23:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.172.212 with HTTP; Fri, 26 Aug 2016 03:23:16 -0700 (PDT) In-Reply-To: References: <58fa64dd-bccb-e42c-0f5b-b2c847a2d7c6@gmail.com> From: Adrian Hope-Bailie Date: Fri, 26 Aug 2016 12:23:16 +0200 Message-ID: To: Manuel Polo Content-Type: multipart/alternative; boundary=001a113cf90e200f48053af6e746 Archived-At: Cc: Interledger Community Group , Interledger Mailing List - IETF Subject: Re: [Ledger] AGENDA - Community Call - Wed 24 August - 3pm UTC X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 26 Aug 2016 10:23:21 -0000 --001a113cf90e200f48053af6e746 Content-Type: text/plain; charset=UTF-8 I have logged an issue for this: https://github.com/interledger/interledger.github.io/issues/28 If anyone wants to have a stab at a PR feel free otherwise I'll try and put something together this weekend. On 26 August 2016 at 10:44, Manuel Polo wrote: > Hi! > > Would be great to have an implementation(connectors,ledger plug-ins etc) > and or initiatives table somewhere (interledger.org or at least github.com) > to be aware of: language - repos - maintainer/s. > > What do you think? > > 2016-08-24 15:39 GMT+02:00 Adrian Hope-Bailie : > >> Thanks Yaron! >> >> I believe there is a Go implementation in the works from someone in the >> community >> >> On 24 August 2016 at 15:31, Yaron Sheffer wrote: >> >>> *Binary format status* >>> >>> - Plan to encapsulate most of it in ilp-core, so everyone else doesn't >>> have to worry about it. >>> - We had previously thought that we would reimplement ILP in every >>> language. Now adopted a more nuanced view - need implementations in >>> JavaScript (browsers, web), C (support most languages through bindings; >>> embedded systems), Java (to support JVM), C# (to support .NET), Python >>> (large amount of interest). But not much more for now. >>> - Javascript and Java have started on GitHub looking for others >>> >>> >>> Hi Adrian, >>> >>> C is notoriously unsuitable for security-sensitive code. As an outside >>> observer, I would suggest that you look at alternatives. My favorite would >>> be Go with a thin C shim on top. A more realistic alternative would be C++ >>> with a C interface. >>> >>> Thanks, >>> Yaron >>> >> >> > > > -- > Manuel Polo > > http://about.me/mrmx > > > --001a113cf90e200f48053af6e746 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If anyone wants= to have a stab at a PR feel free otherwise I'll try and put something = together this weekend.

On 26 August 2016 at 10:44, Manuel Polo = <mistermx@gmail.= com> wrote:
Hi!

Would be great to have an implementation(conne= ctors,ledger plug-ins etc) and or initiatives table somewhere (interledger.org or at lea= st github.com) to be aw= are of: language - repos - maintainer/s.

What do you think?

2016-08-24 15:39 GMT+02:00 Adrian Hope-Bailie <adrian@hop= ebailie.com>:
Thanks Yaron!

I believe there is a Go implementation = in the works from someone in the community

On 24 August 2016 at 15:31, Ya= ron Sheffer <yaronf.ietf@gmail.com> wrote:
=20 =20 =20
Binary format status
- Plan to encapsulate most of it in ilp-core, so everyone else doesn't have to worry about it.
- We had previously thought that we would reimplement ILP in every language. Now adopted a more nuanced view - need implementations in JavaScript (browsers, web), C (support most languages through bindings; embedded systems), Java (to support JVM), C# (to support .NET), Python (large amount of interest). But not much more for now.
- Javascript and Java have started on GitHub looking for others


 Hi Adrian,

C is notoriously unsuitable for security-sensitive code. As an outside observer, I would suggest that you look at alternatives. My favorite would be Go with a thin C shim on top. A more realistic alternative would be C++ with a C interface.

Thanks,
=C2=A0=C2=A0=C2=A0 Yaron




--

--001a113cf90e200f48053af6e746-- From mistermx@gmail.com Fri Aug 26 01:45:10 2016 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 7E1DC12B035 for ; Fri, 26 Aug 2016 01:45:10 -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, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=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 HEmFwp7H-gCc for ; Fri, 26 Aug 2016 01:45:08 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 0516312D50E for ; Fri, 26 Aug 2016 01:45:07 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id l89so51909139lfi.1 for ; Fri, 26 Aug 2016 01:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1pnXzLAw6LydeisGxqJtPNWlKfKKLz7/2egPRwUyS+E=; b=Kn1fkzWkxPH3IKbBcxJc99V5wSw902+P/XZ8lAJaR1op+W98/wTP9qijsAw/ewp31B 6Kg1t2n3qdNlbfuzpWdvxaxRszTEgkWUYhq35owdbKjxQQOHqm5MQdXXbk72ELWSOYPy 5ayyT2SaIF0SVrsTSqEnewFG7WcXMWBgEmi6vWuBr1i2IXiNm78KsF+vZAg3ZBTFmuJW 7dKRlfW/qfnafJfyW4NSZFmxp++LaEr7IWrgMeb2c/do18MrjMJBZTKl8LyW46xxDNLw BtbPvW5ifFbZYMnd4fwqLyDklFM5JeUkP9NTO7Yahr24Dv2aG9sBrK1sWCh+m0fACeAF ZmsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1pnXzLAw6LydeisGxqJtPNWlKfKKLz7/2egPRwUyS+E=; b=L5HUzT6W1Vlod48NOo5TriTMWjWlZpx0duhvmCPI+VfEHTHhyNrzgzIfPq/drVYb9o znDRJysgcMFGQx0Zgu2/xHsjpT8fsWD7+fjnFyqe+K6GGwUWRtXtAG9YeLj84oNX0U35 3kPl0S7D5MArUeWnbgZVCZbsBqfzSoovvj6GlpR9PssuLGz6X1o6+JvkRqgRqKdyJLq7 Z5u/IxuK/eE0J1wYcONlZ+rdgYmSv/hQ3z/5i+Z9jZMUMb4h6cFSvVbreqoFV1Kj1RHe Bm2e45/OPlI3HZpSZDdvAOkCw5SNZSRLDSFEaw02MnT2KaT09PP+Vc1HSJExMt3VuRPN nPpw== X-Gm-Message-State: AE9vXwPnPpe6fyi1e5r4cB89SDKfHkvBhKW39R4PUDpisSilR3vJJcJeKm6IZhHFoXlKRWyNgwyPIABIvgDwgA== X-Received: by 10.25.21.32 with SMTP id l32mr631207lfi.158.1472201105912; Fri, 26 Aug 2016 01:45:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.19.106 with HTTP; Fri, 26 Aug 2016 01:44:35 -0700 (PDT) In-Reply-To: References: <58fa64dd-bccb-e42c-0f5b-b2c847a2d7c6@gmail.com> From: Manuel Polo Date: Fri, 26 Aug 2016 10:44:35 +0200 Message-ID: To: Adrian Hope-Bailie Content-Type: multipart/alternative; boundary=001a1140826ef4ba27053af58780 Archived-At: X-Mailman-Approved-At: Fri, 26 Aug 2016 08:52:19 -0700 Cc: Interledger Community Group , Interledger Mailing List - IETF Subject: Re: [Ledger] AGENDA - Community Call - Wed 24 August - 3pm UTC X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 26 Aug 2016 09:22:43 -0000 --001a1140826ef4ba27053af58780 Content-Type: text/plain; charset=UTF-8 Hi! Would be great to have an implementation(connectors,ledger plug-ins etc) and or initiatives table somewhere (interledger.org or at least github.com) to be aware of: language - repos - maintainer/s. What do you think? 2016-08-24 15:39 GMT+02:00 Adrian Hope-Bailie : > Thanks Yaron! > > I believe there is a Go implementation in the works from someone in the > community > > On 24 August 2016 at 15:31, Yaron Sheffer wrote: > >> *Binary format status* >> >> - Plan to encapsulate most of it in ilp-core, so everyone else doesn't >> have to worry about it. >> - We had previously thought that we would reimplement ILP in every >> language. Now adopted a more nuanced view - need implementations in >> JavaScript (browsers, web), C (support most languages through bindings; >> embedded systems), Java (to support JVM), C# (to support .NET), Python >> (large amount of interest). But not much more for now. >> - Javascript and Java have started on GitHub looking for others >> >> >> Hi Adrian, >> >> C is notoriously unsuitable for security-sensitive code. As an outside >> observer, I would suggest that you look at alternatives. My favorite would >> be Go with a thin C shim on top. A more realistic alternative would be C++ >> with a C interface. >> >> Thanks, >> Yaron >> > > -- Manuel Polo http://about.me/mrmx --001a1140826ef4ba27053af58780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

Would be great to have an imple= mentation(connectors,ledger plug-ins etc) and or initiatives table somewher= e (interledger.org or at least github.com) to be aware of: language - repos -= maintainer/s.

What do you think?

2016-08-24 15:39 GMT+02:00 Adrian Ho= pe-Bailie <adrian@hopebailie.com>:
Thanks Yaron!

I believe th= ere is a Go implementation in the works from someone in the community

=
On 24 August 2016 at 15:31, Yaron Sheffer <= yaronf.ietf@gmail.com> wrote:
=20 =20 =20
Binary format status
- Plan to encapsulate most of it in ilp-core, so everyone else doesn't have to worry about it.
- We had previously thought that we would reimplement ILP in every language. Now adopted a more nuanced view - need implementations in JavaScript (browsers, web), C (support most languages through bindings; embedded systems), Java (to support JVM), C# (to support .NET), Python (large amount of interest). But not much more for now.
- Javascript and Java have started on GitHub looking for others


 Hi Adrian,

C is notoriously unsuitable for security-sensitive code. As an outside observer, I would suggest that you look at alternatives. My favorite would be Go with a thin C shim on top. A more realistic alternative would be C++ with a C interface.

Thanks,
=C2=A0=C2=A0=C2=A0 Yaron




--
Manuel Polo

= http://about.me/mrmx=


--001a1140826ef4ba27053af58780-- From nobody Fri Aug 26 08:52:23 2016 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 B592A12D516 for ; Fri, 26 Aug 2016 03:43:22 -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 OQfcP4EpSoZ9 for ; Fri, 26 Aug 2016 03:43:20 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 067CD12D60A for ; Fri, 26 Aug 2016 03:42:40 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id f93so53849020lfi.2 for ; Fri, 26 Aug 2016 03:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pLN8ZYJyNgP1KgsJ7FCm+y/H+LnwWOljukqqhDGyhV4=; b=zZ2bSIYUDkzfXtBkJlsPonaBHn8ffvIXuZsmHPMfGCQdot4gLXKPgjNB7UUtYLg6FB 5pkk/hZtYFa41Agb2W8BS1GdqF+8WH4PgX+K1jWjBrXCVb9xmH15x6miypNwKcpdEWG4 TjrTn8ZaSSByXWin8AbM/ZMS6Hy4kAlXAYRdYYyJQM829xGoEAiQFkiTJgSCPgbw4MD9 xlYbSS+0n1U67DVtl6ijSfEEeM4izkL3uetK5gBKc13FU6bgO3t9P1Y4GQI8inQqKihQ /LfwCW9z++bVhKBW0ojwaSL+mBqa5jI04/S939hkiH8rsqihDdkUb+5nZWOzU+45Mrfo JSug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pLN8ZYJyNgP1KgsJ7FCm+y/H+LnwWOljukqqhDGyhV4=; b=f73ggmu1KUWAtGR5UXuaBgP/HYfiRe7iPBOUrV2guX4s5zdX276TLN+rCT7PiKO7ld +VQAobUjZI4ogTjdeVFBG2aq+N3Koc3j4St9r78sXpDLiiiA2objLU8BPu777wnt4xcj kvQ6DuEcFlGRn8GNvtgU3vp4rYLGXpvMl6Z6lrex5F6kqwapRzNfFwMFlSFg1ufQ+HJT gLYXLwOFw4JQ8grPKTAi0Oqzf8g2xC/CH49TmPul0dw1ewFZMl4uHCZhSjRtgqZKATjz Zi2huISUlvFgZihYFJX/9OMml7dz12nPnLZ6FzESqRu+mHyxdc0YRF3jBJVH37ntXhGv 81Nw== X-Gm-Message-State: AE9vXwM0b3xs3lgyecwb+osU7iS1gveHL/XSuASHCvn4tWAkzUcdgS+L+n4u5VnojM1h8nvnAsyCFCgI6niIJg== X-Received: by 10.46.71.84 with SMTP id u81mr743879lja.19.1472208158147; Fri, 26 Aug 2016 03:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.19.106 with HTTP; Fri, 26 Aug 2016 03:42:07 -0700 (PDT) In-Reply-To: References: <58fa64dd-bccb-e42c-0f5b-b2c847a2d7c6@gmail.com> From: Manuel Polo Date: Fri, 26 Aug 2016 12:42:07 +0200 Message-ID: To: Adrian Hope-Bailie Content-Type: multipart/alternative; boundary=001a114116d24d49ab053af72cc1 Archived-At: X-Mailman-Approved-At: Fri, 26 Aug 2016 08:52:19 -0700 Cc: Interledger Community Group , Interledger Mailing List - IETF Subject: Re: [Ledger] AGENDA - Community Call - Wed 24 August - 3pm UTC X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 26 Aug 2016 10:43:24 -0000 --001a114116d24d49ab053af72cc1 Content-Type: text/plain; charset=UTF-8 Great Adrian! We'll submit a PR next week! 2016-08-26 12:23 GMT+02:00 Adrian Hope-Bailie : > I have logged an issue for this: https://github.com/ > interledger/interledger.github.io/issues/28 > > If anyone wants to have a stab at a PR feel free otherwise I'll try and > put something together this weekend. > > On 26 August 2016 at 10:44, Manuel Polo wrote: > >> Hi! >> >> Would be great to have an implementation(connectors,ledger plug-ins etc) >> and or initiatives table somewhere (interledger.org or at least >> github.com) to be aware of: language - repos - maintainer/s. >> >> What do you think? >> >> 2016-08-24 15:39 GMT+02:00 Adrian Hope-Bailie : >> >>> Thanks Yaron! >>> >>> I believe there is a Go implementation in the works from someone in the >>> community >>> >>> On 24 August 2016 at 15:31, Yaron Sheffer wrote: >>> >>>> *Binary format status* >>>> >>>> - Plan to encapsulate most of it in ilp-core, so everyone else doesn't >>>> have to worry about it. >>>> - We had previously thought that we would reimplement ILP in every >>>> language. Now adopted a more nuanced view - need implementations in >>>> JavaScript (browsers, web), C (support most languages through bindings; >>>> embedded systems), Java (to support JVM), C# (to support .NET), Python >>>> (large amount of interest). But not much more for now. >>>> - Javascript and Java have started on GitHub looking for others >>>> >>>> >>>> Hi Adrian, >>>> >>>> C is notoriously unsuitable for security-sensitive code. As an outside >>>> observer, I would suggest that you look at alternatives. My favorite would >>>> be Go with a thin C shim on top. A more realistic alternative would be C++ >>>> with a C interface. >>>> >>>> Thanks, >>>> Yaron >>>> >>> >>> >> >> >> -- >> Manuel Polo >> >> http://about.me/mrmx >> >> >> > -- Manuel Polo http://about.me/mrmx --001a114116d24d49ab053af72cc1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great Adrian! We'll submit a PR next week!

2016-08-26 12:23 GM= T+02:00 Adrian Hope-Bailie <adrian@hopebailie.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
If anyone wants to have a stab a= t a PR feel free otherwise I'll try and put something together this wee= kend.

On 26 August 2016 at 10:44, Manuel Po= lo <mistermx@gmail.com> wrote:
Hi!

Would be great to have an= implementation(connectors,ledger plug-ins etc) and or initiatives tab= le somewhere (interled= ger.org or at least git= hub.com) to be aware of: language - repos - maintainer/s.

= What do you think?

2016-08-24 15:39 GMT+02:00 Adrian Hope-Bailie <ad= rian@hopebailie.com>:
Thanks Yaron!

I believe there is a Go impleme= ntation in the works from someone in the community

On 24 August 2016 at 1= 5:31, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
=20 =20 =20
Binary format status
- Plan to encapsulate most of it in ilp-core, so everyone else doesn't have to worry about it.
- We had previously thought that we would reimplement ILP in every language. Now adopted a more nuanced view - need implementations in JavaScript (browsers, web), C (support most languages through bindings; embedded systems), Java (to support JVM), C# (to support .NET), Python (large amount of interest). But not much more for now.
- Javascript and Java have started on GitHub looking for others


 Hi Adrian,

C is notoriously unsuitable for security-sensitive code. As an outside observer, I would suggest that you look at alternatives. My favorite would be Go with a thin C shim on top. A more realistic alternative would be C++ with a C interface.

Thanks,
=C2=A0=C2=A0=C2=A0 Yaron




= --




--
Manuel Polo

= http://about.me/mrmx=


--001a114116d24d49ab053af72cc1-- From nobody Mon Aug 29 05:33:19 2016 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 9B72112D0F1 for ; Mon, 29 Aug 2016 05:33:17 -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 QCaeWqTdOacr for ; Mon, 29 Aug 2016 05:33:16 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 0353C12D17E for ; Mon, 29 Aug 2016 05:33:15 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id l203so193477723oib.1 for ; Mon, 29 Aug 2016 05:33:15 -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=aBRqIA3gq0vvaFSoSjZy3QZPxCflzHvEIK4i+dy6IQk=; b=keg5z9bRMkqRzWIDsn6ss0QS4fMGt+xiak4a4b5GsHxynZ4nsGsISmamdgz9bu1DQm u3l80r8oLw2RXm4wnESeE1VHx62BhfcDRMcZagdVYDEGYM0zm3kfRNcs6kKPest2A2mT tkoPZwiOiU7XohB6okQOqvuUAmPINzi3vP65Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aBRqIA3gq0vvaFSoSjZy3QZPxCflzHvEIK4i+dy6IQk=; b=C8tX5kdo0pMdDzxvaTI/Q9kEjsyB6vFsPAfEWILnePL/BLHk2/dLvpnu6IPWQ8UMXT h0UYRqlG68Rc1zXW/SBblIy0K+ZUabmUtlVlahnxASvm2lrk71RjINhPDoWi0hqgZHMV 4WPCbqiiAWy339zU3vSZcADn+hY32kSfdPJa0jUU8QCDU3r1XKZYbyBoqWTCS8XaINC1 Q59I19po1ZWr1KODnrG0ExadkH0bcLkIfgmsFunb/WekStLixvzuEWoYRLBd1g4DlzRc 3sr3FsIevDrrA6p+Acd4vDG4BuYOfa6mMqOpq7YrrxJnkMcA9VIFZ7Zx/TbyKVRMVyKQ 0myQ== X-Gm-Message-State: AE9vXwP8DUboAeUukJqz3XOlnQIV3oWxCEDRn1TJdCf5jIL/vVl76eXsuWHNblCMqv2sZLpjQgZeWCC+RRy6hA== X-Received: by 10.157.38.167 with SMTP id l36mr12444170otb.59.1472473995201; Mon, 29 Aug 2016 05:33:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.172.212 with HTTP; Mon, 29 Aug 2016 05:33:14 -0700 (PDT) From: Adrian Hope-Bailie Date: Mon, 29 Aug 2016 14:33:14 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary=001a113ddba66ce9b8053b351191 Archived-At: Subject: [Ledger] Register for W3C TPAC Lisbon before Friday 2 September X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 29 Aug 2016 12:33:18 -0000 --001a113ddba66ce9b8053b351191 Content-Type: text/plain; charset=UTF-8 Reminder to register for TPAC before registration closes at the end of the week. The Interledger community is meeting on Thursday but community group members are also able to attend the W3C Technical Plenary on Wednesday or other group meetings as observers if you are interested in doing so. TPAC: https://www.w3.org/2016/09/TPAC/ Plenary FAQ: https://www.w3.org/wiki/TPAC2016/FAQ Registration form: https://www.w3.org/2002/09/wbs/35125/TPAC2016/ --001a113ddba66ce9b8053b351191 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reminder to register for TPAC before registratio= n closes at the end of the week.

The Interledger community is = meeting on Thursday but community group members are also able to attend the= W3C Technical Plenary on Wednesday or other group meetings as observers if= you are interested in doing so.

TPAC:
https://www.w3.org/2016/09/TPAC/
--001a113ddba66ce9b8053b351191-- From nobody Mon Aug 29 15:16:49 2016 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 E626012D8A3 for ; Mon, 29 Aug 2016 15:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRWBCcw0Dc3h for ; Mon, 29 Aug 2016 15:16:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 011DB12B047 for ; Mon, 29 Aug 2016 15:16:45 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7TLudDm038610 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 29 Aug 2016 16:56:40 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local References: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> To: ledger@ietf.org From: Adam Roach X-Forwarded-Message-Id: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> Message-ID: <1780d62a-3f42-73f3-c19f-14f083a8da77@nostrum.com> Date: Mon, 29 Aug 2016 16:56:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ledger] NomCom 2016-2017: Call for Nominations X-BeenThere: ledger@ietf.org X-Mailman-Version: 2.1.17 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, 29 Aug 2016 22:16:48 -0000 The 2016-17 Nominating Committee (Nomcom) is seeking nominations from now until October 8, 2016. The open positions being considered by this year's Nomcom can be found at the end of this email and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2016/ Nominations may be made by selecting the Nominate link at the top of the Nomcom 2016 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2016/nominate/ {Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ } If you are unable to use the web form, nominations may instead be made by email to nomcom-16@ietf.org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Self-nomination is welcome! Willing nominees will be asked to fill out a questionnaire specific to the position for which they are nominated. The questionnaires will be available on September 2, 2016 and have a submission deadline of October 13, 2016. NomCom 2016-17 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the Nomcom to tell the nominee that you were the one who made the nomination. This defaults to “no” - so if you don't mark the field we won’t tell. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before October 8, 2016. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for management permission, as it is easier to decline the nomination than put one in late. The Nomcom appoints individuals to fill the open slots on the IAOC, the IAB, and the IESG. The list of people and posts whose terms end with the March 2017 IETF meeting, and thus the positions for which this Nomcom is responsible, follows: IAOC Lou Berger IAB Ralph Droms* Russ Housley* Robert Sparks Andrew Sullivan Dave Thaler* Suzanne Woolf IESG Jari Arkko (GEN)* Deborah Brungard (RTG) Ben Campbell (ART) Spencer Dawkins (TSV) Stephen Farrell (SEC)* Joel Jaeggli (OPS)* Terry Manderson (INT) Alvaro Retana (RTG) *- have indicated that they do not intend to accept a renomination. This information is always up to date on https://datatracker.ietf.org/nomcom/2016/ Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB, IESG, and IAOC, under individual tabs at: https://datatracker.ietf.org/nomcom/2016/requirements/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-16@ietf.org. Thank you for your help in identifying qualified nominees! Lucy Lynch Nomcom Chair 2016-17 nomcom-chair-2016@ietf.org llynch@civil-tongue.net