From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8EEB925A for ; Thu, 22 Oct 2015 21:05:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0B27D147 for ; Thu, 22 Oct 2015 21:05:40 +0000 (UTC) Received: by oiad129 with SMTP id d129so55178790oia.0 for ; Thu, 22 Oct 2015 14:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fv6Q+6/B4HpT4wJNEcyb64eStTQFUTTsdk/M+o5XPXk=; b=mxQX8wm4YcdDb1cATg0ZFyPx3QlLXJnPVhhFMs/4/tVY4RHlKMQBUqSc7cqxtXkDJX UdBGG37pdoa+Of6m4QQtDkDb2LjhX3pGaTJDktZ8I5rIR68GIP+vEzRCGkIQp1p17I8j mESzf8GDFvPUKQMLy39UP8W+B0i7foKe5SkiIRpuPICJBSWZPbB79jArXhfYPK+mPSeZ GRuiRq6MlozM8X1cr2qlriCjYIh3NTHEKqIzjS1RsJsxg8aix+iHeGP5/B3TD1Wa3qnI +6ZOroe0UDJ3PQloHoY+iiEnB3GHucXf1PDagS4rpqpVlrobbqYX0rYFIcjY236QfK+w Qf8w== MIME-Version: 1.0 X-Received: by 10.202.83.73 with SMTP id h70mr11816141oib.119.1445547939449; Thu, 22 Oct 2015 14:05:39 -0700 (PDT) Received: by 10.202.108.203 with HTTP; Thu, 22 Oct 2015 14:05:39 -0700 (PDT) In-Reply-To: <201510222043.17582.luke@dashjr.org> References: <201510220554.00367.luke@dashjr.org> <5628F8D2.1010709@openbitcoinprivacyproject.org> <201510222043.17582.luke@dashjr.org> Date: Thu, 22 Oct 2015 17:05:39 -0400 Message-ID: From: Kristov Atlas To: Luke Dashjr Content-Type: multipart/alternative; boundary=001a113d3d026fd03b0522b7db80 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 22 Oct 2015 21:20:18 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 21:05:40 -0000 --001a113d3d026fd03b0522b7db80 Content-Type: text/plain; charset=UTF-8 The consequence of previous ECDH address proposals "not designing around current software" is a sustained ~70% of transactions reusing addresses, as you saw in my Reddit post recently. If you have a fear that an inferior proposal will gain popularity, you can always propose a superior one. If it's *actually* superior, it will win out. On Thu, Oct 22, 2015 at 4:43 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote: > > On 22/10/15 00:53, Luke Dashjr wrote: > > > Sorry for the late review. I'm concerned with the "notification > address" > > > requirement, which entails address reuse and blockchain spam. Since it > > > entails address reuse, the recipient is forced to either leave them > > > unspent forever (bloating the UTXO set), or spend it which potentially > > > compromises the private key, and (combined with the payment code) > > > possibly as much as the entire wallet. > > > > > > Instead, I suggest making it a single zero-value OP_RETURN output with > > > two pushes: 1) a hash of the recipient's payment code, and 2) the > > > encrypted payment code. This can be searched with standard bloom > > > filters, or indexed with whatever other optimised algorithms are > > > desired. At the same time, it never uses any space in the UTXO set, and > > > never needs to be > > > spent/mixed/dusted. > > > > The notification transaction portion is my least-favorite portion of the > > spec, but I don't see any alternatives that provide an unambiguous > > improvement, including your suggestion. > > > > One of the most highly-weighted goals of this proposal is to be usable > > on as many mobile/light wallets as possible. > > > > I know for sure that all existing platforms for balance querying index > > by address. Support for bloom filters or other querying methods is less > > comprehensive, meaning the set of wallets that can support payment codes > > would be smaller. > > No, they just need to improve their software, and only to support receiving > with payment codes (not sending to them). BIPs should in general not be > designed around current software, especially in this case where there is no > benefit to doing so (since it requires software upgrades anyway). > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113d3d026fd03b0522b7db80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The consequence of previous ECDH address proposa= ls "not designing around current software" is a sustained ~70% of= transactions reusing addresses, as you saw in my Reddit post recently.
=

If you have a fear that an inferior proposal will gain popu= larity, you can always propose a superior one. If it's *actually* super= ior, it will win out.

On Thu, Oct 22, 2015 at 4:43 PM, Luke Dashjr via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> = wrote:
On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote:
> On 22/10/15 00:53, Luke Dashjr wrote:
> > Sorry for the late review. I'm concerned with the "notif= ication address"
> > requirement, which entails address reuse and blockchain spam. Sin= ce it
> > entails address reuse, the recipient is forced to either leave th= em
> > unspent forever (bloating the UTXO set), or spend it which potent= ially
> > compromises the private key, and (combined with the payment code)=
> > possibly as much as the entire wallet.
> >
> > Instead, I suggest making it a single zero-value OP_RETURN output= with
> > two pushes: 1) a hash of the recipient's payment code, and 2)= the
> > encrypted payment code. This can be searched with standard bloom<= br> > > filters, or indexed with whatever other optimised algorithms are<= br> > > desired. At the same time, it never uses any space in the UTXO se= t, and
> > never needs to be
> > spent/mixed/dusted.
>
> The notification transaction portion is my least-favorite portion of t= he
> spec, but I don't see any alternatives that provide an unambiguous=
> improvement, including your suggestion.
>
> One of the most highly-weighted goals of this proposal is to be usable=
> on as many mobile/light wallets as possible.
>
> I know for sure that all existing platforms for balance querying index=
> by address. Support for bloom filters or other querying methods is les= s
> comprehensive, meaning the set of wallets that can support payment cod= es
> would be smaller.

No, they just need to improve their software, and only to suppo= rt receiving
with payment codes (not sending to them). BIPs should in general not be
designed around current software, especially in this case where there is no=
benefit to doing so (since it requires software upgrades anyway).

Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a113d3d026fd03b0522b7db80--