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 ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
