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 --]
next prev 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] " 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$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.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