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 15:01:03 -0300 [thread overview]
Message-ID: <CA+vKqYfNLvuQH2CEcgvJqPPOYg=1M6=1sTPm65xec7vdzTgP_A@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0t0oXGz6uXaLrGHFKUeRNFBC_MKr7x3uTH3WPkTbe5tQ@mail.gmail.com>
> Could you describe what exactly BWS does?
Sure. BWS tasks are:
* Coordinate Transaction proposals in multisignature wallets: provide
an 'always connected' node to distribute pending transaction proposals
and receive the signatures from peers.
* Coordinate and store BIP32 derivation indexes. (If the BWS
disappear, peer can still access the funds by scanning the blockchain,
but having the index in a common accessable point in useful).
* Access the blockchain and provide functions like: `getBalance` and
`getTxHistory` to peers.
* Allow agents to notify incoming funds / or transaction proposals to peers.
BWS is designed to be extremely easy to setup and run. BitPay will
provide a public BWS instance, but companies and individuals can run
their own for privacy and security reasons.
> It sounds like the server doesn't have to actually derive the keys itself for any particular purpose
> beyond knowing the addresses are a part of the wallet. Could the server work if it didn't even
> know that, and was just a bucket of arbitrary addresses with the clients themselves deriving the
> addresses?
We have evaluated BWS not having the extended public keys (and it is
still an open possibility) but the main drawback we found is that BWS
will have no way to verify addresses sent by the peers (*).
A peer could send a fake address to BWS and then functions like
'getBalance' or 'txHistory' will be broken. Of course, the peers could
verify the addresses on getTxHistory or getBalance (by Address) but we
also want to allow thin-clients and agents with lower level of trust
(than the server) that can notify the wallet balance and incoming
transaction to peers using, for example, mobile push notifications.
(*): Gregory Maxwell proposed an schema for doing this with the "not
extended" pubkeys, that we need to evaluate. That could be the best
solution.
next prev parent reply other threads:[~2015-03-13 18:01 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 [this message]
2015-03-13 18:04 ` Mike Hearn
2015-03-13 20:26 ` Matias Alejo Garcia
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+vKqYfNLvuQH2CEcgvJqPPOYg=1M6=1sTPm65xec7vdzTgP_A@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