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:20:59 +0200 [thread overview]
Message-ID: <CAHabJ+PWRUYEO8mY68kH_wy5iozx0JQG1N_aQhUWcvnMR36A+A@mail.gmail.com> (raw)
In-Reply-To: <CAHabJ+MtWJS=e3tkGih=xoP4ARgHe8X=D_p9OWTnRJi0z9epBw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]
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: 5865 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 ` Justus Ranvier [this message]
[not found] ` <CAHabJ+Oabx80+_1KutfrPUt5QEnMivfNeeh4uJJJOsiHRQqSZw@mail.gmail.com>
2015-04-25 0:21 ` [Bitcoin-development] Fwd: " Justus Ranvier
[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+PWRUYEO8mY68kH_wy5iozx0JQG1N_aQhUWcvnMR36A+A@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