From: Paul Rabahy <prabahy@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Merge avoidance and P2P connection encryption
Date: Thu, 12 Dec 2013 12:28:32 -0500 [thread overview]
Message-ID: <CADu7o8MXuUVrRP0vsvEkPLJ4f=2pC6V7W3hYE0jCVDRKmvqu8A@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1gDxcKO8z4hgM9BJU6-+Ft0oaiCZjqjN4MxGEJCgs5Ng@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2013-12-12 17:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-12 16:03 Mike Hearn
2013-12-12 17:28 ` Paul Rabahy [this message]
2013-12-12 18:24 ` Mike Hearn
2013-12-13 0:20 ` Gavin Andresen
2013-12-13 0:26 ` Jeff Garzik
2013-12-13 14:43 ` Peter Todd
2013-12-13 17:26 ` Mike Hearn
2013-12-13 19:19 ` Mark Friedenbach
2013-12-13 21:49 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADu7o8MXuUVrRP0vsvEkPLJ4f=2pC6V7W3hYE0jCVDRKmvqu8A@mail.gmail.com' \
--to=prabahy@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox