From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YmiG6-0000Yc-6p for bitcoin-development@lists.sourceforge.net; Mon, 27 Apr 2015 12:35:34 +0000 X-ACL-Warn: Received: from mail-qc0-f173.google.com ([209.85.216.173]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YmiG4-0005b7-T3 for bitcoin-development@lists.sourceforge.net; Mon, 27 Apr 2015 12:35:34 +0000 Received: by qcbii10 with SMTP id ii10so54052401qcb.2 for ; Mon, 27 Apr 2015 05:35:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fgawZ10MzjEfeuWVp6TU1xYlPNCOzkxIbITKbOX3nZw=; b=m+24Eem7e34kZEEYHeMRzU8WuTB6TvkuJVwo+L52sYRLT7lANo9D3N8edr8xSiohEh FRypDAWxl9dcWvBkwqsqVjP/6+T8Dl4CJzAGGnDskpR2ZXVkyDmO5+VWltBHHyPtquRj B8cymokj6wXdP0JUqrt/7fcjf/rPnj2Kjf6Zyjx15gMOi01bqODajwSQE1gbXaEfxI+K btCxX5uuovnnZt2F/V63jJhOcGIBpm64x5FdGm3+dXNL4USoHAFM5OOPHQqmP5UyGESo yzTNpI3CerUzTEsm0j6HuxNOnffLh/kPkwiX8dVvhcxBaaeXpCbXA1uTv9ajW/TDx85j 0H0A== X-Gm-Message-State: ALoCoQlGawi8mvBgG1e++Ojh6xmi3OJNoryMDBtkxRs7r9XmCcyR76KD6tsDEzbyah2f+U47BYU0 MIME-Version: 1.0 X-Received: by 10.55.20.207 with SMTP id 76mr11997682qku.46.1430138127291; Mon, 27 Apr 2015 05:35:27 -0700 (PDT) Received: by 10.96.145.9 with HTTP; Mon, 27 Apr 2015 05:35:27 -0700 (PDT) Received: by 10.96.145.9 with HTTP; Mon, 27 Apr 2015 05:35:27 -0700 (PDT) In-Reply-To: <553D87CE.5000005@thinlink.com> References: <553D87CE.5000005@thinlink.com> Date: Mon, 27 Apr 2015 14:35:27 +0200 Message-ID: From: Kalle Rosenbaum To: Tom Harding Content-Type: multipart/alternative; boundary=001a114005320eaa4a0514b3fbcf X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YmiG4-0005b7-T3 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 12:35:34 -0000 --001a114005320eaa4a0514b3fbcf Content-Type: text/plain; charset=UTF-8 > > 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. I like this one, because it shows the power of reusing the transaction data structure. > > 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. This is an interesting one. > > 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. I guess it's possible, but we'd have to remove the txid from the output, since there is none. This is a way of saying "I'm in control of these addresses". The other party/parties can then verify the funds on the blockchain and watch those addresses for changes. Maybe there are some interesting use cases here. Ideas? > > 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? Yes. Initially I thought it would be enough that the funds are already spent, but I think you're right here. Reorgs could be a problem. Worse, you also might want to prove 0-confirmation transactions, in which case it's a huge security problem. Someone might intercept the PoP and publish it on the bitcoin network, spending all the funds. But I still would like wallets to be able to build/verify PoPs with little or no modifications. Could we possibly change the version number on the PoP to something other than 1? Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid, just delayed. Any suggestions here? > > I agree that PoP seems complementary to BIP70. > > Thank you very much for your comments! /Kalle --001a114005320eaa4a0514b3fbcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>
> Some more use cases might be:
> Waiting in comfort:
> =C2=A0- Send a payment ahead of time, then wander over and collect the= goods
> after X confirmations.
>
> Authorized pickup :
> =C2=A0- Hot wallet software used by related people could facilitate th= e use
> of 1 of N multisig funds.=C2=A0 Any one of the N wallets could collect= goods
> and services purchased by any of the others.

I like this one, because it shows the power of reusing the t= ransaction data structure.

>
> Non-monetary gifts:
> =C2=A0- Sender exports spent keys to a beneficiary, enabling PoP to wo= rk as a
> gift claim
>
> Contingent services:
> =C2=A0- Without Bob's permission, a 3rd party conditions action on= a payment
> made from Alice to Bob.=C2=A0 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.

This is an interesting one.

>
> I tried out your demo wallet and service and it worked as advertised.<= br> >
> Could the same standard also be used to prove that a transaction COULD=
> BE created?=C2=A0 To generalize the concept beyond actual payments, yo= u could
> call it something like proof of payment potential.

I guess it's possible, but we'd have to remove the t= xid from the output, since there is none. This is a way of saying "I&#= 39;m in control of these addresses". The other party/parties can then = verify the funds on the blockchain and watch those addresses for changes. M= aybe there are some interesting use cases here. Ideas?

>
> Why not make these proofs permanently INVALID transactions, to remove<= br> > any possibility of their being mined and spending everything to fees > when used in this way, and also in cases involving reorganizations?

Yes. Initially I thought it would be enough that the funds a= re already spent, but I think you're right here. Reorgs could be a prob= lem. Worse, you also might want to prove 0-confirmation transactions, in wh= ich case it's a huge security problem. Someone might intercept the PoP = and publish it on the bitcoin network, spending all the funds. But I still = would like wallets to be able to build/verify PoPs with little or no modifi= cations. Could we possibly change the version number on the PoP to somethin= g other than 1? Maybe 2^4-1? Or a really high lock_time, but it would not m= ake it invalid, just delayed. Any suggestions here?

>
> I agree that PoP seems complementary to BIP70.
>
>

Thank you very much for your comments!

/Kalle

--001a114005320eaa4a0514b3fbcf--