public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <hearn@vinumeris.com>
To: Jonas Schnelli <dev@jonasschnelli.ch>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Future Of Bitcoin-Cores Wallet
Date: Tue, 11 Aug 2015 13:03:15 +0200	[thread overview]
Message-ID: <CA+w+GKR1BNpVk4SAKExrkGDMzb+BQfinpmWGbNiMyM89DnzOFA@mail.gmail.com> (raw)
In-Reply-To: <55C9BA0F.60408@jonasschnelli.ch>

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

Hey Jonas,

I think your analysis of what (some) users need is a good one.

We've discussed this before so I know you prefer your current approach, but
I personally would take a slightly different path to reach the same end:

   1. Support serving of SPV wallets from pruned storage. This means some
   protocol upgrades, BIPs, etc. It helps all SPV wallets, including on phones.
   2. Then make a bitcoinj based desktop wallet app, that contains a
   bundled bitcoind.
   3. Make the app sync TWO wallets simultaneously, one from the P2P
   network as today, and another from the local bitcoind via a local socket
   (or even just passing buffers around internally)
   4. The app should then switch from using the wallet synced to P2P to the
   wallet synced to localhost when the latter is fully caught up, and back
   again when the local node is behind.
   5. If there's a discrepancy, alert the user.

There are big advantages of taking this path! They are:

   - The switching back and forth between local full-security mode (which
   may be behind) and remote SPV security (fully synced) is instant and
   transparent to the user. This is important for laptop users who don't run a
   local node all the time. The different audit levels can be reflected in the
   UI in some way.

   - The bitcoinj wallet code already has support for things like
   multi-sig, BIP32, seed words, micropayment channels, etc. You can disable
   Bloom filtering if you like (download full blocks).

   - You can do a local RPC or JNI/JNA call to get fee estimates, if wanted.

   - The modern JVM tools and languages are much, much more productive than
   working with C++.


If you want a thing that runs a home server, then the best way to do that
IMO would be to bundle Tor and make it auto-register a Tor hidden service.
Then you can just define a QR code standard for 'pairing' a wallet to a
.onion address. Any bitcoinj based wallet can sync to it, and as it's your
own node, you can use a Bloom filter sized to give virtually no false
positives. No additional indexing is then required.

[-- Attachment #2: Type: text/html, Size: 2250 bytes --]

  reply	other threads:[~2015-08-11 11:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-11  9:02 [bitcoin-dev] Future Of Bitcoin-Cores Wallet Jonas Schnelli
2015-08-11 11:03 ` Mike Hearn [this message]
2015-08-11 11:21   ` Sriram Karra
2015-08-11 15:46 ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+w+GKR1BNpVk4SAKExrkGDMzb+BQfinpmWGbNiMyM89DnzOFA@mail.gmail.com \
    --to=hearn@vinumeris.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dev@jonasschnelli.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox