public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol
@ 2013-06-19 19:29 Jeremy Spilman
  2013-06-19 20:10 ` Alan Reiner
  0 siblings, 1 reply; 25+ messages in thread
From: Jeremy Spilman @ 2013-06-19 19:29 UTC (permalink / raw)
  To: Bitcoin Dev

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

If you have two parties who want to form a persistent relationship, by exchanging and verifying public keys beforehand, then I think the canonical way to do this with BIP32 is for the parties to exchange PubKey and *ChainCode*.

I don’t understand the use case for handing out individual multipliers, if what you desire is a persistent relationship. If each party dedicates a child-wallet for receiving coins, and saves a PubKey/ChainCode for sending coins, the two parties can transaction securely forever without ever exchanging any more information, and without any address reuse.

I think ideally, the default behavior is that wallets always dedicate a new child node {PubKey, ChainCode} to each party they transact with. At the presentation layer, you have a “contact” and each contact has a transaction history. You can send coins to a contact at any time, and internally the wallet picks the next address in their sequence. Any funds received on pubkeys from contact’s sequence are attributed to that contact. The wallet can organize the contacts, and roll-up the transaction history into ‘ledgers’ and ‘balances’ however they want – it could be based on the underlying BIP32 hierarchy or perhaps not. The cost of watching large a number of pubkeys, even if you ‘look ahead’ 100 pubkeys for each contact, is relatively small versus the benefits.

What might be nice is a ‘Contact Request’ protocol, basically the same as a PaymentRequest but no actual payments are sent, just child wallets created:

message Contact {
    optional uint32 contact_version = 1 [default = 1];
    optional string pki_type = 2 [default = "none"];
    optional bytes pki_data = 3;
    required bytes serialized_contact_details = 4;
    optional bytes signature = 5;
}

message ContactDetails {
    optional string network = 1 [default = "main"];
    required bytes pubkey = 2;
    required bytes chaincode = 3;
    optional string memo = 4;
    optional string response_url = 5;
}

Alice sends a Contact+ContactDetails to Bob.  If Bob accepts, he sends his own Contact+ContactDetails (without a response_url) back to Alice. Basically just like adding a contact to your IM contacts.

Alice could send a Contact+ContactDetails to Bob without a response_url, in which case after accepting the contact, Bob could send funds to Alice, but not receive funds.

You could probably pack the whole message inside a bitcoin:// URI if you wanted to.

Thanks,
--Jeremy

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
* [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol
@ 2013-06-18  3:48 Alan Reiner
  2013-06-19 12:19 ` Melvin Carvalho
                   ` (2 more replies)
  0 siblings, 3 replies; 25+ messages in thread
From: Alan Reiner @ 2013-06-18  3:48 UTC (permalink / raw)
  To: Bitcoin Dev

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

_*Goal*_:  An alternative address format made possible by BIP 32, which
allows one to specify a "Wallet ID" and "One-time payment" code, instead
of the standard one-use Base58-Hash160 addresses.   This allows parties
with a persistent relationship to be able to prove that payment
addresses they provide each other are linked to a particular wallet,
reducing exposure to MitM attacks without the need for SSL or a web of
trust, and without compromising the privacy of either party.    For
instance, this could be used between businesses that frequently do
business, by exchanging and verifying public keys beforehand, or could
be used by an exchange to identify if a customer withdrawal address is
related to their last deposit address, and if not enforce extra
authentication measures.

_*Background*__:_
I haven't been following the payment protocol discussions/development
much, so I apologize if this has already been addressed.   I'm calling
it "wallet-linkable" addresses, which would be an optional second form
for sending someone your address.   With BIP 32, the address is computed
by the payee (the person sending the address to receive money):

   Standard Address ~ Base58(0x00 || hash160(PubKeyParent *
Multiplier[i]) || checksum)

What I'd like to do is have the option, when specifying an address
through the payment protocol, to send *just* the {PublicKeyParent,
Multiplier[i]} and let the receiver of that address compute the address
on their own.  This is no significant burden on the receiver, but it
does provide the useful property that they can recognize when addresses
specified in this way come from the same wallet -- because the
PubKeyParent will be the same.  Remember, this is _optional_ for the
person providing the address.

One nice, accidental feature of BIP 32 is that the Multiplier[i] used
above does not actually reveal the "chaincode" (I think Pieter started
calling it the "tweak").   It is derived from the chaincode but doesn't
reveal it.  Therefore, the payer sees the parent public key, but that's
not useful to derive any of the other addresses unless they also have
the chaincode.  But they can verify that the PublicKeyParent is
identical between transactions, and thus is accessible only to that
wallet.  It allows them validate a specific address provided by the
payee, but not generate or identify any other addresses.

*_Use Cases:_*
(1)  So, just like with PGP/GPG, when two parties decide they will start
a relationship, they can start by exchanging the public keys of their
wallet and verify them in a reliable manner.  After that, when one party
requests a payment address from the other, they can optionally send
{PubKey, Multiplier}, and the payer's software will identify the owner
of that address, or let you select who you think the address belongs to
and it will verify it.  If the payee's system is compromised and address
is replaced, the address received by the payer won't validate.  This
doesn't help if the side sending the money is compromised.

(2)  When a customer first provides a deposit to an exchange, it will
send money from an address in their wallet and the software will provide
the exchange the {PubKey,Mult}.  When the customer later provides a
withdrawal address, the site can automatically trust the address as long
it is provided in the alternate form and the public keys match.  If they
don't, it might be the same customer just requesting a withdrawal to a
different wallet, which is fine, but they'll have to go through an extra
verification step to do so. 


_*Downsides:*_ 
Multi-sig/P2SH  - The only way this works with P2SH, violates one of the
goals of P2SH slightly, but may not matter much if it's all done under
the hood by the software.  Instead of providing a 20-byte hash of a
script, you provide all the public keys and multipliers for the
individual addresses.  The payer's software automatically verifies all
addresses and creates the P2SH script itself (after a divine decree that
public keys will always be sorted lexicographically in the multi-sig
script).  The blockchain still benefits from the "compression" of moving
the bulky scripts to the TxIn, but it does require revealing more
information than is necessary for the payer to pay the payee.  But it
may not /really/ be a problem, given the benefits.  It might just be
slightly longer strings to exchange during initialization and for each
transaction.

I have various reasons I'd like to use this, and it'd be nice to have
some community backing, so I don't have to twist anyone's arm to trust
me that it's legit.

-Alan





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

^ permalink raw reply	[flat|nested] 25+ messages in thread
end of thread, other threads:[~2013-08-09 21:51 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-19 19:29 [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol Jeremy Spilman
2013-06-19 20:10 ` Alan Reiner
2013-06-19 21:58   ` Jeremy Spilman
2013-06-19 22:47     ` Alan Reiner
2013-06-20  3:54       ` Jeremy Spilman
2013-06-20  7:32         ` Mike Hearn
2013-06-26 15:29           ` Alan Reiner
2013-08-09 17:57             ` [Bitcoin-development] Optional "wallet-linkable" address format (Re-request) Alan Reiner
2013-08-09 19:58               ` Mike Hearn
2013-08-09 20:12                 ` Alan Reiner
2013-08-09 20:35                   ` Mike Hearn
2013-08-09 21:51               ` Gavin Andresen
  -- strict thread matches above, loose matches on Subject: below --
2013-06-18  3:48 [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol Alan Reiner
2013-06-19 12:19 ` Melvin Carvalho
2013-06-19 13:37   ` Alan Reiner
2013-06-19 13:54 ` Pieter Wuille
2013-06-19 14:25 ` Timo Hanke
2013-06-19 14:39   ` Alan Reiner
2013-06-19 15:28     ` Adam Back
2013-06-19 18:36       ` Adam Back
2013-06-19 19:00         ` Alan Reiner
2013-06-20  7:48       ` Timo Hanke
2013-06-20  9:10         ` Jeremy Spilman
2013-06-20 16:09           ` Alan Reiner
2013-06-19 20:03     ` Timo Hanke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox