From: Gregory Maxwell <gmaxwell@gmail•com>
To: Justus Ranvier <justus.ranvier@monetas•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Reusable payment codes
Date: Fri, 24 Apr 2015 20:58:39 +0000 [thread overview]
Message-ID: <CAAS2fgRVcwNfYv8fnoS_uRtDoGqRiWAXcPgaK8if8FO_G6LQoQ@mail.gmail.com> (raw)
In-Reply-To: <CAHabJ+Mn0=vfLvTJ+z3tx8cFAAuLD1pLp4rOe3pM6MtCrCxjwg@mail.gmail.com>
On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier
<justus.ranvier@monetas•net> wrote:
> https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
>
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
>
> Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
> addresses which provide useful features such as positively identifying
> senders to recipients and automatically providing for transaction refunds.
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.
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.)
> Alice selects the first exposed public key of the first input of the transaction
So this creates strong "binding" that we would really strongly like to
avoid in the network; basically what this says is that "You can only
pay to person X if you use scheme Y for your own Bitcoins"-- who says
any of your inputs have a ECDH pubkey at all? Of if they do, who says
its one that you have access to the private key for for use in this
scheme (e.g. it could be in a HSM that only signs according to a
policy). We should avoid creating txout features that restrict what
kind of scriptPubkey the sender can use, or otherwise we'll never be
able to deploy new signature features. (We can see how long P2SH took
to gain adoption because some wallets refused to implement sending to
it, even though doing so was trivial).
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)
Also, SPV wallets do not need to have access to the public keys being
spent by a particular transaction they learn about; providing that
access is fundamentally expensive and pushes things back towards
centralization.
> in uncompressed DER format
This is fundamentally more expensive to compute; please don't specify
"uncompressed".
This appears incompatible with multisignature; which is unfortunate.
I do very much like the fact that this scheme establishes a shared
chain once and then doesn't need to reestablish; this was one of the
improvements I wanted for the stealth address.
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?
next prev parent reply other threads:[~2015-04-24 20:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 20:00 Justus Ranvier
2015-04-24 20:58 ` Gregory Maxwell [this message]
[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
[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
2015-04-27 14:53 Brian Deery
2015-04-27 15:54 ` Justus Ranvier
2015-04-27 16:46 ` Mike Hearn
2015-04-27 17:02 ` Justus Ranvier
2015-04-28 13:53 ` Justus Ranvier
2015-04-29 23:44 ` Justus Ranvier
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=CAAS2fgRVcwNfYv8fnoS_uRtDoGqRiWAXcPgaK8if8FO_G6LQoQ@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=justus.ranvier@monetas$(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