Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ymzx6-0008Vf-13 for bitcoin-development@lists.sourceforge.net; Tue, 28 Apr 2015 07:29:08 +0000 Received: from mail-wi0-f181.google.com ([209.85.212.181]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Ymzx3-0000pk-Ug for bitcoin-development@lists.sourceforge.net; Tue, 28 Apr 2015 07:29:08 +0000 Received: by wicmx19 with SMTP id mx19so101061219wic.1 for ; Tue, 28 Apr 2015 00:28:59 -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=V8YznK8ZrpLYDFsy2ud0rAmV2zKoS367m3PJDFcK3O8=; b=PUZohm9wN6E6DbWorzv1bNL+5EW2try9+xBQprG56wGfFnqaE8gAv49yIuCtLvQGtk zN/4j10DtldJ8yzQB4suKlW+3vCg3L9sNtVRMMzCDKVRnnBfDaCenC0sUbPMBzma5ukN kLOZhZQoaBsngD9nVr9JjqDVWLNt8Pss5N1Q6lLr/mdCbxb2z4DHTwkocEgWaCfo51Sv mvg21H/cfp7SPPh4xjuFWy6pGFi3ob8Wzhp+SYevxN9mrTyW7rM7CZvfREB/UUiDEwRG kxLbPqEAxsoDMYLKJ+RfNgNvGvN7d4K4atTqb3ee6iWQlHdBxVJRxSxf5tprxRJrmR9Q bhEA== X-Gm-Message-State: ALoCoQnfdRLabRcmpax85D+AUlIfXKVf4hH8ypsIlf3I9OONrJl8zHM49eJg7Uph2HubYXyrJ+w3 MIME-Version: 1.0 X-Received: by 10.180.105.193 with SMTP id go1mr26609025wib.92.1430205833701; Tue, 28 Apr 2015 00:23:53 -0700 (PDT) Received: by 10.194.124.2 with HTTP; Tue, 28 Apr 2015 00:23:53 -0700 (PDT) Received: by 10.194.124.2 with HTTP; Tue, 28 Apr 2015 00:23:53 -0700 (PDT) In-Reply-To: References: <553D87CE.5000005@thinlink.com> Date: Tue, 28 Apr 2015 09:23:53 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Kalle Rosenbaum Content-Type: multipart/alternative; boundary=f46d04182800ac7f620514c3be39 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: 1Ymzx3-0000pk-Ug 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: Tue, 28 Apr 2015 07:29:08 -0000 --f46d04182800ac7f620514c3be39 Content-Type: text/plain; charset=UTF-8 So at the low level, how does a "proof of payment" differ from just proving that a given transaction is in a given block (what SPV nodes take as proof of payment today)? On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum" wrote: > "Or a really high lock_time, but it would not make it invalid, just > delayed." > > Ok, this was a bad idea, since nodes would have to keep it in memory. > Please disregard that idea... > > Kalle > > Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" : > > > > > > > > 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 > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --f46d04182800ac7f620514c3be39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So at the low level, how does a "proof of payment"= differ from just proving that a given transaction is in a given block (wha= t SPV nodes take as proof of payment today)?

On Apr 27, 2015 2:42 PM, "Kalle Rosenbaum&q= uot; <kalle@rosenbaum.se> w= rote:

"Or a really high lock_time, but it would not make it invalid, just d= elayed."

Ok, this was a bad idea, since nodes would have to keep it i= n memory. Please disregard that idea...

Kalle

Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" <= kalle@rosenbaum.se<= /a>>:
>
> >
> > Some more use cases might be:
> > Waiting in comfort:
> > =C2=A0- Send a payment ahead of time, then wander over and collec= t the goods
> > after X confirmations.
> >
> > Authorized pickup :
> > =C2=A0- Hot wallet software used by related people could facilita= te the use
> > of 1 of N multisig funds.=C2=A0 Any one of the N wallets could co= llect 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:
> > =C2=A0- Sender exports spent keys to a beneficiary, enabling PoP = to work as a
> > gift claim
> >
> > Contingent services:
> > =C2=A0- Without Bob's permission, a 3rd party conditions acti= on on a payment
> > made from Alice to Bob.=C2=A0 For example, if you donated at leas= t .02 BTC to
> > Dorian, you (or combining scenarios, any of your N authorized fam= ily
> > members), can come to my dinner party.
>
> This is an interesting one.
>
> >
> > I tried out your demo wallet and service and it worked as adverti= sed.
> >
> > Could the same standard also be used to prove that a transaction = COULD
> > BE created?=C2=A0 To generalize the concept beyond actual payment= s, you could
> > call it something like proof of payment potential.
>
> I guess it's possible, but we'd have to remove the txid from t= he output, since there is none. This is a way of saying "I'm in co= ntrol 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 re= move
> > any possibility of their being mined and spending everything to f= ees
> > when used in this way, and also in cases involving reorganization= s?
>
> 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 i= t's a huge security problem. Someone might intercept the PoP and publis= h 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. C= ould we possibly change the version number on the PoP to something other th= an 1? Maybe 2^4-1? Or a really high lock_time, but it would not make it inv= alid, just delayed. Any suggestions here?
>
> >
> > I agree that PoP seems complementary to BIP70.
> >
> >
>
> Thank you very much for your comments!
>
> /Kalle


-----------------------------------------------------------------------= -------
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
= _______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d04182800ac7f620514c3be39--