path: root/19/3de2e5327fb56d8f6eaf7c2e36d562f1f8dd02

Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6B0E6FE4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  8 Feb 2018 20:28:04 +0000 (UTC)
X-Greylist: delayed 00:05:14 by SQLgrey-1.7.6
Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch
	[138.201.55.219])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 509F15B4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  8 Feb 2018 20:28:03 +0000 (UTC)
Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002)
	id 9583315E2BC5; Thu,  8 Feb 2018 21:22:48 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
Received: from [192.168.43.118] (pa49-199-105-122.pa.vic.optusnet.com.au
	[49.199.105.122])
	by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id B2EA715E2BC3;
	Thu,  8 Feb 2018 21:22:45 +0100 (CET)
From: Jonas Schnelli <dev@jonasschnelli.ch>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_C23FD054-4093-483B-B782-3CEADE7B3A60";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 9 Feb 2018 07:22:38 +1100
References: <8b7bd786-9bc3-efb2-a8ed-0b703e246728@riseup.net>
To: Chris Belcher <belcher@riseup.net>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <8b7bd786-9bc3-efb2-a8ed-0b703e246728@riseup.net>
Message-Id: <D28753D0-97C5-468F-B6B0-049A23FFA5AE@jonasschnelli.ch>
X-Mailer: Apple Mail (2.3273)
X-Virus-Scanned: clamav-milter 0.99.2 at bitcoinsrv.jonasschnelli.ch
X-Virus-Status: Clean
Subject: Re: [bitcoin-dev] Electrum Personal Server alpha release
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 08 Feb 2018 20:28:04 -0000


--Apple-Mail=_C23FD054-4093-483B-B782-3CEADE7B3A60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks Chris for sharing!

I=E2=80=99m following a similar approach where I=E2=80=99d like to share =
a more detailed specification soon.
Since Chris brought this up here, I=E2=80=99d like to shed some lights =
on that, very similar approach.

The idea is to have a Bitcoin Core instance running either with internal =
(Core) support for the proposed interface or via an external script =
(python bridge) while the later is probably preferable (hardened HTTPd, =
less impact on Core).

The idea is, that the interface can create new wallets (needs dynamic =
loading/unloading of wallets in Core), add addresses to a wallet (=3D=3D =
add watch-only addresses).

Addresses on the client are only visible once they could be added via =
the interface to the Core wallet as watch only (avoid missing =
transactions, addresses can be pre-added by the client and used later)

New transactions can be created through the interface (which will use =
fundrawtransaction with watch-only-addresses in the background).
Coin selection, fee calculation, etc. would happened on the Core node.

Signing of transactions happens on the client (maybe BIP174).
Optionally, a 2of2 (or 2of3 with a backup key) could be achieved where =
the node would also hold a key to have some sort of =E2=80=9E2FA=E2=80=9C =
if the node and the client environment are owned by the same person.

This would work with pruned nodes and can serve =E2=80=93 depending on =
the used hardware =E2=80=93 up to a couple of hundred wallets.

Backup restores (xpriv sweeps) are also possible via the UTXO set and =
take less then a minute and don=E2=80=99t require the full transaction =
history (or any kind of index).

Additional, the interface could also act as central, personal multisig =
bridge where n clients could use the same endpoint to participate in =
multisig wallets.

Overall, this wold allow a slick and secure (personal or group) =
(multi-)wallet service that works perfectly fine on pruned nodes by =
simply adding a bridge-script.


Thanks
=E2=80=94
Jonas


> Am 09.02.2018 um 03:51 schrieb Chris Belcher via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org>:
>=20
> Electrum is a popular bitcoin wallet, but it is not a full node wallet
> as it synchronizes itself using third-party Electrum servers. The
> servers must be trusted to verify the rules of bitcoin, they can trick
> Electrum wallets into accepting fake bitcoin transactions which, for
> example, print infinite money. Bitcoin's security model requires that
> most economic activity is backed by full nodes. The Electrum servers
> must also be trusted with the user's privacy, as wallets send all =
their
> bitcoin addresses to the server. Spying on wallets is not much more
> complicated than simply grepping the server logs. Electrum wallets by
> default also connect to servers using their own IP address, linking it
> further to their revealed bitcoin addresses.
>=20
> A way to avoid these problems is for users to run their own Electrum
> server and connect their wallets only to it. But this requires
> significant resource usage: the full unpruned blockchain, transaction
> index and an extra address index, as well as more RAM and CPU usage
> compared to just a full node. Servers are not well suited to being =
shut
> down and started up again, they are typically always online.
>=20
> Electrum servers store a database of every bitcoin address ever used,
> which is inherently not scalable. This is resource-intensive and
> therefore pushes users towards centralized solutions. An alternative =
way
> would be to store only your own addresses and transactions.
>=20
> Introducing Electrum Personal Server; an implementation of the =
Electrum
> server protocol which fulfills the specific need of using the Electrum
> UI with full node verification and privacy, but without the =
heavyweight
> server backend, for a single user. It allows the user to benefit from
> all of Bitcoin Core's resource-saving features like pruning, =
blocksonly
> and disabled txindex. All of Electrum's feature-richness like hardware
> wallet integration, multisignature wallets, offline signing, mnemonic
> recovery phrases and so on can still be used, but backed by the user's
> own full node.
>=20
> An alpha version of Electrum Personal Server can be found on the
> repository: https://github.com/chris-belcher/electrum-personal-server
>=20
> Before using, the wallet user must configure Electrum Personal Server
> with their master public key and those addresses are imported into
> Bitcoin Core as watch-only. If the wallet contains historical
> transactions then it must be rescanned. One of Electrum's motivating
> features is "instant on", which is therefore traded away when using
> Electrum Personal Server in return for full node verification and
> privacy. Although if a brand new empty wallet is created there is no
> need to rescan. A script like Electrum Personal Server is also well
> suited to use private transaction broadcasting tech like dandelion or
> broadcasting through tor.
>=20
> Using Electrum with Electrum Personal Server is probably the most
> resource-efficient way right now to use a hardware wallet connected to
> your own full node. People who make use of Blockstream Satellite could
> use it to have an off-the-grid node connected to Electrum if that is
> their preferred wallet. In the situation of a traveller staying a =
cheap
> hostels, they could sync their node every couple of days to download
> recent blocks and use Electrum. Hopefully this software can be part of
> the plan to get full node wallets into the hands of as many people as
> possible.
>=20
> The same kind of ideas could be applied to other lightweight wallets.
> For example a full nodes can run on smartphones with pruning and
> blocksonly, then a similar script would allow the user to connect =
their
> Samourai Wallet, Breadwallet or GreenAddress app to their own full =
node.
>=20
>=20
> Further Reading:
>=20
> * https://bitcointalk.org/index.php?topic=3D2664747.msg27179198
> *
> =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015=
030.html
> * https://bitcointalk.org/index.php?topic=3D1634967.0;all
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_C23FD054-4093-483B-B782-3CEADE7B3A60
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAlp8sY4ACgkQHrd2uwPH
ki2DbA//f6cLjyEJ9gDNKIMQLk2pRGOnxD08d42YaVXLXoKEzn/EqyIQD3HSdmb2
kolbIw5YOV0ayL0N1FPJJ8OnnQUxR9K8/BSH9LZhFWY9hg5yaXYKvmDiKQzeKLtm
jhfGEw8HzLDzK61zHS8W2iJS5YbI7e+AdqxFsgZ5QLK3tqqFcZQPcSQMk8AzFQcf
IVpNsSGbdAyvaQ4xOWSv8mOSsOPIoibW47UlEuCZkODWOY3LJU5DQlRu4i5gBCnZ
hvz4MWkaEDaR4WgLHDagKO65R47kUbUXqJ0CylPEcGyBmpRJ0eAJizBC19f2HHGf
uFX5xYwsVrdNLSELAr/3/AV41VDNRGUtyCPgGjBQSojxaVbRaizKJMc7YpXmOm4r
yPBL59ymDfwg/Pi3KKaEuhCCpO3niYYoAgait9SPxJifSZHljlvh4vIuHQdr9wtm
rLrEZfmccc7yNCh+uCT+ktKrblIjwKMcUh58Koujeej0kbPG36fLvQVmWbyjf673
af3un5QhQ6yWHFv6QOtZiWLHzZw85j37gWQTuxgE7kDZ053tQvze8IeZJCC0PLRx
pq8UGNQH8R8v8JyJDGxT4bAx5/YD4ZgGt55boKGa6EAqzXU1DbqMMfmytVU85Py7
QWYyJjoWUski6wm8FjvVKGuejWIoPUoVaIzsJGJvO34tQODONTo=
=CSd0
-----END PGP SIGNATURE-----

--Apple-Mail=_C23FD054-4093-483B-B782-3CEADE7B3A60--