path: root/b0/07a07ffecbcda4c7b77fced3b6be38712243d2

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1UomuP-0007LW-EO
	for bitcoin-development@lists.sourceforge.net;
	Tue, 18 Jun 2013 03:48:41 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.170 as permitted sender)
	client-ip=209.85.223.170; envelope-from=etotheipi@gmail.com;
	helo=mail-ie0-f170.google.com; 
Received: from mail-ie0-f170.google.com ([209.85.223.170])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1UomuK-0007xU-U6
	for bitcoin-development@lists.sourceforge.net;
	Tue, 18 Jun 2013 03:48:41 +0000
Received: by mail-ie0-f170.google.com with SMTP id e11so8922077iej.15
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 17 Jun 2013 20:48:31 -0700 (PDT)
X-Received: by 10.50.57.48 with SMTP id f16mr6438357igq.72.1371527311637;
	Mon, 17 Jun 2013 20:48:31 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
	[76.111.96.126]) by mx.google.com with ESMTPSA id
	ie16sm20453162igb.4.2013.06.17.20.48.28
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 17 Jun 2013 20:48:29 -0700 (PDT)
Message-ID: <51BFD886.8000701@gmail.com>
Date: Mon, 17 Jun 2013 23:48:22 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
	boundary="------------060600080401050209080308"
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(etotheipi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	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: 1UomuK-0007xU-U6
Subject: [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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 03:48:41 -0000

This is a multi-part message in MIME format.
--------------060600080401050209080308
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

_*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





--------------060600080401050209080308
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <u><b>Goal</b></u>:&nbsp; 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.&nbsp;&nbsp; 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.&nbsp;&nbsp;&nbsp; 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.<br>
    <br>
    <u><b>Background</b></u><u>:</u><br>
    I haven't been following the payment protocol
    discussions/development much, so I apologize if this has already
    been addressed.&nbsp;&nbsp; I'm calling it "wallet-linkable" addresses, which
    would be an optional second form for sending someone your address.&nbsp;&nbsp;
    With BIP 32, the address is computed by the payee (the person
    sending the address to receive money):<br>
    <br>
    &nbsp;&nbsp; Standard Address ~ Base58(0x00 || hash160(<font color="#3333ff">PubKeyParent
      * Multiplier[i]</font>) || checksum)<br>
    <br>
    What I'd like to do is have the option, when specifying an address
    through the payment protocol, to send *just* the {<font
      color="#3333ff">PublicKeyParent, Multiplier[i]</font>} and let the
    receiver of that address compute the address on their own.&nbsp; 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.&nbsp; Remember, this is <u>optional</u> for the person
    providing the address.<br>
    <br>
    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").&nbsp;&nbsp; It is derived from the chaincode
    but doesn't reveal it.&nbsp; 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.&nbsp; But they can verify that the
    PublicKeyParent is identical between transactions, and thus is
    accessible only to that wallet.&nbsp; It allows them validate a specific
    address provided by the payee, but not generate or identify any
    other addresses.<br>
    <br>
    <b><u>Use Cases:</u></b><br>
    (1)&nbsp; 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.&nbsp; 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.&nbsp; If the payee's system
    is compromised and address is replaced, the address received by the
    payer won't validate.&nbsp; This doesn't help if the side sending the
    money is compromised.<br>
    <br>
    (2)&nbsp; 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}.&nbsp; 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.&nbsp; 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.&nbsp;
    <br>
    <br>
    <br>
    <u><b>Downsides:</b></u>&nbsp; <br>
    Multi-sig/P2SH&nbsp; - 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.&nbsp; Instead of providing a 20-byte hash
    of a script, you provide all the public keys and multipliers for the
    individual addresses.&nbsp; 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).&nbsp; 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.&nbsp; But it may not <i>really</i> be a problem, given
    the benefits.&nbsp; It might just be slightly longer strings to exchange
    during initialization and for each transaction.<br>
    <br>
    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.<br>
    <br>
    -Alan<br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------060600080401050209080308--