path: root/bf/bc989f56bc1886c905f21f717c02f2038a9e6f

Return-Path: <christophera@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 381F0C07FF;
 Fri,  8 May 2020 21:30:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 276D188AD1;
 Fri,  8 May 2020 21:30:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fTsCNqUvmzsY; Fri,  8 May 2020 21:30:01 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com
 [209.85.222.42])
 by whitealder.osuosl.org (Postfix) with ESMTPS id E900B88AB6;
 Fri,  8 May 2020 21:30:00 +0000 (UTC)
Received: by mail-ua1-f42.google.com with SMTP id t8so1224924uap.3;
 Fri, 08 May 2020 14:30:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=lifewithalacrity-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=wlUJm5CugMm/X5tMvynGA59F88LMnXtVxzXeUVfmCKM=;
 b=0Q+VmODR2f7c4WUig+rJ1tnDnRNJT/z6GY2aV8R7biGiErIt7TgfIovxXxIgKhzTyn
 0+cVktyhmIdZmAqzj0xNgncngLExyPWtbuZTS8ZZ+m2OILZYwuMg3gj0ixXvywkYK8dN
 Exnzk6r0cmhifj2e4HM1d4ly4kDuk7qiNeOIw5Vk2dAVISlM/2BHNS9JwnVsKqZYdv6O
 h1IbLHTB6drRInSSvlvCGNluKbfs1euM8UAT6IsEq8PxdaCNF6oP4XlpE7zIG4v9L9ii
 wMLBX6R1/Ja21UytyIAm3LE+CnTkdzrU2i2fBZAWwFPKc7SRT+9KMkNSHt9VDiCILnlq
 x8fA==
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=wlUJm5CugMm/X5tMvynGA59F88LMnXtVxzXeUVfmCKM=;
 b=d7j5rs5snn9Jfw3fHfPFNqmnZIBFXBvN9gcoUhyWxPxUQOxR4EYHmE2pGlZyLb4hBq
 KsiFdEukcTVzW/FsZBxkggl1oH3cPP/MzBpuAOFhP7A7PrXR7UOfrxqC/zKDaIqggDNl
 SrOE8wlJsvTqpqsoU+rAs3JAdjlKv+UOqgzmSrqJwocffzPocu7DrQB7mSaDFuxz8df8
 TNx2ymPCGP0QBObadP9gT8X9oSyDq9QYLh6Loi8mqtSqxhwCrdkoF8JaZwCgPcVTArHU
 qBJcO8+hZlRx9yk7ROZmel/qt0IYWqFFeC7FDU+fOr0uQ5osUROD+fXJQ5YTCjxF13i3
 vpzA==
X-Gm-Message-State: AGi0PuYJmUzjh4Z6PFQvX2b9k4tl9MH6zES3PKduFtwBUC+P47HKmxjr
 scDOAzDbqON/J7A/6btKcSiM4GnOYQP+jX61Dz+jhsCi
X-Google-Smtp-Source: APiQypJEEnj7F3JxZJJEGmLUP33KfCSs9FeoFPNDaeTBJrlglgN4T99jvLGaLaFAVTcHFdL+ej9NjooJOdj2fFdRo1E=
X-Received: by 2002:ab0:6893:: with SMTP id t19mr4225904uar.37.1588973399364; 
 Fri, 08 May 2020 14:29:59 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <202005051300.38836.luke@dashjr.org>
 <CALZpt+GR8L6Zo_4A8LJb=yndr32g62XFKBmGiWMSRaZqHrfOog@mail.gmail.com>
 <CALeFGL3LnhEhcsuCeusBjZL=4Exm9fiQuALDfN53wrHLLGMejA@mail.gmail.com>
 <CALZpt+Fmv3d-J69uyoJ5XB9hP78vqoS76Y2OVmHWqafkHTm5ZQ@mail.gmail.com>
 <CALeFGL3WRF11Q7d3Mea5nHS2da1atEfXArpdAfMfd1uJ+5f3JA@mail.gmail.com>
 <ecce23db-2622-b257-5a05-22a40aafd1e3@purse.io>
 <CALeFGL0vRM5o21oD0mrtPFnRCdRTUkyEv_nry3SQ4nvgyShGdA@mail.gmail.com>
In-Reply-To: <CALeFGL0vRM5o21oD0mrtPFnRCdRTUkyEv_nry3SQ4nvgyShGdA@mail.gmail.com>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Fri, 8 May 2020 14:29:48 -0700
Message-ID: <CACrqygCbX8ru=OJk==3T+Bav7ykiO+Vid98tLY--ww__fr-PjA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 Keagan McClelland <keagan.mcclelland@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000006d9e505a529b3e9"
X-Mailman-Approved-At: Fri, 08 May 2020 21:31:03 +0000
Cc: "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of
 onboarding millions of LN mobile clients
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2020 21:30:03 -0000

--00000000000006d9e505a529b3e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Perhaps I wasn't explicit in my previous note but what I mean is that
> there seems to be a demand for something *in between* a peer interface,
> and an owner interface. I have little opinion as to whether this belongs =
in
> core or not, I think there are much more experienced folks who can weight
> in on that, but without something like this, you cannot limit your exposu=
re
> for serving something like bip157 filters without removing your own abili=
ty
> to make use of some of those same services.
>

Our FullyNoded2 multisig wallet on iOS & Mac, communicates with your own
personal node over RPC, securing the connection using Tor over a hidden
onion service and two-way client authentication using a v3 Tor
Authentication key: https://github.com/BlockchainCommons/FullyNoded-2

It many ways the app (and its predecessor FullyNoded1) is an interface
between a personal full node and a user.

However, we do wish that the full RPC functionality was not exposed in
bitcoin-core. I=E2=80=99d love to see a cryptographic capability mechanism =
such
that the remote wallet could only m ask the node functions that it needs,
and allow escalation for other rarer services it needs with addition
authorization.

This capability mechanism feature set should go both ways, to a minimum
subset needed for being a watch-only transaction verification tool, all the
way to things RPC can=E2=80=99t do like deleting a wallet and changing bitc=
oin.conf
parameters and rebooting, without requiring full ssh access to the server
running the node.

If there are people interested in coordinating some proposals on how to
defining different sets of wallet functionality, Blockchain Commons would
be interested in hosting that collaboration. This could start as just being
a transparent shim between bitcoin-core & remote RPC, but later could
inform proposals for the future of the core wallet functionality as it gets
refactored.

=E2=80=94 Christopher Allen

--00000000000006d9e505a529b3e9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev &lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt; wrote:<br></div><div><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Perhaps I wasn&#39;t e=
xplicit in my previous note but what I mean is that there seems to be a dem=
and for something <i>in between</i> a peer interface, and an owner interfac=
e. I have little opinion as to whether this belongs in core or not, I think=
 there are much more experienced folks who can weight in on that, but witho=
ut something like this, you cannot limit your exposure for serving somethin=
g like bip157 filters without removing your own ability to make use of some=
 of those same services.</div></div></blockquote><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Our FullyNoded2 multisig wallet on iOS &amp; Mac, commu=
nicates with your own personal node over RPC, securing the connection using=
 Tor over a hidden onion service and two-way client authentication using a =
v3 Tor Authentication key: <a href=3D"https://github.com/BlockchainCommons/=
FullyNoded-2">https://github.com/BlockchainCommons/FullyNoded-2</a></div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">It many ways the app (and its p=
redecessor FullyNoded1) is an interface between a personal full node and a =
user.</div><div dir=3D"auto"><br></div><div dir=3D"auto">However, we do wis=
h that the full RPC functionality was not exposed in bitcoin-core. I=E2=80=
=99d love to see a cryptographic capability mechanism such that the remote =
wallet could only m ask the node functions that it needs, and allow escalat=
ion for other rarer services it needs with addition authorization.=C2=A0</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">This capability mechanism =
feature set should go both ways, to a minimum subset needed for being a wat=
ch-only transaction verification tool, all the way to things RPC can=E2=80=
=99t do like deleting a wallet and changing bitcoin.conf parameters and reb=
ooting, without requiring full ssh access to the server running the node.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">If there are people inter=
ested in coordinating some proposals on how to defining different sets of w=
allet functionality, Blockchain Commons would be interested in hosting that=
 collaboration. This could start as just being a transparent shim between b=
itcoin-core &amp; remote RPC, but later could inform proposals for the futu=
re of the core wallet functionality as it gets refactored.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">=E2=80=94 Christopher Allen</div></div><=
/div>

--00000000000006d9e505a529b3e9--