path: root/07/ef6f24f51f8156b303e400f240db460fb925a3

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1VrAwQ-0007Oa-DF
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Dec 2013 18:24:54 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.178 as permitted sender)
	client-ip=209.85.214.178; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f178.google.com; 
Received: from mail-ob0-f178.google.com ([209.85.214.178])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VrAwO-000360-Ex
	for bitcoin-development@lists.sourceforge.net;
	Thu, 12 Dec 2013 18:24:54 +0000
Received: by mail-ob0-f178.google.com with SMTP id uz6so833469obc.37
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 12 Dec 2013 10:24:47 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.51.161 with SMTP id l1mr1390467oeo.69.1386872687016; Thu,
	12 Dec 2013 10:24:47 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.92.72 with HTTP; Thu, 12 Dec 2013 10:24:46 -0800 (PST)
In-Reply-To: <CADu7o8MXuUVrRP0vsvEkPLJ4f=2pC6V7W3hYE0jCVDRKmvqu8A@mail.gmail.com>
References: <CANEZrP1gDxcKO8z4hgM9BJU6-+Ft0oaiCZjqjN4MxGEJCgs5Ng@mail.gmail.com>
	<CADu7o8MXuUVrRP0vsvEkPLJ4f=2pC6V7W3hYE0jCVDRKmvqu8A@mail.gmail.com>
Date: Thu, 12 Dec 2013 10:24:46 -0800
X-Google-Sender-Auth: XpUUmB9HabKsX-tofoZ40Bsa5yw
Message-ID: <CANEZrP33bRx6abbXcf6nQYiPXFOOWSsZJqiFZY+A08x6O3X+pg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Paul Rabahy <prabahy@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2f3ecdbc17b04ed5a755f
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: doubleclick.net]
	-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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1VrAwO-000360-Ex
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Merge avoidance and P2P connection
	encryption
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: Thu, 12 Dec 2013 18:24:54 -0000

--001a11c2f3ecdbc17b04ed5a755f
Content-Type: text/plain; charset=UTF-8

I think the right way to integrate BIP32 and BIP70 would be to specify
output scripts as normal for backwards compatibility, and then allow each
output to have an additional xpubkey and iteration count field. The
iteration counts could be unsigned.

Unfortunately to add data that isn't signed requires a backwards
incompatible change to the protocol :( There isn't currently any area that
isn't covered by the signature. We would have to add one, and then have a
matching array of iteration counts for each xpubkey that was specified in
the output.

I wonder if we should make a last minute change to BIP70 before wallets
have shipped and merchant support starts, something like

message PaymentRequest {
  optional byte unsigned_data = 6;
}

that would be deleted like the signature is before reserialization.



On Thu, Dec 12, 2013 at 9:28 AM, Paul Rabahy <prabahy@gmail.com> wrote:

> First off, nice article. Very clear and informative.
>
> I don't know if this is the best place to post this, but it seems related
> to me.
>
> As more wallets implement BIP32, I believe that bitcoin wallets should
> begin to encourage people to use
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-mi0style address instead of traditional addresses. In the end, this would
> improve privacy because users never need to merge coin if they had one of
> these "super addresses".
>
> In addition, "super addresses" would fit nicely into BIP70. Right now, the
> PaymentDetails message allows the merchant to provide multiple outputs. If
> instead the PaymentDetails provide 1 traditional output (for reverse
> compatibility) and 1 "super address", the payment could be broken into as
> many pieces as is needed to match unspent outputs already in the customers
> wallet. Finally, the refund_to address in Payment could also be upgraded to
> a "super address" to enhance privacy there.
>
> I am not sure if there is a large memory requirement for "super
> addresses", but to me, it seems that a lot of these privacy enhancing
> possibilities will be simple to implement once BIP32 is widely deployed.
>
>
> On Thu, Dec 12, 2013 at 11:03 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> I wrote an article intended for a broad/non-developer audience on a few
>> Bitcoin privacy topics:
>>
>> - P2P connection encryption
>> - Address re-use/payment protocol
>> - CoinJoin and merge avoidance
>>
>> I don't think there's anything much new here for people who were involved
>> with the BIP70 design discussions, but it may prove a useful resource when
>> talking about privacy features in the payment protocol. Specifically the
>> ability to request multiple outputs and submit multiple transactions that
>> satisfy them. The article elaborates on how to use that feature to achieve
>> some useful privacy outcomes.
>>
>> I also analyze what using SSL for P2P connections would buy us and what
>> it wouldn't.
>>
>> https://medium.com/p/7f95a386692f
>>
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

--001a11c2f3ecdbc17b04ed5a755f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think the right way to integrate BIP32 and BIP70 would b=
e to specify output scripts as normal for backwards compatibility, and then=
 allow each output to have an additional xpubkey and iteration count field.=
 The iteration counts could be unsigned.<div>
<br></div><div>Unfortunately to add data that isn&#39;t signed requires a b=
ackwards incompatible change to the protocol :( There isn&#39;t currently a=
ny area that isn&#39;t covered by the signature. We would have to add one, =
and then have a matching array of iteration counts for each xpubkey that wa=
s specified in the output.</div>
<div><br></div><div>I wonder if we should make a last minute change to BIP7=
0 before wallets have shipped and merchant support starts, something like</=
div><div><br></div><div>message PaymentRequest {</div><div>=C2=A0 optional =
byte unsigned_data =3D 6;</div>
<div>}</div><div><br></div><div>that would be deleted like the signature is=
 before reserialization.</div><div><br></div></div><div class=3D"gmail_extr=
a"><br><br><div class=3D"gmail_quote">On Thu, Dec 12, 2013 at 9:28 AM, Paul=
 Rabahy <span dir=3D"ltr">&lt;<a href=3D"mailto:prabahy@gmail.com" target=
=3D"_blank">prabahy@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>First off, nice articl=
e. Very clear and informative.<br><br>I don&#39;t know if this is the best =
place to post this, but it seems related to me.<br>
<br>As more wallets implement BIP32, I believe that bitcoin wallets should =
begin to encourage people to use <a href=3D"https://github.com/bitcoin/bips=
/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions=
-mi0" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-003=
2.mediawiki#recurrent-business-to-business-transactions-mi0</a> style addre=
ss instead of traditional addresses. In the end, this would improve privacy=
 because users never need to merge coin if they had one of these &quot;supe=
r addresses&quot;.<br>


<br>In addition, &quot;super addresses&quot; would fit nicely into BIP70. R=
ight now, the PaymentDetails message allows the merchant to provide multipl=
e outputs. If instead the PaymentDetails provide 1 traditional output (for =
reverse compatibility) and 1 &quot;super address&quot;, the payment could b=
e broken into as many pieces as is needed to match unspent outputs already =
in the customers wallet. Finally, the refund_to address in Payment could al=
so be upgraded to a &quot;super address&quot; to enhance privacy there.<br>


<br></div>I am not sure if there is a large memory requirement for &quot;su=
per addresses&quot;, but to me, it seems that a lot of these privacy enhanc=
ing possibilities will be simple to implement once BIP32 is widely deployed=
.<br>


</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><d=
iv class=3D"h5">On Thu, Dec 12, 2013 at 11:03 AM, Mike Hearn <span dir=3D"l=
tr">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.ne=
t</a>&gt;</span> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">

<div dir=3D"ltr">I wrote an article intended for a broad/non-developer audi=
ence on a few Bitcoin privacy topics:<div><br></div><div>- P2P connection e=
ncryption</div><div>- Address re-use/payment protocol</div><div>- CoinJoin =
and merge avoidance</div>



<div><br></div><div>I don&#39;t think there&#39;s anything much new here fo=
r people who were involved with the BIP70 design discussions, but it may pr=
ove a useful resource when talking about privacy features in the payment pr=
otocol. Specifically the ability to request multiple outputs and submit mul=
tiple transactions that satisfy them. The article elaborates on how to use =
that feature to achieve some useful privacy outcomes.</div>



<div><br></div><div>I also analyze what using SSL for P2P connections would=
 buy us and what it wouldn&#39;t.</div><div><br></div><div><a href=3D"https=
://medium.com/p/7f95a386692f" target=3D"_blank">https://medium.com/p/7f95a3=
86692f</a><br>


</div>
</div>
<br></div></div>-----------------------------------------------------------=
-------------------<br>
Rapidly troubleshoot problems before they affect your business. Most IT<br>
organizations don&#39;t have a clear picture of how application performance=
<br>
affects their revenue. With AppDynamics, you get 100% visibility into your<=
br>
Java,.NET, &amp; PHP application. Start your 15-day FREE TRIAL of AppDynami=
cs Pro!<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D84349831&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D84349831&amp;iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>



Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>

--001a11c2f3ecdbc17b04ed5a755f--