This is not about complex scripts - although I consider the ability to transparently support complex script an advantage (which is true for both this proposal and OP_DROP).
This is about realizing that a static txout template itself has limitations.
For example: if I am using a webpage to buy something, I am already using the http protocol. Why do I need to carry the burden of getting the transaction broadcast and accepted on the network, instead of just sending it to him? The payee is the one who 1) already has the network infrastructure in place and 2) cares about getting his money.
Topic: Proposal: bitcoin payment protocol (Read 980 times)
Related discussions in https://bitcointalksearch.org/topic/proposed-extensions-to-the-transaction-protocol-receiver-scripts-optime-more-46429, https://bitcointalksearch.org/topic/proposal-to-modify-opchecksig-45211, https://bitcointalksearch.org/topic/opeval-proposal-46538. The basic idea - allowing more-complex scripts to control the conditions under which coins are released - is good. However, I prefer the versions that keep the address format the same, or at least very similar. Allowing complicated addresses puts burden on Bitcoin-handling web sites and breaks compatibility in ways that it doesn't need to be broken.
Currently, addresses are the only well-supported way of initiating a bitcoin transaction. However, what bitcoin addresses are in practice is no more than a template for a txout script. In practice, such an address (typically a freshly-generated one) is communicated to the payer when a payment is requested, through a website, a QR code, e-mail, ...
If stop limiting ourselves to short strings to define a payment, a lot of possibilities open up. In the following gist i've written up a proposal for a full bitcoin payment protocol, that allows arbitrary scripts, makes the receiver responsible for getting the transaction accepted, optionally removes the burden of transaction fees from the payer, and allows easy tracking of actual individual payments.
https://gist.github.com/1237788
Comments, suggestions, ideas?
If stop limiting ourselves to short strings to define a payment, a lot of possibilities open up. In the following gist i've written up a proposal for a full bitcoin payment protocol, that allows arbitrary scripts, makes the receiver responsible for getting the transaction accepted, optionally removes the burden of transaction fees from the payer, and allows easy tracking of actual individual payments.
https://gist.github.com/1237788
Comments, suggestions, ideas?
Jump to: