diff options
| author | Kalle Rosenbaum <kalle@rosenbaum.se> | 2015-04-27 14:41:51 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-04-27 12:41:58 +0000 |
| commit | f95258b54545e88feffd78ca2798a1f834a6430c (patch) | |
| tree | 5408a383050f05cc0ccd6fd49fff7131acfb3b1b | |
| parent | 1b7a05c525e99fcad23566dc4874fb1e7038aaaa (diff) | |
| download | pi-bitcoindev-f95258b54545e88feffd78ca2798a1f834a6430c.tar.gz pi-bitcoindev-f95258b54545e88feffd78ca2798a1f834a6430c.zip | |
Re: [Bitcoin-development] Proof of Payment
| -rw-r--r-- | 40/fc0c30653dfe8464f87fbfcb18f2bc45cb556f | 233 |
1 files changed, 233 insertions, 0 deletions
diff --git a/40/fc0c30653dfe8464f87fbfcb18f2bc45cb556f b/40/fc0c30653dfe8464f87fbfcb18f2bc45cb556f new file mode 100644 index 000000000..576426520 --- /dev/null +++ b/40/fc0c30653dfe8464f87fbfcb18f2bc45cb556f @@ -0,0 +1,233 @@ +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 <kalle@rosenbaum.se>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <CAPswA9xUfr1D6New3hm+1Z1OqSfkAZ8L+VnbFZayG+uJecgaeA@mail.gmail.com> +References: <CAPswA9zzVDxW8_WXg5833r2Z4pxZOppYtNLHMQ=Nw-H72cMz7w@mail.gmail.com> + <A2849710-1069-45A1-89C0-9D8E40C4A8D6@newcastle.ac.uk> + <CAPswA9wNS2J=4YhpqWN8SmzJuUF8mek8XLUYTE+twLX9vM4Jhg@mail.gmail.com> + <CAPswA9wZk_8EjbN8J-VbMGQ6nrZ7SthopJ=HYMtpxhSCsm_neA@mail.gmail.com> + <553D87CE.5000005@thinlink.com> + <CAPswA9xUfr1D6New3hm+1Z1OqSfkAZ8L+VnbFZayG+uJecgaeA@mail.gmail.com> +Date: Mon, 27 Apr 2015 14:41:51 +0200 +Message-ID: <CAPswA9w=DMDokS8BrDPTtWa_qpdORbK+V4aNS4DoAKE_F1iVoA@mail.gmail.com> +From: Kalle Rosenbaum <kalle@rosenbaum.se> +To: Tom Harding <tomh@thinlink.com> +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 <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Proof of Payment +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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" <kalle@rosenbaum.se>: +> +> > +> > 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 + +<p dir=3D"ltr">"Or a really high lock_time, but it would not make it i= +nvalid, just delayed." </p> +<p dir=3D"ltr">Ok, this was a bad idea, since nodes would have to keep it i= +n memory. Please disregard that idea... </p> +<p dir=3D"ltr">Kalle </p> +<p dir=3D"ltr">Den 27 apr 2015 14:35 skrev "Kalle Rosenbaum" <= +<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>>:<br> +><br> +> ><br> +> > Some more use cases might be:<br> +> > Waiting in comfort:<br> +> > =C2=A0- Send a payment ahead of time, then wander over and collec= +t the goods<br> +> > after X confirmations.<br> +> ><br> +> > Authorized pickup :<br> +> > =C2=A0- Hot wallet software used by related people could facilita= +te the use<br> +> > of 1 of N multisig funds.=C2=A0 Any one of the N wallets could co= +llect goods<br> +> > and services purchased by any of the others.<br> +><br> +> I like this one, because it shows the power of reusing the transaction= + data structure.<br> +><br> +> ><br> +> > Non-monetary gifts:<br> +> > =C2=A0- Sender exports spent keys to a beneficiary, enabling PoP = +to work as a<br> +> > gift claim<br> +> ><br> +> > Contingent services:<br> +> > =C2=A0- Without Bob's permission, a 3rd party conditions acti= +on on a payment<br> +> > made from Alice to Bob.=C2=A0 For example, if you donated at leas= +t .02 BTC to<br> +> > Dorian, you (or combining scenarios, any of your N authorized fam= +ily<br> +> > members), can come to my dinner party.<br> +><br> +> This is an interesting one.<br> +><br> +> ><br> +> > I tried out your demo wallet and service and it worked as adverti= +sed.<br> +> ><br> +> > Could the same standard also be used to prove that a transaction = +COULD<br> +> > BE created?=C2=A0 To generalize the concept beyond actual payment= +s, you could<br> +> > call it something like proof of payment potential.<br> +><br> +> 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?<br> +><br> +> ><br> +> > Why not make these proofs permanently INVALID transactions, to re= +move<br> +> > any possibility of their being mined and spending everything to f= +ees<br> +> > when used in this way, and also in cases involving reorganization= +s?<br> +><br> +> 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?<br> +><br> +> ><br> +> > I agree that PoP seems complementary to BIP70.<br> +> ><br> +> ><br> +><br> +> Thank you very much for your comments!<br> +><br> +> /Kalle</p> + +--001a1139b1b2fc047f0514b4115a-- + + |