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; 
Message-ID: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
From: "Jeremy Spilman" <jeremy@taplink.co>
To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>
Date: Wed, 19 Jun 2013 12:29:19 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0F1D_01CE6CE8.9EFF3160"
Importance: Normal
oclient: 192.168.168.158#jeremy@taplink.co#465
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format
 - Payment Protocol
Precedence: list

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

<HTML><HEAD>
<META content=3D"text/html; charset=3DISO-8859-1" =
http-equiv=3Dcontent-type></HEAD>
<BODY dir=3Dltr bgColor=3D#ffffff text=3D#000000>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>
<DIV=20
style=3D"FONT-SIZE: small; FONT-FAMILY: 'Calibri'; FONT-WEIGHT: normal; =
COLOR: #000000; FONT-STYLE: normal; TEXT-DECORATION: none; DISPLAY: =
inline">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*.</DIV>
<DIV dir=3Dltr>
<DIV style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Calibri'; COLOR: #000000">
<DIV>&nbsp;</DIV>
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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:</DIV>
<DIV>&nbsp;</DIV>
<DIV>message Contact {</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional uint32 contact_version =3D 1 [default =
=3D 1];</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional string pki_type =3D 2 [default =3D =
"none"];</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional bytes pki_data =3D 3;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; required bytes serialized_contact_details =3D =
4;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional bytes signature =3D 5;</DIV>
<DIV>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>message ContactDetails {</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional string network =3D 1 [default =3D =
"main"];</DIV>
<DIV>&nbsp;&nbsp;&nbsp; required bytes pubkey =3D 2;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; required bytes chaincode =3D 3;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional string memo =3D 4;</DIV>
<DIV>&nbsp;&nbsp;&nbsp; optional string response_url =3D 5;</DIV>
<DIV>}</DIV>
<DIV>&nbsp;</DIV>
<DIV>Alice sends a Contact+ContactDetails to Bob.&nbsp; 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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>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.</DIV>
<DIV>&nbsp;</DIV>
<DIV>You could probably pack the whole message inside a bitcoin:// URI =
if you=20
wanted to.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>--Jeremy</DIV></DIV></DIV></DIV></DIV></DIV></BODY></HTML>

------=_NextPart_000_0F1D_01CE6CE8.9EFF3160--