[Bitcoin-development] Merge avoidance and P2P connection encryption

[Bitcoin-development] Merge avoidance and P2P connection encryption

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 921 bytes --]

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

[Paul Rabahy]

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3748 bytes --]

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3677 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5198 bytes --]

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

[Gavin Andresen]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Fri, Dec 13, 2013 at 4:24 AM, Mike Hearn <mike@plan99.net> wrote:

> 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.
>

Why would there be an iteration count? The payer would handle that,
wouldn't they?

If the use case is:  I give the Foundation a "here's where to pay my
salary" PaymentRequest, maybe with several Outputs each having a different
xpubkey, then it seems to me the Foundation's wallet software should take
care of iterating.

(either saving state, so it knows it used xpubkey+10 last month and should
use xpubkey+11 this month, or maybe it knows I'm paid monthly and just uses
xpubkey+(number_of_months_from_date_in_original_payment_request).

-- 
--
Gavin Andresen

[-- Attachment #2: Type: text/html, Size: 1318 bytes --]

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

[Jeff Garzik]

On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> If the use case is:  I give the Foundation a "here's where to pay my salary"
> PaymentRequest, maybe with several Outputs each having a different xpubkey,
> then it seems to me the Foundation's wallet software should take care of
> iterating.

Absolutely.  This is a key address-non-reuse case we really need to
solve.  Miner payouts, BitPay salary payouts, etc. all use a
statically provided, manually changed address.

Rotating through multiple outputs is a stopgap -- but IMO a useful
one.  HD wallets will solve this in a better way, but existing randkey
systems will be around for a long time.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

So, vendors hat on, what would it take for, say, BitPay to implement merge avoidance and coinjoin together?

At the dark wallet hackathon when we were talking usability we decided that the main way to get coinjoin working well is to take advantage of non-time-critical payments to act as counterparties to time-critical payments. For instance BitPay could schedule a vendor payment to happen in full by some time in the future, say 1 day, and send the funds in one or more joins. The actual amounts sent in each tx are then picked to match the amounts desired by the counterparty who needs funds sent right now.

We expect this to be first implemented just as a "anonymize my coins" button for wallet software on always on machines; getting vendors on board would be gravy.

We may even allow joins to happen when one party pays less fees than the other, although this is tricky: the main Sybil resistance of coinjoin is fees so you don't want to overdo it. OTOH the idea of the NSA and Chinese equivalent wasting money completing each others joins is hilarious...


Jeff Garzik <jgarzik@bitpay.com> wrote:
>On Thu, Dec 12, 2013 at 7:20 PM, Gavin Andresen
><gavinandresen@gmail.com> wrote:
>> If the use case is:  I give the Foundation a "here's where to pay my
>salary"
>> PaymentRequest, maybe with several Outputs each having a different
>xpubkey,
>> then it seems to me the Foundation's wallet software should take care
>of
>> iterating.
>
>Absolutely.  This is a key address-non-reuse case we really need to
>solve.  Miner payouts, BitPay salary payouts, etc. all use a
>statically provided, manually changed address.
>
>Rotating through multiple outputs is a stopgap -- but IMO a useful
>one.  HD wallets will solve this in a better way, but existing randkey
>systems will be around for a long time.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9

iQFQBAEBCAA6BQJSqxz9MxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhTMBB/9L8h5NuSHxsC6W5ptm
gucxg2AbCwReuWQzRzqW42TYKQ7MnAhpfLLbSQrewNoXRP4H/j6aG8uWOt+z7fZf
pJZ9K8kxmSltHm8SJcmPLTb62yazEKQXF5TDsdpgBdH14M/pFsjUR4H2hypW8k4T
gcEAIhymZvlXev1NXDMh6rbuw0LtRTBE4NgE2buCuFzp0sEwTNTLxMU1WenMXfRQ
PooSBn8UoAVNw7Vztnag0T0f5D45VFNJBvQ8m42ee0u3gvMCa4JNRTBM49N2U9qc
Gk6WAvDakOf7FwaJiNMYoDpGyWphx6g697j28NnfB2q2hdjUVnZF+UVuBzkjnNwD
Y40/
=4dxZ
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

>
> Why would there be an iteration count? The payer would handle that,
> wouldn't they?
>

I'm thinking about a use case I hope will become common next year -
pastebin style hosting sites for payment requests. Like, if I as a regular
end user wish to use the payment protocol, I could just upload a (possibly
signed) payment request to:

payr.com/a62gahZ

or whatever, and then payr.com can take care of incrementing the iteration
count on each download of my file. That's why it's useful for it to be
unsigned.


> If the use case is:  I give the Foundation a "here's where to pay my
> salary" PaymentRequest, maybe with several Outputs each having a different
> xpubkey, then it seems to me the Foundation's wallet software should take
> care of iterating.
>

Absolutely. The two use cases can both be supported. You could give
iteration ranges, for instance, if you want to specify expiry in terms of
number of payments rather than time.

[-- Attachment #2: Type: text/html, Size: 1749 bytes --]

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

[Mark Friedenbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/13/2013 09:26 AM, Mike Hearn wrote:
> I'm thinking about a use case I hope will become common next year
> - pastebin style hosting sites for payment requests. Like, if I as
> a regular end user wish to use the payment protocol, I could just
> upload a (possibly signed) payment request to:
> 
> payr.com/a62gahZ <http://payr.com/a62gahZ>
> 
> or whatever, and then payr.com <http://payr.com> can take care of 
> incrementing the iteration count on each download of my file.
> That's why it's useful for it to be unsigned.

Or alternatively, the user-signed payment request without iteration
count is enclosed within a payr.com-signed envelope that contains the
iteration count. Having fields completely unsigned by anybody leaves
me a little nervous.

Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSq12pAAoJEAdzVfsmodw4MC4QAI9cjmQXz8AVawwr1htFc6b+
DVAAs1Y4hzbChPeeJCmy13m8a/BuXqc6G0WEWGSzIIa1or3IXCd01JQ2a5waD0IC
uOjlIMD0tTT7yxwxRjxPc2df82s82traGJC2caOMYjrN4T5VPtj7erB2poNyvOF+
p0lmj+duxUZ8IoyDaih5mgNKzIVujfX7o3lPoOMDdIi6Q1LF9SZ9XbUAxHCpCLfw
ieqVIm8zqtH0NprZ7/JLbqstl1iq5jCPKbORc+9qQWESZH1hFAeS29/ptjnRR8y6
HqrpDP236vSlrLDW4dLcW9UiQP42tSTwrLCgud08VqeKapSlMX8fjukLyNlTD7h5
GtPHEo1/j+LmpMfwsXA2OotUIVQBeFfEoi7PwV/Jd+SRVqC6zCTPky1lfg0P7JXA
7qD9m3u/Ey0+nk888zzff8N7AfBe7GaqFuUByXIyHh6dkcr0xUHBU4afiadFpNhg
8dTvmP4yqY0g05uz/Cq/ZqrSb5y/yPqsysuruAjWG2GT0M8rFM9oYepVHpUJr01K
QOHY6qSoqyX/KDCkZgpTMZFDq9gvyPyMFuCQbdecNcCeMPV5kiwPyqqH4rHliJ8I
gsXW44re5GfdL90nCOTboYFf2CFEn+66zyJ5vBskKSyDRDcU3t5YyCtrDzXdtJMu
MjVeMFRluY700zLBajw0
=+MjP
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

>
> Or alternatively, the user-signed payment request without iteration
> count is enclosed within a payr.com-signed envelope that contains the
> iteration count.


But how does that show up in the user interface? I don't know how you would
explain what the signature means or implies, or what you do if the
signature is broken/missing.

The only thing that a maliciously modified iteration count can do is cause
money to be sent to an address that's beyond the recipients gap limit,
meaning they won't receive it (unless they reconfigure their software and
rescan). But you can't steal money that way.

[-- Attachment #2: Type: text/html, Size: 873 bytes --]