From nobody Fri Feb 3 02:23:09 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD236129BDB for ; Fri, 3 Feb 2017 02:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 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_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 V3GAuP4Gaow0 for ; Fri, 3 Feb 2017 02:22:54 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 AAD3F129A82 for ; Fri, 3 Feb 2017 02:22:54 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id w20so27287618qtb.1 for ; Fri, 03 Feb 2017 02:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=xLzS4y/PXPzyWKIHKFyMS1k6pi3G9lZc9sjSVkOOZKc=; b=DPVwFpooYKEkTlkIv1mLcZfPX6ZoCG9NcJ2HnJdHH2n1SiN4pIaa9JimxN3dQPOO3G 0MbXFvRGKK8Aq9eF3As+nQJ0JIY4AzP/7SJahPf40/hXRkf0KAkdgugfadFTRPy5hLMN ebraxL0PpVWlrgiMmCbT5SDJY0pEWXbEb/9i8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xLzS4y/PXPzyWKIHKFyMS1k6pi3G9lZc9sjSVkOOZKc=; b=YE2q3Tr+NwCtoqtgOjl6XOE1ce+L6w6vZT/JfEMy1aLUMSq7i4ghCUD2IcvaliJe5c DjIPh8/P60SWLXhson9oiLcOjQ9eRvT89gK9RdTd3aL030X9uZVm6+DePyyPlYQvqdte 2k49u1UgmhxwsjyofP1dEE1m4ZFJvH1ydlUidG6Z/sBktZOxyJlsIGHF0ECiwKU11iib HoEFYMWYLQx0T9XO3obwnySL8JWDPyniAM8DPUMeApOyftNLePRCUBBy1G86Rqztx91A 6GNisO5Bix7OOoPWXyMaUb1DhS0qyVVeQQ/1FAnLc5gRdvb7aa2JBOKqDp7jmTtDdZix cq1w== X-Gm-Message-State: AMke39mLRvAmVySWrCCbzSGRJkKc8S8IqfQyv1fA1yVckO//wQgJknClhuvBZT4068aAVGeLNCF4waP83tUmkkCt X-Received: by 10.55.54.143 with SMTP id d137mr12686817qka.258.1486117372714; Fri, 03 Feb 2017 02:22:52 -0800 (PST) MIME-Version: 1.0 From: Evan Schwartz Date: Fri, 03 Feb 2017 10:22:42 +0000 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary=001a1146f4f418787305479daaf5 Archived-At: Subject: [Ledger] ILP Addresses, Conditions, and SPSP 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, 03 Feb 2017 10:22:57 -0000 --001a1146f4f418787305479daaf5 Content-Type: text/plain; charset=UTF-8 Just wanted to give you a heads up about a couple new discussions going on that you might be interested in: - Should ILP use Crypto Conditions or just SHA-256 hashlocks? - rfcs/issues/153 - How should you choose and interpret ILP Addresses and what character set should they use? - rfcs/pull/154 - What is the Simple Payment Setup Protocol for and how should it work? Is non-repudiability important? rfcs/issues/152 Ideas, questions, concerns are welcome! -- --- Evan Schwartz Software Engineer Managing Director of Ripple Luxembourg --001a1146f4f418787305479daaf5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just wanted to give you a heads up about a couple new disc= ussions going on that you might be interested in:
  • Should ILP us= e Crypto Conditions or just SHA-256 hashlocks? -=C2=A0rfcs/issues/153=C2=A0
  • How= should you choose and interpret ILP Addresses and what character set shoul= d they use?=C2=A0-=C2=A0rfcs/pull/154=C2=A0
  • What is the Simple Payment Setup Prot= ocol for and how should it work? Is non-repudiability important? rfcs/issues/152=C2=A0<= /li>
=C2=A0Ideas, questions, concerns are welcome!
--

---

Evan Schwartz
Software Engineer
Managi= ng Director of Ripple Luxembourg
=
--001a1146f4f418787305479daaf5-- From nobody Tue Feb 7 01:29:50 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B7D1295A6 for ; Tue, 7 Feb 2017 01:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTC8bdP2s4mn for ; Tue, 7 Feb 2017 01:29:47 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A11612949F for ; Tue, 7 Feb 2017 01:29:47 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id c85so152196194wmi.1 for ; Tue, 07 Feb 2017 01:29:47 -0800 (PST) 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=ovQENhlN49iUS97wYFb+nWzRffYaxu/T1z9IJH68XlU=; b=I0kxxYo9AD9Oim9tB9c5ew1ViJmmQ5LcxMTsrbgMcQWtDjqRNAoh9PDB6ji4fXBMeK 1UdQX7tsUug8DwlVUTS0e+qAtNAhNg9jTsFxb1iauuFARQRBmN/1OqIe8qrJGWEtbKTt NO1GbZe9vQ0vncej6Rn/gyS/lIcA5BFAXPbeE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ovQENhlN49iUS97wYFb+nWzRffYaxu/T1z9IJH68XlU=; b=RRgW8q3WS51x1ixbuVHcgnb3NmMJNS1wtmpBHP71AnSX6RcaGZTQ9rc50XoUB1wJoq 43ohg4tYvhBuGMTePwDtG00h9qMedOLLetbTpVsgMaXY+W/2K/Xfrv5H+HZecZhtcIHX AY2PhaZDkgMOuxHHgdfcFsOF+z83qksUJ2a3yZYjPqZQcN/O7KQuTZyqnQnjdx126BXy 7DM2J/syZQttnaPiCfMtmcMQZoRVb6bFIWJ801DncDIKt3MdZh30YRSNLCoHDAYzCHjE djVlcZgxrzclFooUt0eHG648C5OPq+ZflGbwWc67r0PUZyP20WTkjBHMt+L9Aluxisre XFYQ== X-Gm-Message-State: AIkVDXJiGtSOCPYxHi4qBqUvWRTQMbPLqy36A9QynGZ5TSDyjw+X7qqSO2ImgB8qHqCgAUq69P75cUSuI+lJhg== X-Received: by 10.223.141.229 with SMTP id o92mr14931984wrb.22.1486459785626; Tue, 07 Feb 2017 01:29:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.195.17.131 with HTTP; Tue, 7 Feb 2017 01:29:44 -0800 (PST) From: Adrian Hope-Bailie Date: Tue, 7 Feb 2017 11:29:44 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/mixed; boundary=f403045f530a809ec80547ed635b Archived-At: Subject: [Ledger] AGENDA - Community Call - 8 February - 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, 07 Feb 2017 09:29:49 -0000 --f403045f530a809ec80547ed635b Content-Type: multipart/alternative; boundary=f403045f530a809ec50547ed6359 --f403045f530a809ec50547ed6359 Content-Type: text/plain; charset=UTF-8 Hi all, *AGENDA* Let's spend the time on this weeks call picking up on the discussion of some of the bigger issues from the lists: 1. Crypto-conditions or just SHA-256 hashes See: https://github.com/interledger/rfcs/issues/153 2. A simpler Simple Payment Setup Protocol See: https://gist.github.com/sharafian/df7a4b7e2ff000248800b113f06f549a And: https://github.com/interledger/rfcs/issues/152 We are also thinking of having another workshop/hackathon in a few months so would be great to hear any thoughts or ideas. *Dial In Details* 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 *Reminder that all calls are recorded.* I am catching up on a backlog of recordings. Apologies that they have fallen behind. We've just upgraded our SoundCloud subscription (again) to accommodate more uploads so I'll be putting the last few months calls up asap. --f403045f530a809ec50547ed6359 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

AGENDA
=

Let's spend the time on this weeks call picking up= on the discussion of some of the bigger issues from the lists:

1. Crypto-conditions or just SHA-256 hashes
=C2=A0=C2=A0=C2=A0 See: https://github.com= /interledger/rfcs/issues/153

2. A simpler Simple Paym= ent Setup Protocol
W= e are also thinking of having another workshop/hackathon in a few months so= would be great to hear any thoughts or ideas.

Dial In Details

To join the meeting, go to:
https://bluejeans.co= m/795795755
(Try your iPhone or Android phone)

Just want= to dial in? (ht= tp://bluejeans.com/numbers)
Enter Meeting ID: 795795755

Re= minder that all calls are recorded.

I am catching up = on a backlog of recordings. Apologies that they have fallen behind. We'= ve just upgraded our SoundCloud subscription (again) to accommodate more up= loads so I'll be putting the last few months calls up asap.
<= /div>
--f403045f530a809ec50547ed6359-- --f403045f530a809ec80547ed635b Content-Type: text/calendar; charset=US-ASCII; name="interledger-community-calls.ics" Content-Disposition: attachment; filename="interledger-community-calls.ics" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iyvboy6g0 QkVHSU46VkNBTEVOREFSDQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6 UFVCTElTSA0KQkVHSU46VkVWRU5UClVJRDpiaXdlZWtseWNhbGxAaW50ZXJsZWRnZXIub3JnDQpE VFNUQVJUOjIwMTcwMTExVDE1MDAwMFoNCkRURU5EOjIwMTcwMTExVDE2MDAwMFoNClJSVUxFOkZS RVE9V0VFS0xZO0lOVEVSVkFMPTI7QllEQVk9V0UNCkRUU1RBTVA6MjAxNjExMjhUMTYwMjQ4Wg0K Q1JFQVRFRDoyMDE2MTEyOFQxMDI5MTZaDQpERVNDUklQVElPTjpUaGlzIGlzIHRoZSBiaS13ZWVr bHkgY2FsbCBvZiB0aGUgSW50ZXJsZWRnZXIgY29tbXVuaXR5LlxuXG5UaGUNCiAgYWdlbmRhIGlz IGRpc3RyaWJ1dGVkIHZpYSB0aGUgbWFpbGluZyBsaXN0cyBwcmlvciB0byBlYWNoIG1lZXRpbmcu XG5cbkZvciANCiBtb3JlIGluZm8gYW5kIHRvIGpvaW4gdGhlIG1haWxpbmcgbGlzdHMgdmlzaXQ6 IGh0dHBzOi8vaW50ZXJsZWRnZXIub3JnL2NvbW0NCiB1bml0eVxuXG5UbyBqb2luIG9yIHN0YXJ0 IHRoZSBtZWV0aW5nXCwgZ28gdG86XG5odHRwczovL2JsdWVqZWFucy5jb20vNzk1NzkNCiA1NzU1 XG4oQWxzbyB3b3JrcyBvbiBpUGhvbmUgb3IgQW5kcm9pZCBwaG9uZSlcblxuVG8gY29ubmVjdCBk aXJlY3RseSBmcm8NCiBtIGEgcm9vbSBzeXN0ZW0/XG4xKSBEaWFsOiAxOTkuNDguMTUyLjE1MiBv ciBiam4udmNcbjIpIEVudGVyIE1lZXRpbmcgSUQ6IDcNCiA5NTc5NTc1NSAtb3ItIHVzZSB0aGUg cGFpcmluZyBjb2RlXG5cbkRpYWwtaW4gbnVtYmVyczogaHR0cDovL2JsdWVqZWFucy5jb20NCiAv bnVtYmVycyAodXNlIE1lZXRpbmcgSUQ6IDc5NTc5NTc1NSkKTE9DQVRJT046aHR0cHM6Ly9ibHVl amVhbnMuY29tLzc5NTc5NTc1NQ0KVVJMOmh0dHBzOi8vYmx1ZWplYW5zLmNvbS83OTU3OTU3NTUN ClNFUVVFTkNFOjANClNUQVRVUzpDT05GSVJNRUQNClNVTU1BUlk6SW50ZXJsZWRnZXIgQ29tbXVu aXR5IENhbGwNClRSQU5TUDpPUEFRVUUNCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVIK --f403045f530a809ec80547ed635b-- From nobody Thu Feb 9 10:29:52 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E032C129C4A for ; Thu, 9 Feb 2017 10:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSrXPapnQAVg for ; Thu, 9 Feb 2017 10:29:49 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A57129439 for ; Thu, 9 Feb 2017 10:29:49 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id r136so9041276vke.1 for ; Thu, 09 Feb 2017 10:29:49 -0800 (PST) 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=s9ta9wSEJ8WqdrfAY/32fY7LLDAk7WmHe9c+gPWY2yw=; b=GNYQGHyPsmYyZhI51P/MXTYxqDtEy6eoMVfjuCgjinMVeAAxSJeQaRinq6swKksFdU JTqFeYYRG8FI+UcjvnDDEcaQorpHUjRGq2oFt9TYbsXAYkAeCilpYyNZt4KgoU8xPO6d z9cCyAD8eJDoQw7rweE/3TPWbtSj9yfAyiJtk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=s9ta9wSEJ8WqdrfAY/32fY7LLDAk7WmHe9c+gPWY2yw=; b=OJWd5FogJIzJ5cHCTBaLaNtENyzUIqmuWMc51RyxHQnUueGwLqplyvm6CCRnP+tFV5 +4fb8nw0kL8KmqyJ9Dw20KNBch186a2lnGJrbaWq+nSHaJxdO7KZUlpdq2gkpM835RNs XfBtaEP5SITLga6m+wANgxC1WrnNQMO/GIAQPHJQ2V4F4wqjbCnKKMQsnlFVKIF9qh2z D902pdG9PdjCqon9z6DK8DN++KeZr+ZD8cJD2cSNPl5dlxfMehzVY7D5vDVA4DbJ0DSH xxYNVk4+8npSukdHyeN9tfmVkvUB0sFwBQvzFfCY6W0EgOkPj0hcq4SzFF/GU26RNPgp 4m5Q== X-Gm-Message-State: AMke39klUuEozELPKF31e1VhIjuOASZ1uxoU14Lc/C6oTfX/yeUIX36c6xiePYZoX/p1wAZ8s0Fim/FN/6WN7w== X-Received: by 10.31.200.199 with SMTP id y190mr2206609vkf.115.1486664987986; Thu, 09 Feb 2017 10:29:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.119.79 with HTTP; Thu, 9 Feb 2017 10:29:47 -0800 (PST) From: Adrian Hope-Bailie Date: Thu, 9 Feb 2017 20:29:47 +0200 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary=001a114d9d488267a505481d2a1a Archived-At: Subject: [Ledger] Call for Mentors and Project Ideas - Google Summer of Code 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, 09 Feb 2017 18:29:51 -0000 --001a114d9d488267a505481d2a1a Content-Type: text/plain; charset=UTF-8 Hi all, I have submitted an application on behalf of the community to Google Summer of Code for 2017. If successful, Interledger will be one of the projects that students can apply to work on during their summer break. Students propose a project and, if accepted, are given a mentor from the existing contributors. Details on the requirements of a mentor are here: http://write.flossmanuals.net/gsoc-mentoring/what-makes-a-good-mentor/ *Are there any members of the community willing to be mentors if the project is accepted?* The ask is that you assist the student in getting familiar with the project and help them complete their 12 week project (which is a contribution toward the Interledger code-base.) The goal is to help the student with contributions to Interledger a useful side-effect. *Are there any members of the community with good ideas for a 12 week student project?* The heart of the process is an "Ideas Page" where we can list ideas for new projects. Ours is here: https://interledger.org/ideas.html Right now it is very general (and quite focused on ILP-Kit) so anyone that has a concrete proposals for a 12 week programming project and is volunteering to be a mentor, please submit a PR to add your proposal or send it as a reply to this email. (Guidelines for project definitions: http://write.flossmanuals.net/gsoc-mentoring/defining-a-project/) Adrian --001a114d9d488267a505481d2a1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I have = submitted an application on behalf of the community to Google Summer of Cod= e for 2017. If successful, Interledger will be one of the projects that stu= dents can apply to work on during their summer break. Students propose a pr= oject and, if accepted, are given a mentor from the existing contributors.<= br>
Details on the requirements of a mentor are here: http://write.flossmanuals.net/gsoc-mentoring/what-makes-a-good-mentor/=

Are there any members of the community willing to = be mentors if the project is accepted?

The ask is that you= assist the student in getting familiar with the project and help them comp= lete their 12 week project (which is a contribution toward the Interledger = code-base.) The goal is to help the student with contributions to Interledg= er a useful side-effect.

Are there any members of the commu= nity with good ideas for a 12 week student project?

The hea= rt of the process is an "Ideas Page" where we can list ideas for = new projects. Ours is here: = https://interledger.org/ideas.html

Right now it is very general = (and quite focused on ILP-Kit) so anyone that has a concrete proposals for = a 12 week programming project and is volunteering to be a mentor, please su= bmit a PR to add your proposal or send it as a reply to this email. (Guidel= ines for project definitions: http://write.flossmanuals.net/gsoc-mentorin= g/defining-a-project/)

Adrian
--001a114d9d488267a505481d2a1a-- From nobody Tue Feb 21 06:55:43 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E28F129BF6 for ; Tue, 21 Feb 2017 06:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWIPXCL2ux-0 for ; Tue, 21 Feb 2017 06:55:33 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5BB1294AF for ; Tue, 21 Feb 2017 06:55:33 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id x24so13997111uae.3 for ; Tue, 21 Feb 2017 06:55:33 -0800 (PST) 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=ot4jpMTjOyj/YZ/nfZJCcSX7jYesl+gEeBf2mara8YY=; b=IhfBKh2pJvv/je6ks7/PPb0xLvha9MyKEhzDm+ty2hHYwhQns8y1ml0+ycnzpvqFTj XpWnO9La3BqUP++Ic41ncV0Ro5ZYW5Fr2aC7W7wGpq4aY4DYFyEZlgocOwZ1q9rDHSNJ 29u9jDmTN52WVN6vBRr/v5yD0CVxiE9nT5fqk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ot4jpMTjOyj/YZ/nfZJCcSX7jYesl+gEeBf2mara8YY=; b=hOifYUE09eHI3QNL8VRoeTVCRNKzWwLxBWhZEwcqq9LQMYn36Q5g17B+WIfsM5QhW6 8z+BLzbVWM8suww+fWZRO7q8a2eQgisoyaJ8dOroJJfh6J+lVkq9D/9wLnMCIdeZ+bXA zgFK5JTElR1r4diK0VYT2RJyZB6yotdihmwIJutnc4Ii0zzyz/YC25jbv9w9C292DOt0 AnZPwqremQhcgDnBgZEJjZ9lB7rpqT/DaoGXJT879ZnyAHQ3KNCM7egn/mkCcRGJJC6r WeRzByJ6Z6eNXOIqZJCAiH3tjwI1tuGktcATI0Y5HJVZai6TVTgy+NP5ACDowga6bYzX QgHw== X-Gm-Message-State: AMke39kopxsUHJdTQmlHnfkOazpdaadf74B3oiETf3nLPYdByJlKewPoYNZPIOWYVK5IpR0lk3OsiS56Y1j76A== X-Received: by 10.159.32.78 with SMTP id 72mr11395824uam.59.1487688932641; Tue, 21 Feb 2017 06:55:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.42.130 with HTTP; Tue, 21 Feb 2017 06:55:31 -0800 (PST) From: Adrian Hope-Bailie Date: Tue, 21 Feb 2017 14:55:31 +0000 Message-ID: To: Interledger Community Group , Interledger Mailing List - IETF Content-Type: multipart/alternative; boundary=94eb2c03e7925deb9205490b9217 Archived-At: Subject: [Ledger] AGENDA - Community Call - 22 February - 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, 21 Feb 2017 14:55:35 -0000 --94eb2c03e7925deb9205490b9217 Content-Type: text/plain; charset=UTF-8 *AGENDA* 1. Standardizing ILP Errors 2. SHA-256 as the standard for hashlock condition interop (Raden, Lightning etc) - See: https://github.com/raiden-network/raiden/issues/399 3. ILP Packet format (binary only) 4. Amounts in ILP Packet. Do we use Base2 (Floating Point) or Base10 (Decimal) 5. Possible event in early June in Berlin (Anyone going to: http://blockchain-expo.com/europe/ ?) *Dial In Details* 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 *Reminder that all calls are recorded.* --94eb2c03e7925deb9205490b9217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AGENDA

1. Standardizin= g ILP Errors

2. SHA-256 as the standard for has= hlock condition interop (Raden, Lightning etc)

- See: https://githu= b.com/raiden-network/raiden/issues/399

3. = ILP Packet format (binary only)

4. Amounts in = ILP Packet. Do we use Base2 (Floating Point) or Base10 (Decimal)
<= div>
5. Possible event in early June in Berlin (Anyone going to: http://blockchain-expo.com/europe/<= /a> ?)

Dial In Details

To join the meeting,= go to:
ht= tps://bluejeans.com/795795755
(Try your iPhone or Android phone= )

Just want to dial in? (http://bluejeans.com/numbers)
Enter Meeting ID: 7957= 95755

Reminder that all calls are recorded.
--94eb2c03e7925deb9205490b9217-- From nobody Tue Feb 21 11:04:01 2017 Return-Path: X-Original-To: ledger@ietfa.amsl.com Delivered-To: ledger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F70129C76 for ; Tue, 21 Feb 2017 11:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ripple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czGepzRBgzkB for ; Tue, 21 Feb 2017 11:03:58 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 C825B1296D4 for ; Tue, 21 Feb 2017 11:03:57 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id r136so85164870vke.1 for ; Tue, 21 Feb 2017 11:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ripple.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8sAtTSBunbGDtYEWTWZNWvAli9ajHkkBOh5jh9IIE/I=; b=iuv8rzmtzdsocx3C7hMjsiWOjBtSt7TZRWXpF3ei0CdSVcTtfNIuspuTkbvAwe1Snp cEYRCUnR1SAdAblbdSCN88lJiT3btHrmwkQBTg1j/R7fDE3iI4r8n0RT4DyVn3jdBZNH XqGOgsvVMVm88oXrbJ9qTCuPjShlWS+u+e7vE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8sAtTSBunbGDtYEWTWZNWvAli9ajHkkBOh5jh9IIE/I=; b=tKlKhZKc8fM/Y1cJtjujA2cvtFB18u1x//4fyPEQE6UE9NHRiif/oQEMbVLep48fV0 T6bcNNv/CA0GPmXd8o9zJT5o34/Ghtxa//+Z9HgKwRM1pHmy+GLXogx+RVZvdye32niw ief4123vwe1kOL9Exm55Xlwtmz85zLGLTMzEGYPiECmBRI4raXajFmxjB1em1YnLKdKW iAsR5aATq6WYuwrR/2CBUQbWkUP29ykxUMVMAGm1UJEgzmcoGs+tegpLeqiRgbiC4ZhX Z359jvmw0llLO1zTp6PnWg/ItfG/bO4L0gXRWAIhHcndEFQ0p+bu2FQiak414p30ORhA ygRg== X-Gm-Message-State: AMke39n+1lJg++1DwThdjUDifoq3ookJxMoTEGdq4qo7uICJtR0Ymsu6bdOUtjb/bXuCcKGGKRwTeZoxwWiWGNM6 X-Received: by 10.31.151.196 with SMTP id z187mr14511150vkd.41.1487703836607; Tue, 21 Feb 2017 11:03:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Stefan Thomas Date: Tue, 21 Feb 2017 19:03:45 +0000 Message-ID: To: David Nicol , Adrian Hope-Bailie Content-Type: multipart/alternative; boundary=001a11425e44b65f1105490f0ae1 Archived-At: Cc: Interledger Community Group , Interledger Mailing List - IETF Subject: Re: [Ledger] AGENDA - Community Call - 22 February - 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, 21 Feb 2017 19:04:00 -0000 --001a11425e44b65f1105490f0ae1 Content-Type: text/plain; charset=UTF-8 @David: That's great, because that's exactly what we ended up on as well. We actually had favored a decimal floating point for most of Interledger's history, but only recently really dove deeply into the subject. The current proposal for the amount field in Interledger packets is: - Unsigned Integer, 64-bits, Big Endian (network byte order) - Scale is chosen by each ledger or ledger plugin and provided as part of the ledger metadata; the default scale for ILP Kit will be nanodollars for USD. Defaults for other currencies will be chosen accordingly. That means the largest amount of USD you can send in one transaction on ILP Kit would be 18 446 744 073.709 551 615 or about $18.45 billion. And the precision would be nanodollar. - If someone needs to create a ledger that can send both micropayments with nanodollar accuracy and payments larger than $18 billion, they can advertise their ledger with a different ledger prefix per precision. To be clear, you can even use a different prefix for the same physical account. You just can't exceed the precision within a single Interledger payment. You can, however, do a large and a simultaneous small payment with the same condition. The use case is so extreme and obscure that it seems perfectly fine to require some extra hoop jumping in this case. ("...Really? You have to have nanodollar precision for your 100 billion dollar payments?") - Similarly, if somebody wants to change their ledger's precision, they could advertise a new prefix for a while, then seamlessly make the switch and after waiting some more, turn off the old prefix. In other words, ledgers can change their Interledger precision setting without any disruption to their users. - Integers are pretty easy to parse, so this choice simplifies implementations a good deal. Connectors merely have to watch out when calculating liquidity curves (the data format we use to describe exchange rates) to avoid overflows. The structural constraints on liquidity curves (monotonically increasing) would make it very likely that even in a buggy connector implementation, an overflow condition would be caught because it would - with very high likelihood - generate invalid curves. - Because liquidity curves also use UInt64, overflowing amounts cannot be expressed at all, so they will be incredibly safe to use once generated. If you have questions, try to make it onto the call, because we'll be spending some time chatting about this stuff! On Tue, Feb 21, 2017 at 6:35 PM David Nicol wrote: > > In my opinion: > > 1. you want integers not floating point. > 2. And that integer should be 10,000 x the smallest unit the currency > supports. So USD transactions should be, at packet level, denominated as > millionths of dollars, and BTC transactions should be, at packet level, > denominated as ten-thousandths of satoshis. > 3. As this is a "binary only" wire format, the amounts should be 64 > bit integers in "network byte order" a/k/a big-endian a/k/a most > significant byte first. I don't know if negative amounts are supported or > not, if they are a decision needs to be recorded about format for negative > numbers. I think they shouldn't be allowed at all but don't know if that's > how it is. > 4. The above gives a maximum packet value of around sixteen trillion > dollars, enough to express repayment of the US National debt with one > packet (okay, no more coffee for me for a while) > > > > On Tue, Feb 21, 2017 at 8:55 AM, Adrian Hope-Bailie > wrote: > > > *AGENDA* > > 3. ILP Packet format (binary only) > > 4. Amounts in ILP Packet. Do we use Base2 (Floating Point) or Base10 > (Decimal) > > --001a11425e44b65f1105490f0ae1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
@David: That's great, because that's exactly what = we ended up on as well. We actually had favored a decimal floating point fo= r most of Interledger's history, but only recently really dove deeply i= nto the subject.

The current proposal for the amount fie= ld in Interledger packets is:

- Unsigned Integer, = 64-bits, Big Endian (network byte order)
- Scale is chosen by eac= h ledger or ledger plugin and provided as part of the ledger metadata; the = default scale for ILP Kit will be nanodollars for USD. Defaults for other c= urrencies will be chosen accordingly. That means the largest amount of USD = you can send in one transaction on ILP Kit would be 18 446 744 073.709 551 = 615 or about $18.45 billion. And the precision would be nanodollar.
- If someone needs to create a ledger that can send both micropayments w= ith nanodollar=C2=A0accuracy and payments larger than $18 billion, they can= advertise their ledger with a different ledger prefix per precision. To be= clear, you can even use a=C2=A0different prefix for the same physical acco= unt. You just can't exceed the precision within a single Interledger pa= yment. You can, however, do a large and a simultaneous small payment with t= he same condition. The use case is so extreme and obscure that it seems per= fectly fine to require some extra hoop jumping in this case. ("...Real= ly? You have to have nanodollar precision for your 100 billion dollar payme= nts?")
- Similarly, if somebody wants to change their ledger= 's precision, they could advertise a new prefix for a while, then seaml= essly make the switch and after waiting some more, turn off the old prefix.= In other words, ledgers can change their Interledger precision setting wit= hout any disruption to their users.
- Integers are pretty easy to= parse, so this choice simplifies implementations a good deal. Connectors m= erely have to watch out when calculating liquidity curves=C2=A0(the data format we use to des= cribe exchange rates) to avoid overflows. The structural constraints on liq= uidity curves (monotonically increasing) would make it very likely that eve= n in a buggy connector implementation, an overflow condition would be caugh= t because it would - with very high likelihood - generate invalid curves.
- Because liquidity curves also use UInt64, overflowing amounts ca= nnot be expressed at all, so they will be incredibly safe to use once gener= ated.

If you have questions, try to make it onto t= he call, because we'll be spending some time chatting about this stuff!=

On Tue, Feb 21,= 2017 at 6:35 PM David Nicol <da= vidnicol@gmail.com> wrote:
<= div dir=3D"ltr" class=3D"gmail_msg">

In my opinion:
  1. you want integer= s not floating point.
  2. And that integer should b= e 10,000 x the smallest unit the currency supports. So USD transactions sho= uld be, at packet level, denominated as millionths of dollars, and BTC tran= sactions should be, at packet level, denominated as ten-thousandths of sato= shis.
  3. As this is a "binary only" wire= format, the amounts should be 64 bit integers in "network byte order&= quot; a/k/a big-endian a/k/a most significant byte first. I don't know = if negative amounts are supported or not, if they are a decision needs to b= e recorded about format for negative numbers. I think they shouldn't be= allowed at all but don't know if that's how it is.
  4. The above gives a maximum packet value of around sixteen tri= llion dollars, enough to express repayment of the US National debt with one= packet (okay, no more coffee for me for a while)


On Tue, Feb 21, 2017 at 8:55 AM, Adri= an Hope-Bailie <adrian@hopebai= lie.com> wrote:
AGENDA
=
3. ILP Packet format (binary only)

4. Amounts in ILP Packet. Do we use = Base2 (Floating Point) or Base10 (Decimal)
--001a11425e44b65f1105490f0ae1--