Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UpO4I-0000gW-EJ for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 19:29:22 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co designates 50.117.27.232 as permitted sender) client-ip=50.117.27.232; envelope-from=jeremy@taplink.co; helo=mail.taplink.co; Received: from mail.taplink.co ([50.117.27.232]) by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1UpO4H-000207-38 for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 19:29:22 +0000 Received: from LAPTOPAIR ([192.168.168.158]) by mail.taplink.co ; Wed, 19 Jun 2013 12:29:42 -0700 Message-ID: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR> From: "Jeremy Spilman" To: "Bitcoin Dev" Date: Wed, 19 Jun 2013 12:29:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F1D_01CE6CE8.9EFF3160" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 oclient: 192.168.168.158#jeremy@taplink.co#465 X-Spam-Score: -1.9 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1UpO4H-000207-38 Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 19:29:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0F1D_01CE6CE8.9EFF3160 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99t 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 =E2=80=9Ccontact=E2=80=9D 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=E2=80=99s sequence = are attributed to that contact. The wallet can organize the contacts, = and roll-up the transaction history into =E2=80=98ledgers=E2=80=99 and = =E2=80=98balances=E2=80=99 however they want =E2=80=93 it could be based = on the underlying BIP32 hierarchy or perhaps not. The cost of watching = large a number of pubkeys, even if you =E2=80=98look ahead=E2=80=99 100 = pubkeys for each contact, is relatively small versus the benefits. What might be nice is a =E2=80=98Contact Request=E2=80=99 protocol, = basically the same as a PaymentRequest but no actual payments are sent, = just child wallets created: message Contact { optional uint32 contact_version =3D 1 [default =3D 1]; optional string pki_type =3D 2 [default =3D "none"]; optional bytes pki_data =3D 3; required bytes serialized_contact_details =3D 4; optional bytes signature =3D 5; } message ContactDetails { optional string network =3D 1 [default =3D "main"]; required bytes pubkey =3D 2; required bytes chaincode =3D 3; optional string memo =3D 4; optional string response_url =3D 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 ------=_NextPart_000_0F1D_01CE6CE8.9EFF3160 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If=20 you have two parties who want to form a persistent relationship, by = exchanging=20 and verifying public keys beforehand, then I think the canonical way to = do this=20 with BIP32 is for the parties to exchange PubKey and *ChainCode*.
 
I don=E2=80=99t understand the use case for handing out individual = multipliers, if=20 what you desire is a persistent relationship. If each party dedicates a=20 child-wallet for receiving coins, and saves a PubKey/ChainCode for = sending=20 coins, the two parties can transaction securely forever without ever = exchanging=20 any more information, and without any address reuse.
 
I think ideally, the default behavior is that wallets always = dedicate a new=20 child node {PubKey, ChainCode} to each party they transact with. At the=20 presentation layer, you have a =E2=80=9Ccontact=E2=80=9D and each = contact has a transaction=20 history. You can send coins to a contact at any time, and internally the = wallet=20 picks the next address in their sequence. Any funds received on pubkeys = from=20 contact=E2=80=99s sequence are attributed to that contact. The wallet = can organize the=20 contacts, and roll-up the transaction history into = =E2=80=98ledgers=E2=80=99 and =E2=80=98balances=E2=80=99=20 however they want =E2=80=93 it could be based on the underlying BIP32 = hierarchy or=20 perhaps not. The cost of watching large a number of pubkeys, even if you = =E2=80=98look=20 ahead=E2=80=99 100 pubkeys for each contact, is relatively small versus = the=20 benefits.
 
What might be nice is a =E2=80=98Contact Request=E2=80=99 protocol, = basically the same as a=20 PaymentRequest but no actual payments are sent, just child wallets=20 created:
 
message Contact {
    optional uint32 contact_version =3D 1 [default = =3D 1];
    optional string pki_type =3D 2 [default =3D = "none"];
    optional bytes pki_data =3D 3;
    required bytes serialized_contact_details =3D = 4;
    optional bytes signature =3D 5;
}
 
message ContactDetails {
    optional string network =3D 1 [default =3D = "main"];
    required bytes pubkey =3D 2;
    required bytes chaincode =3D 3;
    optional string memo =3D 4;
    optional string response_url =3D 5;
}
 
Alice sends a Contact+ContactDetails to Bob.  If Bob accepts, = he sends=20 his own Contact+ContactDetails (without a response_url) back to Alice. = Basically=20 just like adding a contact to your IM contacts.
 
Alice could send a Contact+ContactDetails to Bob without a = response_url, in=20 which case after accepting the contact, Bob could send funds to Alice, = but not=20 receive funds.
 
You could probably pack the whole message inside a bitcoin:// URI = if you=20 wanted to.
 
Thanks,
--Jeremy
------=_NextPart_000_0F1D_01CE6CE8.9EFF3160--