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 1YlnqD-0006hd-ME for bitcoin-development@lists.sourceforge.net; Sat, 25 Apr 2015 00:21:05 +0000 Received: from mail-ie0-f171.google.com ([209.85.223.171]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YlnqC-0003Y5-KB for bitcoin-development@lists.sourceforge.net; Sat, 25 Apr 2015 00:21:05 +0000 Received: by iedfl3 with SMTP id fl3so106766106ied.1 for ; Fri, 24 Apr 2015 17:20:59 -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=R7y/aS+xGx5Ew6THrzWWIayfsHw1/tgUedp21d0Qwk4=; b=lst+t1EjOkgRZ+znvXeunliDYZoLEhG6jQdsr+xwO5CctoWIkp794esg+asDi3aG/M +CezEkXR+FEFO0uBaplVTyDX3pNPbhUop6KgD0ynU+TkQtgPGpJ1/vK29LtQno8O/c2t xFWX2JitK4yfwG5SEzExmmd+GEvNEOVPspX/XtFXky3/o4ApCaP6E7LD9UaFt1lo84m5 3G/amhCsu+ULjJ1pKRP0MIdjGDp2iY1jYPxffCfUNFcvC26BclgeWV1ZgiOdJCzIiUk5 EzPnpEPxhiOfOcLuNpFaQfgi53YakAjoLlCiRXG0K5/yzm+DjF6YtzlEz3GETIaP8QzE VbYw== X-Gm-Message-State: ALoCoQm6cl4+g+p1bY97wkn1bkV8AtC1n5l7qWqRRZL904kdwK3iz+JIRgE2xPhUY6QVsz+7XaFJ MIME-Version: 1.0 X-Received: by 10.42.129.73 with SMTP id p9mr1674241ics.48.1429921259265; Fri, 24 Apr 2015 17:20:59 -0700 (PDT) Received: by 10.36.205.135 with HTTP; Fri, 24 Apr 2015 17:20:59 -0700 (PDT) In-Reply-To: References: Date: Sat, 25 Apr 2015 02:20:59 +0200 Message-ID: From: Justus Ranvier To: Bitcoin Dev Content-Type: multipart/alternative; boundary=20cf301af6d9b738d70514817cbf 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: 1YlnqC-0003Y5-KB 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:05 -0000 --20cf301af6d9b738d70514817cbf Content-Type: text/plain; charset=UTF-8 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. --20cf301af6d9b738d70514817cbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 24, 20= 15 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 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 intentionall= y 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.

Thi= s is fundamentally 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 mult= isignature; which is unfortunate.

I agree. I could not find a straightforward way to express a multisignatu= re payment code in less than 80 bytes.
=C2=A0
I'm disappointed that there isn't any thought g= iven 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&#= 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.

=

--20cf301af6d9b738d70514817cbf--