Chris Belcher via bitcoin-dev
2018-03-29 12:07:04 UTC
Electrum Personal Server is an implementation of the Electrum wallet
server protocol that allows users to point their Electrum wallet at
their own full node. It is compatible resource-saving features like
pruning, blocksonly and disabled txindex. It is much less
resource-intensive than other Electrum servers because it only stores
the user's own addresses, instead of every address that was ever used.
As such it makes tradeoffs, namely losing Electrum's "instant on" feature.
Right now using Electrum Personal Server is the easiest way to use a
hardware wallet backed by your own full node. It is very lightweight,
being a small python script that barely uses any CPU or RAM; much less
than the full node it's connected to. Hopefully Electrum Personal Server
can be part of the solution in putting full node wallets into the hands
of as many people as possible.
The project is now in beta release:
https://github.com/chris-belcher/electrum-personal-server
It now has all the essential features to make it practical for use;
Merkle proofs, deterministic wallets, bech32 addresses, SSL, Core's
multi-wallet support. Along with the features that were in the alpha
release of tracking new transactions, confirmations, block headers,
importing addresses.
There is a caveat about pruning. Electrum Personal Server obtains merkle
proofs using the `gettxoutproof` RPC call, if pruning is enabled and
that block has been deleted then the RPC will return null and so the
Electrum wallet will display `Not Verified`. Everything else will still
work, and this shouldn't be a problem in most situations because
Electrum usually only requests merkle proofs for recent transactions and
pruning keeps recent blocks. But in the long term it needs some thought
on the best way to fix this. I've been thinking about adding code for
Bitcoin Core that stores merkle proofs for each of the wallet's own
transactions in wallet.dat.
Further Reading:
*
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015707.html
* https://bitcointalk.org/index.php?topic=3167572.0
server protocol that allows users to point their Electrum wallet at
their own full node. It is compatible resource-saving features like
pruning, blocksonly and disabled txindex. It is much less
resource-intensive than other Electrum servers because it only stores
the user's own addresses, instead of every address that was ever used.
As such it makes tradeoffs, namely losing Electrum's "instant on" feature.
Right now using Electrum Personal Server is the easiest way to use a
hardware wallet backed by your own full node. It is very lightweight,
being a small python script that barely uses any CPU or RAM; much less
than the full node it's connected to. Hopefully Electrum Personal Server
can be part of the solution in putting full node wallets into the hands
of as many people as possible.
The project is now in beta release:
https://github.com/chris-belcher/electrum-personal-server
It now has all the essential features to make it practical for use;
Merkle proofs, deterministic wallets, bech32 addresses, SSL, Core's
multi-wallet support. Along with the features that were in the alpha
release of tracking new transactions, confirmations, block headers,
importing addresses.
There is a caveat about pruning. Electrum Personal Server obtains merkle
proofs using the `gettxoutproof` RPC call, if pruning is enabled and
that block has been deleted then the RPC will return null and so the
Electrum wallet will display `Not Verified`. Everything else will still
work, and this shouldn't be a problem in most situations because
Electrum usually only requests merkle proofs for recent transactions and
pruning keeps recent blocks. But in the long term it needs some thought
on the best way to fix this. I've been thinking about adding code for
Bitcoin Core that stores merkle proofs for each of the wallet's own
transactions in wallet.dat.
Further Reading:
*
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015707.html
* https://bitcointalk.org/index.php?topic=3167572.0