From: Tom Harding <tomh@thinlink•com>
To: Kalle Rosenbaum <kalle@rosenbaum•se>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proof of Payment
Date: Sun, 26 Apr 2015 17:50:22 -0700 [thread overview]
Message-ID: <553D87CE.5000005@thinlink.com> (raw)
In-Reply-To: <CAPswA9wZk_8EjbN8J-VbMGQ6nrZ7SthopJ=HYMtpxhSCsm_neA@mail.gmail.com>
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.
>
>
> >> 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
!= beneficiary, and/or receiver != 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.
next prev parent reply other threads:[~2015-04-27 0:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-13 19:29 Kalle Rosenbaum
2015-03-13 20:30 ` Natanael
2015-03-13 21:31 ` Mike Hearn
2015-03-13 21:47 ` Kalle Rosenbaum
2015-03-13 22:03 ` Mike Hearn
[not found] ` <CAPswA9y5bDs1urRCmh8Oxeho4As8pBt2rRVP6fjhjJA0cZrvfA@mail.gmail.com>
[not found] ` <CANEZrP35_h_-2c=A-1+M8umSpAC70DJ7sYhPPo_62dm2QKHCEg@mail.gmail.com>
2015-03-14 9:28 ` Kalle Rosenbaum
[not found] ` <A2849710-1069-45A1-89C0-9D8E40C4A8D6@newcastle.ac.uk>
2015-03-14 18:16 ` Kalle Rosenbaum
2015-04-22 20:03 ` Kalle Rosenbaum
[not found] ` <55384AC9.80501@datamagi.no>
2015-04-23 14:39 ` Kalle Rosenbaum
2015-04-27 0:50 ` Tom Harding [this message]
2015-04-27 12:35 ` Kalle Rosenbaum
2015-04-27 12:41 ` Kalle Rosenbaum
2015-04-28 7:23 ` Jorge Timón
2015-04-28 12:41 ` Kalle Rosenbaum
2015-04-28 12:53 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=553D87CE.5000005@thinlink.com \
--to=tomh@thinlink$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=kalle@rosenbaum$(echo .)se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox