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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) 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 ; 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 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 References: In-Reply-To: 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 Subject: Re: [Bitcoin-development] Proof of Payment 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: 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.