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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tomh@thinlink.com>) id 1YmXFj-0003lh-ON
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Apr 2015 00:50:27 +0000
X-ACL-Warn:
Received: from mail-pd0-f179.google.com ([209.85.192.179])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YmXFg-0003yE-Eg
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Apr 2015 00:50:27 +0000
Received: by pdbnk13 with SMTP id nk13so110386918pdb.0
for <bitcoin-development@lists.sourceforge.net>;
Sun, 26 Apr 2015 17:50:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=wpLbMPXjAu5esYC/vnd3Ldb8S2cvGTe/UzpwEkRCR18=;
b=DEZwoNPA/DMlX9TqiXnEVQbgPw6zeGk43NA/fnT7kgRv4geH6ttaeUMVHfZ4u6OctF
qFd3qLnHfuUT/jLk07VtHwgOvCwqKnoEZ+Jij0Z00GkfTqRg7c45Z0eBv4I0bvEC4OyV
Wnwh49QsHzRnrJ+yKmeKBOZz27pNnb8CdFNUwDtyAI+p8qipsBcmbL4DdMfh4NK/4fu5
YKGYgaygHlmTnqXlTZZWQrPmQtA7qZZdS0Vnke55CVoFyiYF9xl7UbbMOgNTzrO+Bd/m
8zwdlplzOggeP/tXY67AiXVRI3F4BKuUGV1omlI7lve+xFZ84MLw7gp3629xljw+eNIy
Bw+A==
X-Gm-Message-State: ALoCoQmJWcHilLhNo1jRv2ogseeR00N3DSy+boRsAXn48FIj0J8Bi2K/UvDEukAAqoq74NDV2cAF
X-Received: by 10.70.52.103 with SMTP id s7mr17174298pdo.117.1430095818601;
Sun, 26 Apr 2015 17:50:18 -0700 (PDT)
Received: from [192.168.1.89] (99-8-65-117.lightspeed.davlca.sbcglobal.net.
[99.8.65.117])
by mx.google.com with ESMTPSA id o3sm9907363pds.1.2015.04.26.17.50.17
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 26 Apr 2015 17:50:17 -0700 (PDT)
Message-ID: <553D87CE.5000005@thinlink.com>
Date: Sun, 26 Apr 2015 17:50:22 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Kalle Rosenbaum <kalle@rosenbaum.se>
References: <CAPswA9zzVDxW8_WXg5833r2Z4pxZOppYtNLHMQ=Nw-H72cMz7w@mail.gmail.com> <A2849710-1069-45A1-89C0-9D8E40C4A8D6@newcastle.ac.uk> <CAPswA9wNS2J=4YhpqWN8SmzJuUF8mek8XLUYTE+twLX9vM4Jhg@mail.gmail.com>
<CAPswA9wZk_8EjbN8J-VbMGQ6nrZ7SthopJ=HYMtpxhSCsm_neA@mail.gmail.com>
In-Reply-To: <CAPswA9wZk_8EjbN8J-VbMGQ6nrZ7SthopJ=HYMtpxhSCsm_neA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YmXFg-0003yE-Eg
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 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: Mon, 27 Apr 2015 00:50:27 -0000
On 4/22/2015 1:03 PM, Kalle Rosenbaum wrote:
>
> I've built a proof-of-concept for Proof of Payment. It's available at
> http://www.rosenbaum.se:8080. The site contains links to the source
> code for both the server and a Mycelium fork as well as pre-built apk:s=
=2E
>
>
> >> There are several scenarios in which it would be useful to
> prove that you have paid for something. For example:
> >> A pre-paid hotel room where your PoP functions as a key to the
> door.
> >> An online video rental service where you pay for a video and
> watch it on any device.
> >> An ad-sign where you pay in advance for e.g. 2-weeks
> exclusivity. During this period you can upload new content to the
> sign whenever you like using PoP.
> >> A lottery where all participants pay to the same address, and
> the winner of the T-shirt is selected among the transactions to
> that address. You exchange the T-shirt for a PoP for the winning
> transaction.
>
Kalle,
You propose a standard format for proving that wallet-controlled funds
COULD HAVE BEEN spent as they were in a real transaction. Standardized
PoP would give wallets a new way to communicate with the outside world.
PoP could allow payment and delivery to be separated in time in a
standard way, without relying on a mechanism external to bitcoin's
cryptosystem, and enable standardized real-world scenarios where sender
!=3D beneficiary, and/or receiver !=3D provider.
Payment:
sender -> receiver
Delivery:
beneficiary <- provider
Some more use cases might be:
Waiting in comfort:
- Send a payment ahead of time, then wander over and collect the goods
after X confirmations.
Authorized pickup :
- Hot wallet software used by related people could facilitate the use
of 1 of N multisig funds. Any one of the N wallets could collect goods
and services purchased by any of the others.
Non-monetary gifts:
- Sender exports spent keys to a beneficiary, enabling PoP to work as a
gift claim
Contingent services:
- Without Bob's permission, a 3rd party conditions action on a payment
made from Alice to Bob. For example, if you donated at least .02 BTC to
Dorian, you (or combining scenarios, any of your N authorized family
members), can come to my dinner party.
I tried out your demo wallet and service and it worked as advertised.
Could the same standard also be used to prove that a transaction COULD
BE created? To generalize the concept beyond actual payments, you could
call it something like proof of payment potential.
Why not make these proofs permanently INVALID transactions, to remove
any possibility of their being mined and spending everything to fees
when used in this way, and also in cases involving reorganizations?
I agree that PoP seems complementary to BIP70.
|
