Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2020-05-09 📝 Original message: Hi Christopher, Thanks ...
📅 Original date posted:2020-05-09
📝 Original message:
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 à 17:31, Christopher Allen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev <
> bitcoin-dev at 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 exposure
>> for serving something like bip157 filters without removing your own ability
>> 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’d 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’t do like deleting a wallet and changing bitcoin.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.
>
> — Christopher Allen
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200509/f1180329/attachment.html>
📝 Original message:
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 à 17:31, Christopher Allen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> On Fri, May 8, 2020 at 2:00 PM Keagan McClelland via bitcoin-dev <
> bitcoin-dev at 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 exposure
>> for serving something like bip157 filters without removing your own ability
>> 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’d 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’t do like deleting a wallet and changing bitcoin.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.
>
> — Christopher Allen
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200509/f1180329/attachment.html>