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 1Yn4pg-0005Ff-8k for bitcoin-development@lists.sourceforge.net; Tue, 28 Apr 2015 12:41:48 +0000 X-ACL-Warn: Received: from mail-qg0-f43.google.com ([209.85.192.43]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yn4pe-0002xH-4B for bitcoin-development@lists.sourceforge.net; Tue, 28 Apr 2015 12:41:48 +0000 Received: by qgfi89 with SMTP id i89so62284052qgf.1 for ; Tue, 28 Apr 2015 05:41:40 -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=x7sZdaKuOYXweMZl753WFXuK+1YSiXDtcFFNJSMMwZA=; b=aVduk8Hzub2sPkU5pnBLnOD1sLQ97DxyN2yhStsLm022NqaJa+ZQ4HjdbECONCbAud cQvf7UbKxUUN5GDZXj2fFi27A9gQg7yjgXWcy77/LkTILEhIZxVUUxWT0W0r3Mg5jqUQ 4G2b12yVjgRjHwLDTLoP40l+rCIt/6oKbopCTGZhBDkwf4idmotvuxrn56Sb6g5mjSLu wbK0xLB5Bt5WmuA3e86O8N4Ntiz9wMyFxb1qMjECB3IG8ft95TPe+QlQxmxB/c3XDXpj F8BHUOva7ZZ0zsMhqQ26SqKZSB0pzI1cQmuR0+5ykLa9FAfFDFtOgR5G+zLkpGaH1iXE darQ== X-Gm-Message-State: ALoCoQm6oz1D4/d+U9F+O3VKa7gww8cW5iqlMkL8JxhlrAXGUVZVX2X4uRQy98UlYt5IrZzkxhDL MIME-Version: 1.0 X-Received: by 10.140.28.163 with SMTP id 32mr11689722qgz.5.1430224900577; Tue, 28 Apr 2015 05:41:40 -0700 (PDT) Received: by 10.96.145.9 with HTTP; Tue, 28 Apr 2015 05:41:40 -0700 (PDT) Received: by 10.96.145.9 with HTTP; Tue, 28 Apr 2015 05:41:40 -0700 (PDT) In-Reply-To: References: <553D87CE.5000005@thinlink.com> Date: Tue, 28 Apr 2015 14:41:40 +0200 Message-ID: From: Kalle Rosenbaum To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=001a1139b1b225f4ce0514c82f21 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: 1Yn4pe-0002xH-4B 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 12:41:48 -0000 --001a1139b1b225f4ce0514c82f21 Content-Type: text/plain; charset=UTF-8 Hi Jorge, I don't think I understand the question. Proof of Payment is used to prove that you have the credentials needed for a certain transaction. It does not care where in the blockchain the transaction is. Or if it's in the blockchain at all. /Kalle 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 > > --001a1139b1b225f4ce0514c82f21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Jorge,

I don't think I understand the question. Proof of Paymen= t is used to prove that you have the credentials needed for a certain trans= action. It does not care where in the blockchain the transaction is. Or if = it's in the blockchain at all.

/Kalle

So at the low = level, how does a "proof of payment" differ from just proving tha= t 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&q= uot; <kalle@rose= nbaum.se> 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 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-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a1139b1b225f4ce0514c82f21--