From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YlkgQ-0007nl-7l for bitcoin-development@lists.sourceforge.net; Fri, 24 Apr 2015 20:58:46 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.170 as permitted sender) client-ip=209.85.213.170; envelope-from=gmaxwell@gmail.com; helo=mail-ig0-f170.google.com; Received: from mail-ig0-f170.google.com ([209.85.213.170]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YlkgO-0002Pg-MY for bitcoin-development@lists.sourceforge.net; Fri, 24 Apr 2015 20:58:46 +0000 Received: by igbpi8 with SMTP id pi8so35693219igb.0 for ; Fri, 24 Apr 2015 13:58:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.7.87 with SMTP id 84mr420879ioh.76.1429909119387; Fri, 24 Apr 2015 13:58:39 -0700 (PDT) Received: by 10.107.15.82 with HTTP; Fri, 24 Apr 2015 13:58:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Apr 2015 20:58:39 +0000 Message-ID: From: Gregory Maxwell To: Justus Ranvier Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YlkgO-0002Pg-MY Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] 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: Fri, 24 Apr 2015 20:58:46 -0000 On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier 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?