diff options
| author | Pieter Wuille <pieter.wuille@gmail.com> | 2011-09-24 01:15:48 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-09-23 23:16:03 +0000 |
| commit | 44e8dcd266e7d7ba67e0641f0abe6c1fa6e5ed01 (patch) | |
| tree | 286b25c69d7ea43416a27ec655471ad8dfe3dce0 /73 | |
| parent | 4444e8088c67890e16ea53d6d332211ec67a09db (diff) | |
| download | pi-bitcoindev-44e8dcd266e7d7ba67e0641f0abe6c1fa6e5ed01.tar.gz pi-bitcoindev-44e8dcd266e7d7ba67e0641f0abe6c1fa6e5ed01.zip | |
Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin payment protocol
Diffstat (limited to '73')
| -rw-r--r-- | 73/cf70c68421725593eba782f96b819be8b57ac2 | 142 |
1 files changed, 142 insertions, 0 deletions
diff --git a/73/cf70c68421725593eba782f96b819be8b57ac2 b/73/cf70c68421725593eba782f96b819be8b57ac2 new file mode 100644 index 000000000..b34633fd0 --- /dev/null +++ b/73/cf70c68421725593eba782f96b819be8b57ac2 @@ -0,0 +1,142 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <sipa@ulyssis.org>) id 1R7EyR-00007E-R8 + for bitcoin-development@lists.sourceforge.net; + Fri, 23 Sep 2011 23:16:03 +0000 +X-ACL-Warn: +Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129] + helo=cavuit01.kulnet.kuleuven.be) + by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1R7EyQ-0006Nk-2X for bitcoin-development@lists.sourceforge.net; + Fri, 23 Sep 2011 23:16:03 +0000 +X-KULeuven-Envelope-From: sipa@ulyssis.org +X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5, + autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00, + FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20) +X-KULeuven-Scanned: Found to be clean +X-KULeuven-ID: 09DCC138025.ABCB8 +X-KULeuven-Information: Katholieke Universiteit Leuven +Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be + [134.58.240.75]) + by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 09DCC138025 + for <bitcoin-development@lists.sourceforge.net>; + Sat, 24 Sep 2011 01:15:49 +0200 (CEST) +Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be + [193.190.253.235]) + by smtps02.kuleuven.be (Postfix) with ESMTP id C6229F3862 + for <bitcoin-development@lists.sourceforge.net>; + Sat, 24 Sep 2011 01:15:48 +0200 (CEST) +Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182]) + by smtp.ulyssis.org (Postfix) with ESMTP id 327CB1001C + for <bitcoin-development@lists.sourceforge.net>; + Sat, 24 Sep 2011 01:20:50 +0200 (CEST) +Received: by wop.ulyssis.org (Postfix, from userid 615) + id CE4E487C1AC; Sat, 24 Sep 2011 01:15:48 +0200 (CEST) +Date: Sat, 24 Sep 2011 01:15:48 +0200 +X-Kuleuven: This mail passed the K.U.Leuven mailcluster +From: Pieter Wuille <pieter.wuille@gmail.com> +To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Message-ID: <20110923231547.GA28700@ulyssis.org> +References: <20110923162102.GA13532@ulyssis.org> <4E7CC428.6020500@jerviss.org> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <4E7CC428.6020500@jerviss.org> +X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc +User-Agent: Mutt/1.5.20 (2009-06-14) +X-Spam-Score: 1.2 (+) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (pieter.wuille[at]gmail.com) + 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is + CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, + and not from a mailing list + 0.0 AWL AWL: From: address is in the auto white-list +X-Headers-End: 1R7EyQ-0006Nk-2X +Subject: Re: [Bitcoin-development] Beyond IP transactions: towards a bitcoin + payment protocol +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: Fri, 23 Sep 2011 23:16:03 -0000 + +On Fri, Sep 23, 2011 at 12:38:48PM -0500, kjj wrote: +> Pieter Wuille wrote: +> >Hello everyone, +> > +> >here is an idea i've bean writing up: https://gist.github.com/1237788 +> > +> >I hope it can start some discussion about moving away from static bitcoin addresses +> >as descriptions for transactions. I suppose it's a candidate for a BIP/BEPS/BFC/..., +> >but as things don't seem to have been decided completely about those, I put it in a +> >Gist. +> > +> >Please, comment. +> > +> This may just be me, but this really looks like an incredibly +> convoluted way to solve a bunch of problems that aren't really +> problems. The central issue that I see, is that you assume that +> there is no out of band channel, as if people were just sending +> transactions to addresses that came to them in a dream. +> +> I think that this assumption is only true when it doesn't matter. +> For example, I have a donation link in my sig on the forums. I +> don't care much who sends to it, or why, and I certainly don't need +> annotations or a refund address. The rest of the time, payments are +> sent to addresses that already have sufficient context. + +Well, I agree, this scheme is not (primarily) intended to be a solution +for people who want to accept anonymous donations; static addresses +work very well for that application (unless you want unlinkability +between different payments). + +Let me try to explain what I do want to accomplish. + +What current addresses are, is a reference to a public key. The way they +are used is as a template for a transaction. If you do not need complex +transactions, this suffices indeed, given that all other negotiation about +the payment occurs out-of-band already (e.g., a webshop interface that +after clicking 'pay' gives you a freshly generated bitcoin address and +stores it so it can track your payment). + +What I want to do is to standardize part of that out-of-band communication +inside a protocol. The first observation is that if you want a freshly +negotiated key each time, some form of bidirectional communication is +necessary anyway, and a static txout template does not suffice anymore. +If you're doing bidirectional communication, you are no longer limited +by the space constraints of something by-human-copy-pastable, and you can +just negotiate the txout directly, which transparently adds support for +anything that is possible through bitcoin scripts. + +So far, the creation of transactions is "solved". However, by asking nodes +not to broadcast their transaction, but instead just send it back (we're +communicating with some other party already anyway, and this other party +is the one who cares about the tx being accepted), the receiver can track +it as well. Furthermore, by passing tags along, identification of +transactions becomes a lot easier. As a extra advantage, this makes the +requirements for a client easier as well (it doesn't need to be a p2p +node). + +The third step is adding signatures to authenticate the whole process. +They are necessary to make sure the client is communicating with who he +thinks he is, but by using them for the submission of the transaction as +well, it gives the client a proof of payment acceptance too. + +Summarized: addresses are a limited method for defining payments, and as +soon as you move to a protocol instead of a static template, a lot of +possibilities open up. + +-- +Pieter + + |