public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Justus Ranvier <justus.ranvier@monetas.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Fwd:  Reusable payment codes
Date: Sat, 25 Apr 2015 02:21:20 +0200	[thread overview]
Message-ID: <CAHabJ+N1acagTJ_-P=BJ_5unHU6ywNZK+wNzZJzTmyFdZ4AMrQ@mail.gmail.com> (raw)
In-Reply-To: <CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@mail.gmail.com>

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

I have pushed an updated version of the proposal which incorporates some of
the received feedback and adds a note about the consequences of sharing a
payment code-enabled walled on multiple devices:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki

https://github.com/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521

On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier <justus.ranvier@monetas.net
> wrote:

>
>
> On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
>
>> So this requires making dust payments to a constantly reused address
>> in order to (ab)use the blockchain as a messaging layer.
>>
>> Indeed, this is more SPV compatible; but it seems likely to me that
>> _in practice_ it would almost completely undermine the privacy the
>> idea hoped to provide; because you'd have an observable linkage to a
>> highly reused address.
>>
>
> I agree that the output associated with notification transactions would
> require special handling to avoid privacy leaks. At a minimum they'd
> require mixing or being donated to miners as a transaction fee.
>
>
>>
>> It would also more than double the data sent for the application where
>> 'stealth addresses' are most important: one-time anonymous donations
>> (in other contexts; you have two way communication between the
>> participants, and so you can just given them a one off address without
>> singling in the public network.)
>>
>
> Communication is only one way, except for the case in which the recipient
> wants to send a refund. Assuming no refund and only a single anonymous
> donation in the lifetime of the sender's identity, payment codes would
> require 65 bytes vs 40 bytes for stealth addresses.
>
> As soon as the sender sends more than one donation to the same recipient,
> payment codes show an space advantage over stealth addresses.
>
> This kind of binding was intentionally designed out of the stealth
>>
> address proposal;  I think this scheme can be made to work without any
>> increase in size by reusing the payment code as the ephemeral public
>> key (or actually being substantially smaller e.g. use the shared
>> secret as the chain code, but I should give it more thought)
>>
>
> With 97 byte standard OP_RETURN values the ephemeral public
> key could be appended to the chain code, but that's undesirable for other
> reasons.
>
> This is fundamentally more expensive to compute; please don't specify
>> "uncompressed".
>>
>
> Taking the SHA512 of something less than 512 bits seemed wrong.
>
>
>> This appears incompatible with multisignature; which is unfortunate.
>>
>
> I agree. I could not find a straightforward way to express a
> multisignature payment code in less than 80 bytes.
>
>
>> I'm disappointed that there isn't any thought given to solving the
>> scanning privacy without forcing non-private pure-overhead messaging
>> transactions on heavily reused addresses. Are you aware of the IBE
>> approach that allows someone to request a third party scan for them
>> with block by block control over their delegation of scanning?
>>
>
> I suspect this is a case where we just can't have all the features we want.
>
> In this proposal I optimized for non-reliance on third party services and
> a guaranteed ability to recover spendable funds from a seed backup.
>
> Gaining those two features resulted in some tradeoffs as you noted, but I
> think there are enough benefits to make them worthwhile.
>
> In particular, payment codes could be the basis for a Heartbleed-free
> payment protocol that can positively identify customers and automatically
> provide refund capabilities in a merchant-customer relationship. A merchant
> only requires one payment code which they can safely use for all their
> customers, meaning they only ever need to associate 65 bytes with their
> identity to allow customers to make sure they are paying the right entity.
>
> Exchanges could restrict bitcoin withdrawals to a single payment code
> known to be associated with their identified customer. This would make
> thefts easier (without involving address reuse as in locking withdrawals to
> a single P2PKH address).
>
> In some jurisdictions the ability to prove that withdrawals are sent to a
> positively-identified party, rather than arbitrary third parties, might
> move some Bitcoin businesses out of money transmitter territory into less
> onerous regulatory situations.
>
>

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

  parent reply	other threads:[~2015-04-25  0:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 20:00 [Bitcoin-development] Reusable payment codes Justus Ranvier
2015-04-24 20:58 ` Gregory Maxwell
     [not found]   ` <CAHabJ+MtWJS=e3tkGih=xoP4ARgHe8X=D_p9OWTnRJi0z9epBw@mail.gmail.com>
2015-04-25  0:20     ` [Bitcoin-development] Fwd: " Justus Ranvier
     [not found]     ` <CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@mail.gmail.com>
2015-04-25  0:21       ` Justus Ranvier [this message]
     [not found] ` <1AE7B0A2-90EE-42EE-9D30-4DC1B5892E53@newcastle.ac.uk>
     [not found]   ` <CAHabJ+NDqMN-rQ1BN1TfOjGLQHH-3Wd28LdoF95Agn4HdRrThg@mail.gmail.com>
2015-04-25  0:22     ` Justus Ranvier
     [not found]       ` <CAAS2fgSAT2otym64oUACpWD8jWLAB6dBusONn-WUx2DK59SB5w@mail.gmail.com>
2015-04-25  2:34         ` Justus Ranvier
2015-04-26 12:58           ` Mike Hearn
2015-04-26 14:50             ` Justus Ranvier
2015-06-16 16:26 ` [Bitcoin-development] " odinn
2015-06-16 17:46   ` Peter Todd
2015-06-17  5:34     ` odinn

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='CAHabJ+N1acagTJ_-P=BJ_5unHU6ywNZK+wNzZJzTmyFdZ4AMrQ@mail.gmail.com' \
    --to=justus.ranvier@monetas.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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