ryanxcharles

  MIP: 70
  Layer: Applications
  Title: Payment Protocol
  Author&#58; Gavin Andresen <gavinandresen@gmail.com>
          Mike Hearn <mhearn@bitcoinfoundation.org>

Ryan X. Charles Brendan mohrt Lorien Gamaroff

ryanxcharles

Takeaways from the "scaling bitcoin + hosting & infrastructure" round table at Scaling Bitcoin in Montreal, September 12, 2015.

• we had very good representation from major bitcoin infrastructure companies
  • large fraction, if not majority, of bitcoins held, bitcoins transacted and bitcoin API calls made
• everyone wants the block size to increase - only a question of how
  • remarkable that infrastructure companies universally agreed on hard forking bitcoin
• some infrastructure companies to run implementations of bitcoin other than Bitcoin Core
  • meaning Bitcoin Core may have less influence than usually thought
  • we also know that some miners have done SPV mining - so what fraction of miners are actually using Bitcoin Core's ruleset?
• lately, wallets have had difficulty computing fees - what happens if different wallets disagree? - stress tests cause issues

ryanxcharles

Privacy is one of the greatest value propositions of bitcoin, and security is one of the greatest challenges. Signing services, which hold one or more keys in a multisig wallet, greatly help to improve the security of bitcoin by adding 2-factor auth and spending policies, but have traditionally come at the cost of privacy, because the signing service knows what addresses belong to the user, and therefore knows how many bitcoins the user has. Fortunately, it is possible to use similar elliptic curve mathematics as BIP32 and stealth addresses in order to have all the advantages of signing services while still maintaining privacy. We call this a stealth signing service.

Assume the signing service will hold one key in a 2-of-3 wallet configuration. The user holds one key online and the final key in cold storage. The user needs to be able to generate addresses for outputs that can be spent with 2-of-3 keys, while at the same time the signing service should not be able to derive what these addresses are, so that t

ryanxcharles

Stealth Addresses, Transactions and Messages

Normal bitcoin addresses cannot be published in public without losing all privacy, since all transactions to that address can be seen by anybody. Stealth addresses let us publish an address in public which can be used by payers to derive a new address that the payee has access to, but no one else knows is associated with the stealth address. The trick is that the payer must use a nonce to derive the address paid to, and this nonce must be delivered to the payee so they know how to recover the funds. This nonce can be delivered in the transaction, so that no separate channel is required to communicate the nonce.

The same technology can also be used to construct new public keys to send encrypted messages to.

We will discuss four methods:

1. The simplest form of stealth addresses, which has some drawbacks that can improved upon.

ryanxcharles

First, The Problem:

Allow for users of Safari and IE to use Copay, and allow for
asynchronous transaction proposals. Do so in a manner consistent with
decentralization, i.e. with no central points of failure, i.e. where the
copayers do not have to trust anybody, including the other copayers and
including BitPay.

The Web RTC Solution:

ryanxcharles

These are the unviolable principles of Copay.

1. Copay is decentralized, i.e. it has no central point of failure, i.e. the users (copayers) do not have to trust anyone to be able to use the Copay app.

2. Every pull request moves towards, not away from, this ideal. A pull request that adds central points of failure gets NACKd.

3. Any existing central point of failure is a bug that must be fixed (i.e., relying on a single PeerJS server, or trusting messages from other Copayers).

4. Where possible, we prefer software to be written on the web first, so that it is easily cross-platform. Not everything can be written in a web browser. Such code will be located in a local node server which both delivers the web app and does anything that cannot be done in the browser.

ryanxcharles

Keybase proof

I hereby claim:

• I am ryanxcharles on github.
• I am ryanxcharles (https://keybase.io/ryanxcharles) on keybase.
• I have a public key whose fingerprint is 123E 4DDF ED12 01B1 03DA 79DE 1FA9 94E2 A11B 4DDE

To claim this, I am signing this object:

ryanxcharles

There are two communication phases for a Copay wallet: The wallet creation phase, which is when the copayers do not yet know the public keys of the other copayers. Then the wallet usage phase, where the copayers do know the public keys of the other copayers.

Each copayer independently generates a master extended public/private key pair before wallet creation which can be used to derive further public/private keys deterministically.

Wallet Creation

The author of the wallet derives a new public/private key pair for the communication purposes. This is the communication public/private key pair of the author.

The hash of the communication public key is used as the PeerJS id.

ryanxcharles

'use strict';
var imports = require('soop').imports();
var bitcore = require('bitcore');
var Storage = imports.Storage || require('./Storage');

function Wallet(opts) {
  opts = opts || {};

  this.network = opts.network === 'livenet' ? 
      bitcore.networks.livenet : bitcore.networks.testnet;