Return-Path: 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: <202005051300.38836.luke@dashjr.org> In-Reply-To: From: Antoine Riard Date: Sat, 9 May 2020 03:48:33 -0400 Message-ID: To: Christopher Allen , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000ea1c3a05a53257ba" X-Mailman-Approved-At: Sat, 09 May 2020 14:55:30 +0000 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi Christopher,

Thanks for Blockchain Co= mmons and Learning Bitcoin from the Command Line!

> 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 & remote RPC, but later could inform proposals for the future of the core wallet=20 functionality as it gets refactored.

Yes generally refact= oring in Core wallets are making good progress [0]. I'm pretty sure fee= dbacks and proposals on future changes with regards to usability would be g= reatly appreciated.

Maybe you can bring these during a IR= C meeting ?

Antoine


Le=C2=A0ven. 8 mai 2020 =C3=A0=C2=A017:31, Christopher Allen via bitc= oin-dev <bitcoi= n-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
On Fri, May 8, 2020 at 2:0= 0 PM Keagan McClelland via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
Perhaps I wasn&#= 39;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 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.
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 us= ing 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 p= ersonal full node and a user.

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

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.

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 & remote RPC, but later could inform = proposals for the future of the core wallet functionality as it gets refact= ored.

=E2=80=94 Christop= her Allen
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000ea1c3a05a53257ba--