From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UpHMb-0000po-7g for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 12:19:49 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.44 as permitted sender) client-ip=209.85.215.44; envelope-from=melvincarvalho@gmail.com; helo=mail-la0-f44.google.com; Received: from mail-la0-f44.google.com ([209.85.215.44]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UpHMZ-0006ZO-NP for bitcoin-development@lists.sourceforge.net; Wed, 19 Jun 2013 12:19:49 +0000 Received: by mail-la0-f44.google.com with SMTP id er20so4609483lab.17 for ; Wed, 19 Jun 2013 05:19:41 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.29.227 with SMTP id n3mr1232780lah.43.1371644380941; Wed, 19 Jun 2013 05:19:40 -0700 (PDT) Received: by 10.112.2.8 with HTTP; Wed, 19 Jun 2013 05:19:40 -0700 (PDT) In-Reply-To: <51BFD886.8000701@gmail.com> References: <51BFD886.8000701@gmail.com> Date: Wed, 19 Jun 2013 14:19:40 +0200 Message-ID: From: Melvin Carvalho To: Alan Reiner Content-Type: multipart/alternative; boundary=089e0158c76c15965504df80d8df 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 (melvincarvalho[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: 1UpHMZ-0006ZO-NP Cc: Bitcoin Dev 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 12:19:49 -0000 --089e0158c76c15965504df80d8df Content-Type: text/plain; charset=ISO-8859-1 On 18 June 2013 05:48, Alan Reiner wrote: > *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. > Generally in favour of hierarchical deterministic wallets. Will this new style of address make it into the block chain? I'd be less keen on that. I'm finding BIP0032 quite hard to read right now, but perhaps that's because I'm less familiar with the material than some. However, there's little things like it never actually defines a deterministic wallet in the Abstract. But, I'll keep trying to understand and see if I can use the test vectors. > > -Alan > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --089e0158c76c15965504df80d8df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 18 June 2013 05:48, Alan Reiner <etotheipi@gmail.com><= /span> wrote:
=20 =20 =20
Goal:=A0 An alternative address format made possible by BIP 32, which allows one to specify a "Wallet ID" and "O= ne-time payment" code, instead of the standard one-use Base58-Hash160 addresses.=A0=A0 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.=A0=A0=A0 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.=A0=A0 I'm calling it "wallet-linkable" ad= dresses, which would be an optional second form for sending someone your address.=A0= =A0 With BIP 32, the address is computed by the payee (the person sending the address to receive money):

=A0=A0 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.=A0 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.=A0 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").=A0=A0 It is derived from the= chaincode but doesn't reveal it.=A0 Therefore, the payer sees the parent publ= ic key, but that's not useful to derive any of the other addresses unless they also have the chaincode.=A0 But they can verify that the PublicKeyParent is identical between transactions, and thus is accessible only to that wallet.=A0 It allows them validate a specific address provided by the payee, but not generate or identify any other addresses.

Use Cases:
(1)=A0 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.=A0 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.=A0 If the payee's sys= tem is compromised and address is replaced, the address received by the payer won't validate.=A0 This doesn't help if the side sending = the money is compromised.

(2)=A0 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}.=A0 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.=A0 If they don't, it might be the same custo= mer 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.= =A0


Downsides:=A0
Multi-sig/P2SH=A0 - The only way this works with P2SH, violates one of the goals of P2SH slightly, but may not matter much if it's all don= e under the hood by the software.=A0 Instead of providing a 20-byte hash of a script, you provide all the public keys and multipliers for the individual addresses.=A0 The payer's software automatically verifie= s 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).=A0 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.=A0 But it may not really be a problem, given the benefits.=A0 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 t= o have some community backing, so I don't have to twist anyone's = arm to trust me that it's legit.

Generally = in favour of hierarchical deterministic wallets.

Will thi= s new style of address make it into the block chain?=A0 I'd be less kee= n on that.

I'm finding BIP0032 quite hard to read right now, but pe= rhaps that's because I'm less familiar with the material than some.= =A0 However, there's little things like it never actually defines a det= erministic wallet in the Abstract.=A0 But, I'll keep trying to understa= nd and see if I can use the test vectors.
=A0

-Alan





-----------------------------------------------------------------------= -------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.= sf.net/sfu/windows-dev2dev
_________________________________________= ______
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--089e0158c76c15965504df80d8df--