path: root/cb/1bab231ec67a8cf9f78c2de67ba8a59c20a751

Return-Path: <antoine.riard@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 288ADC07FF;
 Sat,  9 May 2020 07:48:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 16DC688007;
 Sat,  9 May 2020 07:48:48 +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 XhZ9t9apbBFd; Sat,  9 May 2020 07:48:46 +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-pl1-f173.google.com (mail-pl1-f173.google.com
 [209.85.214.173])
 by whitealder.osuosl.org (Postfix) with ESMTPS id F05BE875B6;
 Sat,  9 May 2020 07:48:45 +0000 (UTC)
Received: by mail-pl1-f173.google.com with SMTP id b8so1734213plm.11;
 Sat, 09 May 2020 00:48:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=sl3Abux+IERHJ6lrBqKtV85Bfd419qCta6V+dVDymy4=;
 b=P0L5bUw4GdBcucOuUzC03scg9wmf42XjQUlODmXhvSECOzTsNrFQKL4kzRWgxuf8HP
 i2UYq/He6SC58Sk9TUfSmaqxswr70GHGn0zleXx7Aod8EpXcJmZeED18Nixe97nA2Tve
 Z2t/4Mdi6DPpKTxI6ixvbcos/C7TUnqze2QsiNaIZSCTlEzJQB7jno55X2Q86Yi7zvSN
 b5VRTGGsLZN4NcEFHzhm6l9aXCSsGR3JG/n275L3Iv48e/WaXpEOshWyNNY3sQNWwQqH
 62WwZxdsWQcFxIoePhbsitMRFK456dJ3YycSkvcclfGCZHprOq55m6FGobFb1bst/wo8
 XVig==
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=sl3Abux+IERHJ6lrBqKtV85Bfd419qCta6V+dVDymy4=;
 b=amw1j71vp/U9fXaIiT8azTLYbgMIcR3r8l7BCa2Y1lc75hKV0k8IeTMmzX3oqnXclw
 917epDAuxbYXBV1/ApEniCmfYocu/t94xGSFlfM8z2DZqZLfh8y4OZpZMShyd14saCQ4
 hKRa3ICcBK5R/3fFny77Draj8hwX9m4q3AhO2gdHPbc1Jm62EFZvF/3f7UfskfocEk7V
 uZFKL6GBxJXR1NPkdR1x3QVWi35niP7rajagH1pWl+UmlxKCC6qPrw+pW2NNNwZft14p
 JvPdIi9zfShsTyttFODCMQneeIuITFpf6OX5T6d00A5RXNvQQlJ4Ku3GBw9SZX/IIZvT
 G7mA==
X-Gm-Message-State: AGi0PubkzVIibH8Y2oo0PsKiSU6EvUtniD1IomNIFxeXCoJinKIDJNsj
 gWo4mq1RaNyX4PTd4+ll7FXDlpm0l8i2w5XeSQE=
X-Google-Smtp-Source: APiQypLs9kVrB5EaE+HwDl6/HUdk2uOxOZJ8yopu3ybCpujkyH/NMh2vYkc+AG/8J2a+Mg5IDMo+m5xYoUoxmkJ5AY0=
X-Received: by 2002:a17:90a:b00d:: with SMTP id
 x13mr10266544pjq.227.1589010525460; 
 Sat, 09 May 2020 00:48:45 -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>
 <CACrqygCbX8ru=OJk==3T+Bav7ykiO+Vid98tLY--ww__fr-PjA@mail.gmail.com>
In-Reply-To: <CACrqygCbX8ru=OJk==3T+Bav7ykiO+Vid98tLY--ww__fr-PjA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sat, 9 May 2020 03:48:33 -0400
Message-ID: <CALZpt+F1LebsfFG+UxuW33SiUT3_3KNqvo+T9RGcaYr5UbQEpw@mail.gmail.com>
To: Christopher Allen <ChristopherA@lifewithalacrity.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ea1c3a05a53257ba"
X-Mailman-Approved-At: Sat, 09 May 2020 14:55:30 +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: Sat, 09 May 2020 07:48:48 -0000

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

Hi Christopher,

Thanks for Blockchain Commons and Learning Bitcoin from the Command Line!

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

Yes generally refactoring in Core wallets are making good progress [0]. I'm
pretty sure feedbacks and proposals on future changes with regards to
usability would be greatly appreciated.

Maybe you can bring these during a IRC meeting ?

Antoine

[0] See https://github.com/bitcoin/bitcoin/pull/16528 or
https://github.com/bitcoin/bitcoin/pull/16426

Le ven. 8 mai 2020 =C3=A0 17:31, Christopher Allen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> 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 weigh=
t
>> in on that, but without something like this, you cannot limit your expos=
ure
>> for serving something like bip157 filters without removing your own abil=
ity
>> 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 mechanis=
m 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 t=
he
> way to things RPC can=E2=80=99t do like deleting a wallet and changing bi=
tcoin.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 bei=
ng
> a transparent shim between bitcoin-core & remote RPC, but later could
> inform proposals for the future of the core wallet functionality as it ge=
ts
> refactored.
>
> =E2=80=94 Christopher Allen
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Hi Christopher,<br><br></div>Thanks for Blockchain Co=
mmons and Learning Bitcoin from the Command Line!<br><div><br>&gt; If there=
 are people interested in coordinating some proposals on how to=20
defining different sets of wallet functionality, Blockchain Commons=20
would be interested in hosting that collaboration. This could start as=20
just being a transparent shim between bitcoin-core &amp; remote RPC, but
 later could inform proposals for the future of the core wallet=20
functionality as it gets refactored.<br><br></div><div>Yes generally refact=
oring in Core wallets are making good progress [0]. I&#39;m pretty sure fee=
dbacks and proposals on future changes with regards to usability would be g=
reatly appreciated.<br><br></div><div>Maybe you can bring these during a IR=
C meeting ?</div><div><br></div><div>Antoine<br></div><div><br></div><div>[=
0] See <a href=3D"https://github.com/bitcoin/bitcoin/pull/16528">https://gi=
thub.com/bitcoin/bitcoin/pull/16528</a> or <a href=3D"https://github.com/bi=
tcoin/bitcoin/pull/16426">https://github.com/bitcoin/bitcoin/pull/16426</a>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">Le=C2=A0ven. 8 mai 2020 =C3=A0=C2=A017:31, Christopher Allen via bitc=
oin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div>On Fri, May 8, 2020 at 2:0=
0 PM Keagan McClelland via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt; wrote:<br></div><div><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Perhaps I wasn&#=
39;t explicit in my previous note but what I mean is that there seems to be=
 a demand for something <i>in between</i> a peer interface, and an owner in=
terface. 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 exposure for serving so=
mething like bip157 filters without removing your own ability to make use o=
f some of those same services.</div></div></blockquote><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Our FullyNoded2 multisig wallet on iOS &amp; Mac,=
 communicates with your own personal node over RPC, securing the connection=
 using Tor over a hidden onion service and two-way client authentication us=
ing a v3 Tor Authentication key: <a href=3D"https://github.com/BlockchainCo=
mmons/FullyNoded-2" target=3D"_blank">https://github.com/BlockchainCommons/=
FullyNoded-2</a></div><div dir=3D"auto"><br></div><div dir=3D"auto">It many=
 ways the app (and its predecessor FullyNoded1) is an interface between a p=
ersonal full node and a user.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">However, we do wish that the full RPC functionality was not exposed i=
n bitcoin-core. I=E2=80=99d love to see a cryptographic capability mechanis=
m such that the remote wallet could only m ask the node functions that it n=
eeds, and allow escalation for other rarer services it needs with addition =
authorization.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Thi=
s capability mechanism feature set should go both ways, to a minimum subset=
 needed for being a watch-only transaction verification tool, all the way t=
o things RPC can=E2=80=99t do like deleting a wallet and changing bitcoin.c=
onf parameters and rebooting, without requiring full ssh access to the serv=
er running the node.</div><div dir=3D"auto"><br></div><div dir=3D"auto">If =
there are people interested in coordinating some proposals on how to defini=
ng different sets of wallet functionality, Blockchain Commons would be inte=
rested in hosting that collaboration. This could start as just being a tran=
sparent shim between bitcoin-core &amp; remote RPC, but later could inform =
proposals for the future of the core wallet functionality as it gets refact=
ored.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=E2=80=94 Christop=
her Allen</div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000ea1c3a05a53257ba--