From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YlnqZ-0006k9-F8 for bitcoin-development@lists.sourceforge.net; Sat, 25 Apr 2015 00:21:27 +0000 Received: from mail-ig0-f179.google.com ([209.85.213.179]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YlnqX-0003Yb-Si for bitcoin-development@lists.sourceforge.net; Sat, 25 Apr 2015 00:21:27 +0000 Received: by igblo3 with SMTP id lo3so27325738igb.1 for ; Fri, 24 Apr 2015 17:21:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ICN5a4qrT74UN4YWD5g9WYwwSsZeq+Y1awLn1cVUN4w=; b=TCz4ZREc1BVVEPRljmDJJiDhj5ztwoFk3OqZx+vzZ6P/rLi62z/ftzj9SuRGniCcrH KTL2y2Lx1ZR8ACwzXzmcLQap6SSjfFnRUSiOYYEYLoa69RxFwsaWfvkrfAvJFxmBUGEy Khv41OLTkao0D/iiKHdTr6OR26p5//ZolzbAf5xJeu/aCyuNkOqsvtmDXDN/4acQVepx F62bbVXpDYmY0x7CJ/RzbELSxL6g1u7etJeR6U7hgZPxwLLfvyP2nq83ou+Ismoa7AoI pUKO1pdyZxbEV45tdhqHzoIbxQDLhWOg6uYO6BcZrPUBt+e6/wmN28QoOPldizjFuouw T0uQ== X-Gm-Message-State: ALoCoQnzrb63mj03u7zMof8+sVETLgvt9qQ9ucRv63bk+yrCv8jrnyYfwCYZDlbZ4cufHV0BJLoN MIME-Version: 1.0 X-Received: by 10.107.130.84 with SMTP id e81mr1197822iod.80.1429921280550; Fri, 24 Apr 2015 17:21:20 -0700 (PDT) Received: by 10.36.205.135 with HTTP; Fri, 24 Apr 2015 17:21:20 -0700 (PDT) In-Reply-To: References: Date: Sat, 25 Apr 2015 02:21:20 +0200 Message-ID: From: Justus Ranvier To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113eca2efbfddc0514817d49 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YlnqX-0003Yb-Si Subject: [Bitcoin-development] Fwd: Reusable payment codes X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 00:21:27 -0000 --001a113eca2efbfddc0514817d49 Content-Type: text/plain; charset=UTF-8 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 wrote: > > > On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell > 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. > > --001a113eca2efbfddc0514817d49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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-e= nabled walled on multiple devices:

https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.media= wiki


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 reu= sed 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 t= hat the output associated with notification transactions would require spec= ial handling to avoid privacy leaks. At a minimum they'd require mixing= or being donated to miners as a transaction fee.
=C2=A0

It would also more than double the data sent for the application where
'stealth addresses' are most important: one-time anonymous donation= s
(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 dona= tion in the lifetime of the sender's identity, payment codes would requ= ire 65 bytes vs 40 bytes for stealth addresses.

As= soon as the sender sends more than one donation to the same recipient, pay= ment codes show an space advantage over stealth addresses.
=
This kind of binding was intentionally designed = out of the stealth
address proposal;=C2=A0 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 eph= emeral public
key could be appended to the chain code, but that's = undesirable for other reasons.

This is fundam= entally more expensive to compute; please don't specify
"uncompressed".

Taking= the SHA512 of something less than 512 bits seemed wrong.
= =C2=A0
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.
=C2=A0
= I'm disappointed that there isn't any thought given to solving the<= br> 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&#= 39;t have all the features we want.

In this propos= al I optimized for non-reliance on third party services and a guaranteed ab= ility to recover spendable funds from a seed backup.

Gaining those t= wo features resulted in some tradeoffs as you noted, but I think there are = enough benefits to make them worthwhile.

In partic= ular, payment codes could be the basis for a Heartbleed-free payment protoc= ol 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 cus= tomers to make sure they are paying the right entity.

Exchanges coul= d restrict bitcoin withdrawals to a single payment code known to be associa= ted 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 arbitra= ry third parties, might move some Bitcoin businesses out of money transmitt= er territory into less onerous regulatory situations.

=


--001a113eca2efbfddc0514817d49--