1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1Z1FtC-000505-2i
for bitcoin-development@lists.sourceforge.net;
Sat, 06 Jun 2015 15:20:02 +0000
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;
Received: from 85-234-147-28.static.as29550.net ([85.234.147.28]
helo=zinan.dashjr.org)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z1FtA-00060X-Sw for bitcoin-development@lists.sourceforge.net;
Sat, 06 Jun 2015 15:20:02 +0000
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 625041083AA6;
Sat, 6 Jun 2015 15:18:20 +0000 (UTC)
X-Hashcash: 1:25:150606:bitcoin-development@lists.sourceforge.net::anvbofXybXPxuOtv:bwk/Y
X-Hashcash: 1:25:150606:kalle@rosenbaum.se::FVGrsG3HdaoU0s6N:afce/
X-Hashcash: 1:25:150606:gmaxwell@gmail.com::OT1=2BaywKYqkIvo:crfYW
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>
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: <201506061518.19431.luke@dashjr.org>
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 TVD_RCVD_IP Message was received from an IP address
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Z1FtA-00060X-Sw
Subject: Re: [Bitcoin-development] BIP for Proof of Payment
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2015 15:20:02 -0000
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
|
