1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
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--
|