Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YmiMI-000269-NK for bitcoin-development@lists.sourceforge.net; Mon, 27 Apr 2015 12:41:58 +0000 X-ACL-Warn: Received: from mail-qg0-f44.google.com ([209.85.192.44]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YmiMH-0006tv-Hl for bitcoin-development@lists.sourceforge.net; Mon, 27 Apr 2015 12:41:58 +0000 Received: by qgej70 with SMTP id j70so48649647qge.2 for ; Mon, 27 Apr 2015 05:41:52 -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=B5kD07ZUs2GhHdbnNwm1Lf5vC1+y8rauNEqNMPTjCVg=; b=JF9SyR96GYnvk+1RDgAoK4jvj3tFCUtlJ4ccNwM1G7SI1swcjimhf3hWaQVgxX7S57 no0GJ4MSVE/mLoOej5r416aOHotDmfJc2G23I/sH5gW22bZ1RA/3lh3cJv2ynDoKA6RL y0uZfWKzbFFcjqLdaK1IHUQIIJfouHD3EXfVTgglEG9bAsFrRgG70HHt6sRhq/WJ3HS2 E0W7vjY0NiZLrh7yIXO1DpYYE6PDBz7O5lumBuulPISwXoGMLUJ66TUcBiB2Y8azt3gU sJ2WfJQkQPt+LHiWbPuzAvXkkibso6xVGgtWpDnQoL0EV7Dw6Rf8CzTZboHeuDVCtyOI koQA== X-Gm-Message-State: ALoCoQlwfm6/3XfUOkXjq4skZG8ERg/DseEB/tHVfq7qt6O2bpDyRX7675n5NllMLkP5uG1wjMH8 MIME-Version: 1.0 X-Received: by 10.140.28.163 with SMTP id 32mr7287707qgz.5.1430138511945; Mon, 27 Apr 2015 05:41:51 -0700 (PDT) Received: by 10.96.145.9 with HTTP; Mon, 27 Apr 2015 05:41:51 -0700 (PDT) Received: by 10.96.145.9 with HTTP; Mon, 27 Apr 2015 05:41:51 -0700 (PDT) In-Reply-To: References: <553D87CE.5000005@thinlink.com> Date: Mon, 27 Apr 2015 14:41:51 +0200 Message-ID: From: Kalle Rosenbaum To: Tom Harding Content-Type: multipart/alternative; boundary=001a1139b1b2fc047f0514b4115a 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: 1YmiMH-0006tv-Hl 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:41:58 -0000 --001a1139b1b2fc047f0514b4115a Content-Type: text/plain; charset=UTF-8 "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 --001a1139b1b2fc047f0514b4115a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

"Or a really high lock_time, but it would not make it i= nvalid, 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>:
>
> >
> > 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

--001a1139b1b2fc047f0514b4115a--