From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6B0E6FE4 for ; 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 ; 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 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 , Bitcoin Protocol Discussion In-Reply-To: <8b7bd786-9bc3-efb2-a8ed-0b703e246728@riseup.net> Message-Id: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = : >=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--