From: Matias Alejo Garcia <matias@bitpay•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP32 Index Randomisation
Date: Fri, 13 Mar 2015 17:26:32 -0300 [thread overview]
Message-ID: <CA+vKqYeafvwJkwWfiMTZDhO_7nxbdLFRppptZRbRoeBJP8O9qg@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1a_hqkZSfnWbfzJj2Y7Z0yptUOuH5iFG=CB5hwjWG3Ew@mail.gmail.com>
> It sounds like the main issue is this is a web wallet server of some kind.
> If the clients were SPV then they'd be checking their own balances and
> downloading their own tx history, which would mean the coordination tasks
> could be done by storing encrypted blobs on the server rather than the
> server itself having insight into what's going on (see: Subspace).
You are killing us Mike! :) We really don't like to think that BWS is
a webwallet. Note
that private keys are not stored (not even encrypted) at the server. Addresses
can be generated offline, funds received and transferred by the peers
without accessing
BWS.
Currently Copay uses the encrypted blob idea (checks balances and tx
history thought Insight), but after working with Copay for ~6 months
we think having some visibility of the wallet by the multisig
facilitator will make the user experience much better (e.g: mobile
notifications).
Thanks for the Subspace reference, we will definitely check it.
> So whilst you might be able to use some scheme to avoid the server knowing
> the xpubkey, if the server still knows all addresses and all transactions
> because the clients are web wallets ..... is there any point? It seems like
> maybe going from server knows everything to server knows 95% of everything:
> maybe not worth the engineering cost.
Interesting point. IMO, if we can prevent the server from having the xpubs keys
it would be valuable: It will give us more flexibility for future
features, and if the server is compromised future addresses will not
be known by the attacker, but of course we need to evaluate the cost.
matías
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
BitPay.com
next prev parent reply other threads:[~2015-03-13 20:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 3:48 Matias Alejo Garcia
2015-03-13 4:01 ` Gregory Maxwell
2015-03-13 16:40 ` Mike Hearn
2015-03-13 18:01 ` Matias Alejo Garcia
2015-03-13 18:04 ` Mike Hearn
2015-03-13 20:26 ` Matias Alejo Garcia [this message]
2015-03-13 21:34 ` Mike Hearn
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+vKqYeafvwJkwWfiMTZDhO_7nxbdLFRppptZRbRoeBJP8O9qg@mail.gmail.com \
--to=matias@bitpay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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