Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of dashjr.org
	designates 85.234.147.28 as permitted sender)
	client-ip=85.234.147.28; envelope-from=luke@dashjr.org;
	helo=zinan.dashjr.org; 
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Sat, 6 Jun 2015 15:18:18 +0000
User-Agent: KMail/1.13.7 (Linux/3.14.41-gentoo; KDE/4.14.3; x86_64; ; )
References: <CAPswA9w5Sgg6AV=9Pqx5sqbkdrwv9LmwoxmMu7xZsQSNXtmZnQ@mail.gmail.com>
In-Reply-To: <CAPswA9w5Sgg6AV=9Pqx5sqbkdrwv9LmwoxmMu7xZsQSNXtmZnQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201506061518.19431.luke@dashjr.org>
Subject: Re: [Bitcoin-development] BIP for Proof of Payment
Precedence: list

On Saturday, June 06, 2015 2:35:17 PM Kalle Rosenbaum wrote:
> Current methods of proving a payment:
> 
> * Signing messages, chosen by the server, with the private keys used to
> sign the transaction. This could meet 1 and 2 but probably not 3. This is
> not standardized either. 4 Could be met if designed so.

It's also not secure, since the signed messages only prove ownership of the 
address associated with the private key, and does not prove ownership of 
UTXOs currently redeemable with the private key, nor prove past UTXOs spent 
were approved by the owner of the address.

> A proof of payment for a transaction T, here called PoP(T), is used to
> prove that one has ownership of the credentials needed to unlock all the
> inputs of T.

This appears to be incompatible with CoinJoin at least. Maybe there's some 
clean way to avoid that by using 
https://github.com/Blockstream/contracthashtool ?

> It has the exact same structure as a bitcoin transaction with
> the same inputs and outputs as T and in the same order as in T. There is
> also one OP_RETURN output inserted at index 0, here called the pop output.

I also agree with Pieter, that this should *not* be so cleanly compatible 
with Bitcoin transactions. If you wish to share code, perhaps using an 
invalid opcode rather than OP_RETURN would be appropriate.

Luke