diff options
| author | Luke Dashjr <luke@dashjr.org> | 2015-10-22 20:43:16 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-22 20:43:32 +0000 |
| commit | 602e7eb6d01afdca38b08f30a5666cc28f222339 (patch) | |
| tree | 79d9b808883ac7c85d5fbc5d8ea051c80eb48683 | |
| parent | c15e6fdb2be9229e8f20ec5f9c0e861070e3ac59 (diff) | |
| download | pi-bitcoindev-602e7eb6d01afdca38b08f30a5666cc28f222339.tar.gz pi-bitcoindev-602e7eb6d01afdca38b08f30a5666cc28f222339.zip | |
Re: [bitcoin-dev] [Bitcoin-development] Reusable payment codes
| -rw-r--r-- | 60/2ebf641bcaa9820d699f4206826e17c9796f70 | 88 |
1 files changed, 88 insertions, 0 deletions
diff --git a/60/2ebf641bcaa9820d699f4206826e17c9796f70 b/60/2ebf641bcaa9820d699f4206826e17c9796f70 new file mode 100644 index 000000000..416383f9c --- /dev/null +++ b/60/2ebf641bcaa9820d699f4206826e17c9796f70 @@ -0,0 +1,88 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id CB689407 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 22 Oct 2015 20:43:32 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 6BFC7142 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 22 Oct 2015 20:43:32 +0000 (UTC) +Received: from ishibashi.localnet (unknown + [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id 7305938A566F; + Thu, 22 Oct 2015 20:43:18 +0000 (UTC) +X-Hashcash: 1:25:151022:justus@openbitcoinprivacyproject.org::9P2tSBvIWK/a=zLJ:aBGiD +X-Hashcash: 1:25:151022:bitcoin-dev@lists.linuxfoundation.org::tVWw1g3YJgGpsf+d:QEGi +From: Luke Dashjr <luke@dashjr.org> +To: Justus Ranvier <justus@openbitcoinprivacyproject.org> +Date: Thu, 22 Oct 2015 20:43:16 +0000 +User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; ) +References: <201510220554.00367.luke@dashjr.org> + <5628F8D2.1010709@openbitcoinprivacyproject.org> +In-Reply-To: <5628F8D2.1010709@openbitcoinprivacyproject.org> +X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F +X-PGP-Key-ID: BD02942421F4889F +X-PGP-Keyserver: hkp://pgp.mit.edu +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="iso-8859-15" +Content-Transfer-Encoding: 7bit +Message-Id: <201510222043.17582.luke@dashjr.org> +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 22 Oct 2015 20:43:32 -0000 + +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 + |