* [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol @ 2016-01-26 1:02 Toby Padilla 2016-01-26 2:24 ` Luke Dashjr 0 siblings, 1 reply; 24+ messages in thread From: Toby Padilla @ 2016-01-26 1:02 UTC (permalink / raw) To: bitcoin-dev; +Cc: luke_bipeditor [-- Attachment #1: Type: text/plain, Size: 5438 bytes --] Hi all, I'm submitting a new BIP draft for consideration and discussion. I've put a pull request up on Github that implements this BIP (with discussion from the Core team): https://github.com/bitcoin/bitcoin/pull/7376 My original discussion of this issue: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011874.html BIP draft as follows... -- ``` Title: Allow zero value OP_RETURN in Payment Protocol Author: Toby Padilla <tobypadilla@gmail•com> ``` ## Abstract This BIP alters the Payment Protocol to allow for zero value OP_RETURN outputs in serialized PaymentRequests. ## Motivation The Payment Protocol (defined in BIP70) gives merchants a way to build sophisticated transactions by serializing one or more outputs in the form of a PaymentRequest. The PaymentRequest is then served over http/https to a customer's wallet where the serialized transaction can be executed. While the Payment Protocol allows for any valid script in its outputs, it also ignores outputs with zero value. This means BIP70 implementations can encode an OP_RETURN script but must provide a greater than dust value for that output. The end result is a successful PaymentRequest transaction with an OP_RETURN but the value assigned to that output is lost forever. This BIP allows for zero value OP_RETURN outputs in serialized PaymentRequests. The change means that OP_RETURN scripts will work as they were originally intended from within PaymentRequests without permanently destroying Bitcoin value. Zero value non-OP_RETURN scripts should continue to be ignored and positive value OP_RETURN outputs should now be rejected. In addition to fixing the issue of destroyed value, this change opens up new use cases that were previously impossible. While storing data on the blockchain is controversial, when used responsibly OP_RETURN provides a powerful mechanism for attaching metadata to a transaction. This BIP effectively decouples the creation of transactions containing OP_RETURN data from the execution of those transactions. The result are positive benefits for both merchants and wallets/customers. By supporting this BIP, wallets can participate in current and future, unforeseen use cases that benefit from metadata stored in OP_RETURN. Until now OP_RETURN transactions have typically been created and submitted by custom software. If a wallet can process a PaymentRequest with OP_RETURN data as proposed by this BIP, it will support potentially sophisticated Bitcoin applications without the wallet developer having to have prior knowledge of that application. An example might be a merchant that adds the hash of a plain text invoice to the checkout transaction. The merchant could construct the PaymentRequest with the invoice hash in an OP_RETURN and pass it to the customer's wallet. The wallet could then submit the transaction, including the invoice hash from the PaymentRequest. The wallet will have encoded a proof of purchase to the blockchain without the wallet developer having to coordinate with the merchant software or add features beyond this BIP. Merchants and Bitcoin application developers benefit from this BIP because they can now construct transactions that include OP_RETURN data in a keyless environment. Again, prior to this BIP, transactions that used OP_RETURN (with zero value) needed to be constructed and executed in the same software. By separating the two concerns, this BIP allows merchant software to create transactions with OP_RETURN metadata on a server without storing public or private Bitcoin keys. This greatly enhances security where OP_RETURN applications currently need access to a private key to sign transactions. ## Specification The specification for this BIP is straightforward. BIP70 should be fully implemented with two changes: 1. Outputs where the script is an OP_RETURN and the value is zero should be accepted by the wallet. 2. Outputs where the script is an OP_RETURN and the value is greater than zero should be rejected. This is a change from the BIP70 requirement that all zero value outputs be ignored. ## Rationale As with the discussion around vanilla OP_RETURN, the practice of storing data on the blockchain is controversial. While blockchain and network bloat is an undeniable issue, the benefits that come from attaching metadata to transactions has proven to be too powerful to dismiss entirely. In the absence of OP_RETURN support the Bitcoin ecosystem has seen alternative, less elegant and more wasteful methods employed for Blockchain data storage. As it exists today, BIP70 allows for OP_RETURN data storage at the expense of permanently destroyed Bitcoin. Even fully removing support for OP_RETURN values in the Payment Protocol would still leave the door open to suboptimal data encoding via burning a larger than dust value to an output with a false address designed to encode data. This BIP offers all of the same benefits that come from the OP_RETURN compromise. Mainly that OP_RETURN scripts are provably unspendable and thus can be pruned from the UTXO pool. Without supporting this BIP, wallets that support BIP70 will allow for wasteful data storage. ## Compatibility While not in widespread use, existing BIP70 PaymentRequest outputs that have a greater than zero value with an OP_RETURN script (burning Bitcoin) will need to have their values changed to zero or they will be rejected by wallets implementing this BIP. [-- Attachment #2: Type: text/html, Size: 6432 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 1:02 [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol Toby Padilla @ 2016-01-26 2:24 ` Luke Dashjr 2016-01-26 2:54 ` Toby Padilla 0 siblings, 1 reply; 24+ messages in thread From: Luke Dashjr @ 2016-01-26 2:24 UTC (permalink / raw) To: Toby Padilla; +Cc: bitcoin-dev This is a bad idea. OP_RETURN attachments are tolerated (not encouraged!) for the sake of the network, since the spam cannot be outright stopped. If it could be outright stopped, it would not be reasonable to allow OP_RETURN. When it comes to the payment protocol, however, changing the current behaviour has literally no benefit to the network at all, and the changes proposed herein are clearly detrimental since it would both encourage spam, and potentially make users unwilling (maybe even unaware) participants in it. For these reasons, *I highly advise against publishing or implementing this BIP, even if the later mentioned issues are fixed.* On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote: > An example might be a merchant that adds the hash of a plain text invoice > to the checkout transaction. The merchant could construct the > PaymentRequest with the invoice hash in an OP_RETURN and pass it to the > customer's wallet. The wallet could then submit the transaction, including > the invoice hash from the PaymentRequest. The wallet will have encoded a > proof of purchase to the blockchain without the wallet developer having to > coordinate with the merchant software or add features beyond this BIP. Such a "proof" is useless without wallet support. Even if you argue it could be implemented later on, it stands to reason that a scammer will simply encode garbage if the wallet is not checking the proof-of-purchase upfront. To check it, you would also need further protocol extensions which are not included in this draft. > Merchants and Bitcoin application developers benefit from this BIP because > they can now construct transactions that include OP_RETURN data in a > keyless environment. Again, prior to this BIP, transactions that used > OP_RETURN (with zero value) needed to be constructed and executed in the > same software. By separating the two concerns, this BIP allows merchant > software to create transactions with OP_RETURN metadata on a server without > storing public or private Bitcoin keys. This greatly enhances security > where OP_RETURN applications currently need access to a private key to sign > transactions. I don't see how this has any relevance to keys at all... > ## Specification > > The specification for this BIP is straightforward. BIP70 should be fully > implemented with two changes: > > 1. Outputs where the script is an OP_RETURN and the value is zero should be > accepted by the wallet. > 2. Outputs where the script is an OP_RETURN and the value is greater than > zero should be rejected. > > This is a change from the BIP70 requirement that all zero value outputs be > ignored. This does not appear to be backward nor even forward compatible. Old clients will continue to use the previous behaviour and transparently omit any commitments. New clients on the other hand will fail to include commitments produced by old servers. In other words, it is impossible to produce software compatible with both BIP 70 and this draft, and implementing either would result in severe consequences. > As it exists today, BIP70 allows for OP_RETURN data storage at the expense > of permanently destroyed Bitcoin. It is better for the spammers to lose burned bitcoins, than have a way to avoid them. Luke ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 2:24 ` Luke Dashjr @ 2016-01-26 2:54 ` Toby Padilla 2016-01-26 2:56 ` Luke Dashjr 2016-01-26 14:37 ` Andreas Schildbach 0 siblings, 2 replies; 24+ messages in thread From: Toby Padilla @ 2016-01-26 2:54 UTC (permalink / raw) To: Luke Dashjr; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 4436 bytes --] It looks like my draft hasn't been approved by the mailing list so if anyone would like to read it it's also on Gist: https://gist.github.com/toby/9e71811d387923a71a53 Luke - As stated in the Github thread, I totally understand where you're coming from but the fact is people *will* encode data on the blockchain using worse methods. For all of the reasons that OP_RETURN was a good idea in the first place, it's a good idea to support it in PaymentRequests. As for keyless - there's no way (that I know of) to construct a transaction with a zero value OP_RETURN in an environment without keys since the Payment Protocol is what defines the method for getting a transaction from a server to a wallet. You can make a custom transaction and execute it in the same application but without Payments there's no way to move transactions between two applications. You need to build the transaction where you execute it and thus need a key. On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr <luke@dashjr•org> wrote: > This is a bad idea. OP_RETURN attachments are tolerated (not encouraged!) > for > the sake of the network, since the spam cannot be outright stopped. If it > could be outright stopped, it would not be reasonable to allow OP_RETURN. > When > it comes to the payment protocol, however, changing the current behaviour > has > literally no benefit to the network at all, and the changes proposed herein > are clearly detrimental since it would both encourage spam, and potentially > make users unwilling (maybe even unaware) participants in it. For these > reasons, *I highly advise against publishing or implementing this BIP, > even if > the later mentioned issues are fixed.* > > On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote: > > An example might be a merchant that adds the hash of a plain text invoice > > to the checkout transaction. The merchant could construct the > > PaymentRequest with the invoice hash in an OP_RETURN and pass it to the > > customer's wallet. The wallet could then submit the transaction, > including > > the invoice hash from the PaymentRequest. The wallet will have encoded a > > proof of purchase to the blockchain without the wallet developer having > to > > coordinate with the merchant software or add features beyond this BIP. > > Such a "proof" is useless without wallet support. Even if you argue it > could > be implemented later on, it stands to reason that a scammer will simply > encode > garbage if the wallet is not checking the proof-of-purchase upfront. To > check > it, you would also need further protocol extensions which are not included > in > this draft. > > > Merchants and Bitcoin application developers benefit from this BIP > because > > they can now construct transactions that include OP_RETURN data in a > > keyless environment. Again, prior to this BIP, transactions that used > > OP_RETURN (with zero value) needed to be constructed and executed in the > > same software. By separating the two concerns, this BIP allows merchant > > software to create transactions with OP_RETURN metadata on a server > without > > storing public or private Bitcoin keys. This greatly enhances security > > where OP_RETURN applications currently need access to a private key to > sign > > transactions. > > I don't see how this has any relevance to keys at all... > > > ## Specification > > > > The specification for this BIP is straightforward. BIP70 should be fully > > implemented with two changes: > > > > 1. Outputs where the script is an OP_RETURN and the value is zero should > be > > accepted by the wallet. > > 2. Outputs where the script is an OP_RETURN and the value is greater than > > zero should be rejected. > > > > This is a change from the BIP70 requirement that all zero value outputs > be > > ignored. > > This does not appear to be backward nor even forward compatible. Old > clients > will continue to use the previous behaviour and transparently omit any > commitments. New clients on the other hand will fail to include commitments > produced by old servers. In other words, it is impossible to produce > software > compatible with both BIP 70 and this draft, and implementing either would > result in severe consequences. > > > As it exists today, BIP70 allows for OP_RETURN data storage at the > expense > > of permanently destroyed Bitcoin. > > It is better for the spammers to lose burned bitcoins, than have a way to > avoid them. > > Luke > [-- Attachment #2: Type: text/html, Size: 5334 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 2:54 ` Toby Padilla @ 2016-01-26 2:56 ` Luke Dashjr 2016-01-26 3:01 ` Toby Padilla 2016-01-26 14:37 ` Andreas Schildbach 1 sibling, 1 reply; 24+ messages in thread From: Luke Dashjr @ 2016-01-26 2:56 UTC (permalink / raw) To: Toby Padilla; +Cc: bitcoin-dev On Tuesday, January 26, 2016 2:54:16 AM Toby Padilla wrote: > Luke - As stated in the Github thread, I totally understand where you're > coming from but the fact is people *will* encode data on the blockchain > using worse methods. For all of the reasons that OP_RETURN was a good idea > in the first place, it's a good idea to support it in PaymentRequests. As I explained, none of those reasons apply to PaymentRequests. > As for keyless - there's no way (that I know of) to construct a transaction > with a zero value OP_RETURN in an environment without keys since the > Payment Protocol is what defines the method for getting a transaction from > a server to a wallet. You can make a custom transaction and execute it in > the same application but without Payments there's no way to move > transactions between two applications. You need to build the transaction > where you execute it and thus need a key. I have no idea what you are trying to say here. Luke ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 2:56 ` Luke Dashjr @ 2016-01-26 3:01 ` Toby Padilla 2016-01-26 3:04 ` Luke Dashjr 0 siblings, 1 reply; 24+ messages in thread From: Toby Padilla @ 2016-01-26 3:01 UTC (permalink / raw) To: Luke Dashjr; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1697 bytes --] > As I explained, none of those reasons apply to PaymentRequests. As they exist today PaymentRequests allow for essentially the same types of transactions as non-PaymentRequest based transactions with the limitation that OP_RETURN values must be greater. In that sense they're basically a pre-OP_RETURN environment. OP_RETURN serves a purpose and it can't be used with PaymentRequest transactions. > I have no idea what you are trying to say here. I think if you think through how you would create an OP_RETURN transaction today without this BIP you'll see you need a key at some point if you want a zero value. On Mon, Jan 25, 2016 at 6:56 PM, Luke Dashjr <luke@dashjr•org> wrote: > On Tuesday, January 26, 2016 2:54:16 AM Toby Padilla wrote: > > Luke - As stated in the Github thread, I totally understand where you're > > coming from but the fact is people *will* encode data on the blockchain > > using worse methods. For all of the reasons that OP_RETURN was a good > idea > > in the first place, it's a good idea to support it in PaymentRequests. > > As I explained, none of those reasons apply to PaymentRequests. > > > As for keyless - there's no way (that I know of) to construct a > transaction > > with a zero value OP_RETURN in an environment without keys since the > > Payment Protocol is what defines the method for getting a transaction > from > > a server to a wallet. You can make a custom transaction and execute it in > > the same application but without Payments there's no way to move > > transactions between two applications. You need to build the transaction > > where you execute it and thus need a key. > > I have no idea what you are trying to say here. > > Luke > [-- Attachment #2: Type: text/html, Size: 2585 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 3:01 ` Toby Padilla @ 2016-01-26 3:04 ` Luke Dashjr 2016-01-26 3:07 ` Toby Padilla 0 siblings, 1 reply; 24+ messages in thread From: Luke Dashjr @ 2016-01-26 3:04 UTC (permalink / raw) To: Toby Padilla; +Cc: bitcoin-dev On Tuesday, January 26, 2016 3:01:13 AM Toby Padilla wrote: > > As I explained, none of those reasons apply to PaymentRequests. > > As they exist today PaymentRequests allow for essentially the same types of > transactions as non-PaymentRequest based transactions with the limitation > that OP_RETURN values must be greater. In that sense they're basically a > pre-OP_RETURN environment. OP_RETURN serves a purpose and it can't be used > with PaymentRequest transactions. OP_RETURN can be used, but you need to burn coins. I don't see any benefit to changing that. It is better that coins are burned. > > I have no idea what you are trying to say here. > > I think if you think through how you would create an OP_RETURN transaction > today without this BIP you'll see you need a key at some point if you want > a zero value. You *always* need a key, to redeem inputs... regardless of values. Luke ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 3:04 ` Luke Dashjr @ 2016-01-26 3:07 ` Toby Padilla 2016-01-26 3:12 ` Luke Dashjr 0 siblings, 1 reply; 24+ messages in thread From: Toby Padilla @ 2016-01-26 3:07 UTC (permalink / raw) To: Luke Dashjr; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1574 bytes --] > I don't see any benefit to changing that. It is better that coins are burned. I think this is our fundamental disagreement. People will burn coins to encode data, why allow this when there's a better alternative? > You *always* need a key, to redeem inputs... regardless of values. Correct, but with BIP70 that key is in the user's wallet and you can construct transactions on another machine (thus not needing a key during construction). Right now there's no way to do the transaction construction on another machine with zero value OP_RETURNs. On Mon, Jan 25, 2016 at 7:04 PM, Luke Dashjr <luke@dashjr•org> wrote: > On Tuesday, January 26, 2016 3:01:13 AM Toby Padilla wrote: > > > As I explained, none of those reasons apply to PaymentRequests. > > > > As they exist today PaymentRequests allow for essentially the same types > of > > transactions as non-PaymentRequest based transactions with the limitation > > that OP_RETURN values must be greater. In that sense they're basically a > > pre-OP_RETURN environment. OP_RETURN serves a purpose and it can't be > used > > with PaymentRequest transactions. > > OP_RETURN can be used, but you need to burn coins. I don't see any benefit > to > changing that. It is better that coins are burned. > > > > I have no idea what you are trying to say here. > > > > I think if you think through how you would create an OP_RETURN > transaction > > today without this BIP you'll see you need a key at some point if you > want > > a zero value. > > You *always* need a key, to redeem inputs... regardless of values. > > Luke > [-- Attachment #2: Type: text/html, Size: 2546 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 3:07 ` Toby Padilla @ 2016-01-26 3:12 ` Luke Dashjr 2016-01-26 3:17 ` Toby Padilla 0 siblings, 1 reply; 24+ messages in thread From: Luke Dashjr @ 2016-01-26 3:12 UTC (permalink / raw) To: Toby Padilla; +Cc: bitcoin-dev On Tuesday, January 26, 2016 3:07:40 AM Toby Padilla wrote: > > I don't see any benefit to changing that. It is better that coins are > > burned. > > I think this is our fundamental disagreement. People will burn coins to > encode data, why allow this when there's a better alternative? My point is that there isn't a better alternative. The coins being burned, is strictly better than it being gratis. > > You *always* need a key, to redeem inputs... regardless of values. > > Correct, but with BIP70 that key is in the user's wallet and you can > construct transactions on another machine (thus not needing a key during > construction). Right now there's no way to do the transaction construction > on another machine with zero value OP_RETURNs. This is also a good thing. Spam should not be made easier or cheaper. Luke ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 3:12 ` Luke Dashjr @ 2016-01-26 3:17 ` Toby Padilla 2016-01-26 3:23 ` Luke Dashjr 0 siblings, 1 reply; 24+ messages in thread From: Toby Padilla @ 2016-01-26 3:17 UTC (permalink / raw) To: Luke Dashjr; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1157 bytes --] I don't think every application of OP_RETURN could be classified as "spam". I also don't think burning the value is going to dissuade anyone from going down that route. I don't think lost value is better for anyone. On Mon, Jan 25, 2016 at 7:12 PM, Luke Dashjr <luke@dashjr•org> wrote: > On Tuesday, January 26, 2016 3:07:40 AM Toby Padilla wrote: > > > I don't see any benefit to changing that. It is better that coins are > > > burned. > > > > I think this is our fundamental disagreement. People will burn coins to > > encode data, why allow this when there's a better alternative? > > My point is that there isn't a better alternative. The coins being burned, > is > strictly better than it being gratis. > > > > You *always* need a key, to redeem inputs... regardless of values. > > > > Correct, but with BIP70 that key is in the user's wallet and you can > > construct transactions on another machine (thus not needing a key during > > construction). Right now there's no way to do the transaction > construction > > on another machine with zero value OP_RETURNs. > > This is also a good thing. Spam should not be made easier or cheaper. > > Luke > [-- Attachment #2: Type: text/html, Size: 1690 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 3:17 ` Toby Padilla @ 2016-01-26 3:23 ` Luke Dashjr 2016-01-26 3:30 ` Toby Padilla 0 siblings, 1 reply; 24+ messages in thread From: Luke Dashjr @ 2016-01-26 3:23 UTC (permalink / raw) To: Toby Padilla; +Cc: bitcoin-dev On Tuesday, January 26, 2016 3:17:12 AM Toby Padilla wrote: > I don't think every application of OP_RETURN could be classified as "spam". Perhaps not, but in this context I cannot think of any non-spam use cases. Use cases should come before changes to support them. > I also don't think burning the value is going to dissuade anyone from going > down that route. I don't think lost value is better for anyone. Lost value is better because it has a cost to the spammer, and deflates the rest of the bitcoins. Luke ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 3:23 ` Luke Dashjr @ 2016-01-26 3:30 ` Toby Padilla 2016-01-26 16:19 ` Thomas Kerin 0 siblings, 1 reply; 24+ messages in thread From: Toby Padilla @ 2016-01-26 3:30 UTC (permalink / raw) To: Luke Dashjr; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1408 bytes --] There are already valid use cases for OP_RETURN, it only makes sense to fully support the feature. The only reason it's not supported now is because the Payments protocol came before OP_RETURN. I give one example use case in the BIP. I agree that special wallet support would make the feature even better, but if someone tried to use Core the transaction would at least not be rejected. I've also been exploring this area with key.run ( https://git.playgrub.com/toby/keyrun) and want the functionality for voting based on aggregate OP_RETURN value. *Not* to store data on the blockchain, but to associate content pointers with transactions. I think that since OP_RETURN has already been approved and supported it doesn't make much sense for me to have to re-defend it from scratch here. On Mon, Jan 25, 2016 at 7:23 PM, Luke Dashjr <luke@dashjr•org> wrote: > On Tuesday, January 26, 2016 3:17:12 AM Toby Padilla wrote: > > I don't think every application of OP_RETURN could be classified as > "spam". > > Perhaps not, but in this context I cannot think of any non-spam use cases. > Use cases should come before changes to support them. > > > I also don't think burning the value is going to dissuade anyone from > going > > down that route. I don't think lost value is better for anyone. > > Lost value is better because it has a cost to the spammer, and deflates the > rest of the bitcoins. > > Luke > [-- Attachment #2: Type: text/html, Size: 2005 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 3:30 ` Toby Padilla @ 2016-01-26 16:19 ` Thomas Kerin 2016-01-26 17:44 ` Toby Padilla 0 siblings, 1 reply; 24+ messages in thread From: Thomas Kerin @ 2016-01-26 16:19 UTC (permalink / raw) To: bitcoin-dev On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote: > There are already valid use cases for OP_RETURN, it only makes sense > to fully support the feature. The only reason it's not supported now > is because the Payments protocol came before OP_RETURN. > You keep saying OP_RETURN is new, but it has been there from day one. It's purpose is causing script execution to end if encountered. Since then, we have tolerated putting pushdata's after it, and even raised the limit for the size of this data. It still doesn't mean every proposal has to be rewritten to cater for a new allowance we give OP_RETURN. > I've also been exploring this area with key.run > (https://git.playgrub.com/toby/keyrun) and want the functionality for > voting based on aggregate OP_RETURN value. *Not* to store data on the > blockchain, but to associate content pointers with transactions. > > I think that since OP_RETURN has already been approved and supported > it doesn't make much sense for me to have to re-defend it from scratch > here. I'd generally agree with Luke. Removing the cost of this hurts bitcoin, and ironically, your application to a certain degree. Just because you can do a thing one way, it doesn't mean you should. Especially if your applications success depends on people spamming OP_RETURN hashes of every torrent they like. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 16:19 ` Thomas Kerin @ 2016-01-26 17:44 ` Toby Padilla 2016-02-02 17:03 ` Peter Todd 0 siblings, 1 reply; 24+ messages in thread From: Toby Padilla @ 2016-01-26 17:44 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3126 bytes --] OP_RETURN was not part of isStandard? from day one. Once it was supported by Core it became necessary to actually support it, not try to support it in one part of the software and not in others. The whole reason it was supported is because without it people will use more heinous methods to encode data on the blockchain. There's no way to stop people from doing that, so this compromise seemed best for everyone. I think we should actually define "spam". To me a valid transaction someone willing pays for is never spam. Also PaymentRequests would be a very inefficient way to spam. It would be much easier to write a script to automatically create and submit transactions yourself. With PaymentRequests customers have to initiate the transaction and submit/pay for it one by one. What is actually the worst case scenario that those opposed to this are concerned about? That this takes off like wild fire and all of the sudden millions of people are using PaymentRequests and creating small transactions? That seems like a win for Bitcoin. It will help spread support for the Payment protocol and IF it becomes a problem it's because so many people are using it. In which case there's a very valid use case for Bitcoin that people are obviously excited about. I really don't like the idea of policing other people's use of the protocol. If a transaction pays its fee and has a greater than dust value, it makes no sense to object to it. On Tue, Jan 26, 2016 at 8:19 AM, Thomas Kerin via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote: > > There are already valid use cases for OP_RETURN, it only makes sense > > to fully support the feature. The only reason it's not supported now > > is because the Payments protocol came before OP_RETURN. > > > You keep saying OP_RETURN is new, but it has been there from day one. > It's purpose is causing script execution to end if encountered. > > Since then, we have tolerated putting pushdata's after it, and even > raised the limit for the size of this data. It still doesn't mean every > proposal has to be rewritten to cater for a new allowance we give > OP_RETURN. > > > > I've also been exploring this area with key.run > > (https://git.playgrub.com/toby/keyrun) and want the functionality for > > voting based on aggregate OP_RETURN value. *Not* to store data on the > > blockchain, but to associate content pointers with transactions. > > > > I think that since OP_RETURN has already been approved and supported > > it doesn't make much sense for me to have to re-defend it from scratch > > here. > > I'd generally agree with Luke. Removing the cost of this hurts bitcoin, > and ironically, your application to a certain degree. Just because you > can do a thing one way, it doesn't mean you should. Especially if your > applications success depends on people spamming OP_RETURN hashes of > every torrent they like. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 4243 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 17:44 ` Toby Padilla @ 2016-02-02 17:03 ` Peter Todd 2016-02-02 17:16 ` Pieter Wuille 0 siblings, 1 reply; 24+ messages in thread From: Peter Todd @ 2016-02-02 17:03 UTC (permalink / raw) To: Toby Padilla; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 840 bytes --] On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev wrote: > I really don't like the idea of policing other people's use of the > protocol. If a transaction pays its fee and has a greater than dust value, > it makes no sense to object to it. I'll point out that getting a BIP for a feature is *not* a hard requirement for deployment. I'd encourage you to go write up your BIP document, give it a non-numerical name for ease of reference, and lobby wallet vendors to implement it. While I'll refrain from commenting on whether or not I think the feature itself is a good idea, I really don't want people to get the impression that we're gatekeepers for how people choose use Bitcoin. -- https://petertodd.org 'peter'[:-1]@petertodd.org 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-02-02 17:03 ` Peter Todd @ 2016-02-02 17:16 ` Pieter Wuille 2016-02-02 17:27 ` Toby Padilla 2016-02-02 19:14 ` Luke Dashjr 0 siblings, 2 replies; 24+ messages in thread From: Pieter Wuille @ 2016-02-02 17:16 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1386 bytes --] On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > > On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev wrote: > > I really don't like the idea of policing other people's use of the > > protocol. If a transaction pays its fee and has a greater than dust value, > > it makes no sense to object to it. > > I'll point out that getting a BIP for a feature is *not* a hard > requirement for deployment. I'd encourage you to go write up your BIP > document, give it a non-numerical name for ease of reference, and lobby > wallet vendors to implement it. > > While I'll refrain from commenting on whether or not I think the feature > itself is a good idea, I really don't want people to get the impression > that we're gatekeepers for how people choose use Bitcoin. I'll go further: whatever people have commented here and elsewhere about this feature (myself included) are personal opinions on the feature itself, in the hope you take the concerns into account. These comments are not a judgement on whether this should be accepted as a BIP. Specifically, the BIP editor should accept a BIP even if he personally dislikes the ideas in it, when the criteria are satisfied. Beyond that, having a BIP accepted does not mean wallets have to implement it. That's up to the individual wallet authors/maintainers. -- Pieter [-- Attachment #2: Type: text/html, Size: 1693 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-02-02 17:16 ` Pieter Wuille @ 2016-02-02 17:27 ` Toby Padilla 2016-02-02 17:38 ` Peter Todd 2016-02-02 19:14 ` Luke Dashjr 1 sibling, 1 reply; 24+ messages in thread From: Toby Padilla @ 2016-02-02 17:27 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2577 bytes --] My BIP was ultimately accepted, it's number 74 https://github.com/bitcoin/bips/blob/master/bip-0074.mediawiki The editor did not agree with it, and I suspect would comment against it with his new proposed BIP :) I really appreciated that despite his vehement disagreement, he assigned the BIP. It seems like the process worked great. There was deep vetting, lots of back and forth and the editor put aside his personal opinions to accept the BIP. That being said... The mailing list is a problem. I'm still on moderation only. I have no idea if this message will go through and when it will go through. I totally understand the desire to keep the conversation level high, but when people who *are* whitelisted can quickly post multiple heated arguments against you (publicly) and you can't respond, then that starts to look very centralized and discouraging. I would agree with Gavin on the other thread about the proposed BIP commenting BIP. Putting more decision power behind a moderated mailing list and wiki doesn't seem like a good idea. On Tue, Feb 2, 2016 at 9:16 AM, Pieter Wuille <pieter.wuille@gmail•com> wrote: > On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > > > On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev > wrote: > > > I really don't like the idea of policing other people's use of the > > > protocol. If a transaction pays its fee and has a greater than dust > value, > > > it makes no sense to object to it. > > > > I'll point out that getting a BIP for a feature is *not* a hard > > requirement for deployment. I'd encourage you to go write up your BIP > > document, give it a non-numerical name for ease of reference, and lobby > > wallet vendors to implement it. > > > > While I'll refrain from commenting on whether or not I think the feature > > itself is a good idea, I really don't want people to get the impression > > that we're gatekeepers for how people choose use Bitcoin. > > I'll go further: whatever people have commented here and elsewhere about > this feature (myself included) are personal opinions on the feature itself, > in the hope you take the concerns into account. > > These comments are not a judgement on whether this should be accepted as a > BIP. Specifically, the BIP editor should accept a BIP even if he personally > dislikes the ideas in it, when the criteria are satisfied. > > Beyond that, having a BIP accepted does not mean wallets have to implement > it. That's up to the individual wallet authors/maintainers. > > -- > Pieter > [-- Attachment #2: Type: text/html, Size: 3494 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-02-02 17:27 ` Toby Padilla @ 2016-02-02 17:38 ` Peter Todd 2016-02-02 17:41 ` Toby Padilla 0 siblings, 1 reply; 24+ messages in thread From: Peter Todd @ 2016-02-02 17:38 UTC (permalink / raw) To: Toby Padilla; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 670 bytes --] On Tue, Feb 02, 2016 at 09:27:58AM -0800, Toby Padilla wrote: > The mailing list is a problem. I'm still on moderation only. I have no idea > if this message will go through and when it will go through. I totally > understand the desire to keep the conversation level high, but when people > who *are* whitelisted can quickly post multiple heated arguments against > you (publicly) and you can't respond, then that starts to look very > centralized and discouraging. Everyone is on moderation only in this mailing list, myself included. -- https://petertodd.org 'peter'[:-1]@petertodd.org 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-02-02 17:38 ` Peter Todd @ 2016-02-02 17:41 ` Toby Padilla 2016-02-02 19:12 ` Peter Todd 0 siblings, 1 reply; 24+ messages in thread From: Toby Padilla @ 2016-02-02 17:41 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1065 bytes --] Then the moderation is being unevenly applied. Luke commented against my BIP multiple times right after it was published but it took hours for my responses to go through and I had to track people down on IRC to ask about it: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/thread.html On Tue, Feb 2, 2016 at 9:38 AM, Peter Todd <pete@petertodd•org> wrote: > On Tue, Feb 02, 2016 at 09:27:58AM -0800, Toby Padilla wrote: > > The mailing list is a problem. I'm still on moderation only. I have no > idea > > if this message will go through and when it will go through. I totally > > understand the desire to keep the conversation level high, but when > people > > who *are* whitelisted can quickly post multiple heated arguments against > > you (publicly) and you can't respond, then that starts to look very > > centralized and discouraging. > > Everyone is on moderation only in this mailing list, myself included. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698 > [-- Attachment #2: Type: text/html, Size: 1756 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-02-02 17:41 ` Toby Padilla @ 2016-02-02 19:12 ` Peter Todd 2016-02-02 19:22 ` Toby Padilla 0 siblings, 1 reply; 24+ messages in thread From: Peter Todd @ 2016-02-02 19:12 UTC (permalink / raw) To: Toby Padilla; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1385 bytes --] On Tue, Feb 02, 2016 at 09:41:35AM -0800, Toby Padilla wrote: > Then the moderation is being unevenly applied. Luke commented against my > BIP multiple times right after it was published but it took hours for my > responses to go through and I had to track people down on IRC to ask about > it: > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/thread.html Keep in mind that actual human beings need to hit the approve button on your posts; quite likely Luke happened to respond when those humans were available, and you didn't. I personally had to do the exact same thing the other day with one of my posts. Moderation is an unfortunate thing to need, but this list is read by literally hundreds of busy people, many of whome have had to unsubscribe at various points in the past due to a lack of moderation. I wish we had a better solution, but that's what we have. We're also not along in using fairly agressive moderation, for example the cryptography@metzdowd•com mailing list where Bitcoin was originally announced uses manual approval moderation on all messages as well; there's also an unmoderated offshoot of it, cryptography@randombit•net (and feel free to start an unmoderated version of bitcoin-dev!) -- https://petertodd.org 'peter'[:-1]@petertodd.org 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-02-02 19:12 ` Peter Todd @ 2016-02-02 19:22 ` Toby Padilla 0 siblings, 0 replies; 24+ messages in thread From: Toby Padilla @ 2016-02-02 19:22 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2103 bytes --] I think it would be helpful to clarify this in the list documentation. Right now there's a bunch of conflicting information. https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev states: "*Greylisting Notice* Your first post to this list may be delayed by 5+ minutes due to Greylisting <https://en.wikipedia.org/wiki/Greylisting>. Subsequent posts should go through without delay." https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011591.html states: "Everyone starts moderated, and the mod bit gets cleared as they post. It gets set again if someone notices or reports a violation." On Tue, Feb 2, 2016 at 11:12 AM, Peter Todd <pete@petertodd•org> wrote: > On Tue, Feb 02, 2016 at 09:41:35AM -0800, Toby Padilla wrote: > > Then the moderation is being unevenly applied. Luke commented against my > > BIP multiple times right after it was published but it took hours for my > > responses to go through and I had to track people down on IRC to ask > about > > it: > > > > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/thread.html > > Keep in mind that actual human beings need to hit the approve button on > your posts; quite likely Luke happened to respond when those humans were > available, and you didn't. I personally had to do the exact same thing > the other day with one of my posts. > > Moderation is an unfortunate thing to need, but this list is read by > literally hundreds of busy people, many of whome have had to unsubscribe > at various points in the past due to a lack of moderation. I wish we had > a better solution, but that's what we have. We're also not along in > using fairly agressive moderation, for example the > cryptography@metzdowd•com mailing list where Bitcoin was originally > announced uses manual approval moderation on all messages as well; > there's also an unmoderated offshoot of it, cryptography@randombit•net > > (and feel free to start an unmoderated version of bitcoin-dev!) > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698 > [-- Attachment #2: Type: text/html, Size: 3828 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-02-02 17:16 ` Pieter Wuille 2016-02-02 17:27 ` Toby Padilla @ 2016-02-02 19:14 ` Luke Dashjr 1 sibling, 0 replies; 24+ messages in thread From: Luke Dashjr @ 2016-02-02 19:14 UTC (permalink / raw) To: bitcoin-dev, Pieter Wuille On Tuesday, February 02, 2016 5:16:30 PM Pieter Wuille via bitcoin-dev wrote: > On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" < > > bitcoin-dev@lists•linuxfoundation.org> wrote: > > On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev > > wrote: > > > I really don't like the idea of policing other people's use of the > > > protocol. If a transaction pays its fee and has a greater than dust > > value, > > > > it makes no sense to object to it. > > > > I'll point out that getting a BIP for a feature is *not* a hard > > requirement for deployment. I'd encourage you to go write up your BIP > > document, give it a non-numerical name for ease of reference, and lobby > > wallet vendors to implement it. > > > > While I'll refrain from commenting on whether or not I think the feature > > itself is a good idea, I really don't want people to get the impression > > that we're gatekeepers for how people choose use Bitcoin. > > I'll go further: whatever people have commented here and elsewhere about > this feature (myself included) are personal opinions on the feature itself, > in the hope you take the concerns into account. > > These comments are not a judgement on whether this should be accepted as a > BIP. Specifically, the BIP editor should accept a BIP even if he personally > dislikes the ideas in it, when the criteria are satisfied. > > Beyond that, having a BIP accepted does not mean wallets have to implement > it. That's up to the individual wallet authors/maintainers. Agree with both Peter and Pieter. Note that BIP 74 was assigned to this proposal last Friday. Luke ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 2:54 ` Toby Padilla 2016-01-26 2:56 ` Luke Dashjr @ 2016-01-26 14:37 ` Andreas Schildbach 2016-01-26 17:41 ` Toby Padilla 1 sibling, 1 reply; 24+ messages in thread From: Andreas Schildbach @ 2016-01-26 14:37 UTC (permalink / raw) To: bitcoin-dev Discussion about reasoning of OP_RETURN aside, I think your specification needs to be more precise/less ambiguous. Here is what BIP70 currently says about PaymentDetails.outputs: "one or more outputs where Bitcoins are to be sent. If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored)." As you can see, zero outputs are not ignored at all. They are used as an indication to allow the user to set an amount. So if you'd come up with one zero-amount OP_RETURN output, it would pop up an amount dialog. Certainly not what you want, right? On 01/26/2016 03:54 AM, Toby Padilla via bitcoin-dev wrote: > It looks like my draft hasn't been approved by the mailing list so if > anyone would like to read it it's also on Gist: > > https://gist.github.com/toby/9e71811d387923a71a53 > > Luke - As stated in the Github thread, I totally understand where you're > coming from but the fact is people *will* encode data on the blockchain > using worse methods. For all of the reasons that OP_RETURN was a good > idea in the first place, it's a good idea to support it in PaymentRequests. > > As for keyless - there's no way (that I know of) to construct a > transaction with a zero value OP_RETURN in an environment without keys > since the Payment Protocol is what defines the method for getting a > transaction from a server to a wallet. You can make a custom transaction > and execute it in the same application but without Payments there's no > way to move transactions between two applications. You need to build the > transaction where you execute it and thus need a key. > > > > On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr <luke@dashjr•org > <mailto:luke@dashjr•org>> wrote: > > This is a bad idea. OP_RETURN attachments are tolerated (not > encouraged!) for > the sake of the network, since the spam cannot be outright stopped. > If it > could be outright stopped, it would not be reasonable to allow > OP_RETURN. When > it comes to the payment protocol, however, changing the current > behaviour has > literally no benefit to the network at all, and the changes proposed > herein > are clearly detrimental since it would both encourage spam, and > potentially > make users unwilling (maybe even unaware) participants in it. For these > reasons, *I highly advise against publishing or implementing this > BIP, even if > the later mentioned issues are fixed.* > > On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote: > > An example might be a merchant that adds the hash of a plain text invoice > > to the checkout transaction. The merchant could construct the > > PaymentRequest with the invoice hash in an OP_RETURN and pass it to the > > customer's wallet. The wallet could then submit the transaction, including > > the invoice hash from the PaymentRequest. The wallet will have encoded a > > proof of purchase to the blockchain without the wallet developer having to > > coordinate with the merchant software or add features beyond this BIP. > > Such a "proof" is useless without wallet support. Even if you argue > it could > be implemented later on, it stands to reason that a scammer will > simply encode > garbage if the wallet is not checking the proof-of-purchase upfront. > To check > it, you would also need further protocol extensions which are not > included in > this draft. > > > Merchants and Bitcoin application developers benefit from this BIP because > > they can now construct transactions that include OP_RETURN data in a > > keyless environment. Again, prior to this BIP, transactions that used > > OP_RETURN (with zero value) needed to be constructed and executed in the > > same software. By separating the two concerns, this BIP allows merchant > > software to create transactions with OP_RETURN metadata on a server without > > storing public or private Bitcoin keys. This greatly enhances security > > where OP_RETURN applications currently need access to a private key to sign > > transactions. > > I don't see how this has any relevance to keys at all... > > > ## Specification > > > > The specification for this BIP is straightforward. BIP70 should be fully > > implemented with two changes: > > > > 1. Outputs where the script is an OP_RETURN and the value is zero should be > > accepted by the wallet. > > 2. Outputs where the script is an OP_RETURN and the value is greater than > > zero should be rejected. > > > > This is a change from the BIP70 requirement that all zero value outputs be > > ignored. > > This does not appear to be backward nor even forward compatible. Old > clients > will continue to use the previous behaviour and transparently omit any > commitments. New clients on the other hand will fail to include > commitments > produced by old servers. In other words, it is impossible to produce > software > compatible with both BIP 70 and this draft, and implementing either > would > result in severe consequences. > > > As it exists today, BIP70 allows for OP_RETURN data storage at the expense > > of permanently destroyed Bitcoin. > > It is better for the spammers to lose burned bitcoins, than have a > way to > avoid them. > > Luke > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 14:37 ` Andreas Schildbach @ 2016-01-26 17:41 ` Toby Padilla 2016-02-02 17:07 ` Peter Todd 0 siblings, 1 reply; 24+ messages in thread From: Toby Padilla @ 2016-01-26 17:41 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 6954 bytes --] The wording is a little strange and I think it *should* work as you state, but Bitcoin Core will actually reject any output that has zero value (even a single OP_RETURN output -- I just tested again to make sure). Here's the blocking code: https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentserver.cpp#L584 I agree that this should be made more clear in my BIP though, I'll clean up the language. On Tue, Jan 26, 2016 at 6:37 AM, Andreas Schildbach via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Discussion about reasoning of OP_RETURN aside, I think your > specification needs to be more precise/less ambiguous. > > Here is what BIP70 currently says about PaymentDetails.outputs: > > "one or more outputs where Bitcoins are to be sent. If the sum of > outputs.amount is zero, the customer will be asked how much to pay, and > the bitcoin client may choose any or all of the Outputs (if there are > more than one) for payment. If the sum of outputs.amount is non-zero, > then the customer will be asked to pay the sum, and the payment shall be > split among the Outputs with non-zero amounts (if there are more than > one; Outputs with zero amounts shall be ignored)." > > As you can see, zero outputs are not ignored at all. They are used as an > indication to allow the user to set an amount. So if you'd come up with > one zero-amount OP_RETURN output, it would pop up an amount dialog. > Certainly not what you want, right? > > > On 01/26/2016 03:54 AM, Toby Padilla via bitcoin-dev wrote: > > It looks like my draft hasn't been approved by the mailing list so if > > anyone would like to read it it's also on Gist: > > > > https://gist.github.com/toby/9e71811d387923a71a53 > > > > Luke - As stated in the Github thread, I totally understand where you're > > coming from but the fact is people *will* encode data on the blockchain > > using worse methods. For all of the reasons that OP_RETURN was a good > > idea in the first place, it's a good idea to support it in > PaymentRequests. > > > > As for keyless - there's no way (that I know of) to construct a > > transaction with a zero value OP_RETURN in an environment without keys > > since the Payment Protocol is what defines the method for getting a > > transaction from a server to a wallet. You can make a custom transaction > > and execute it in the same application but without Payments there's no > > way to move transactions between two applications. You need to build the > > transaction where you execute it and thus need a key. > > > > > > > > On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr <luke@dashjr•org > > <mailto:luke@dashjr•org>> wrote: > > > > This is a bad idea. OP_RETURN attachments are tolerated (not > > encouraged!) for > > the sake of the network, since the spam cannot be outright stopped. > > If it > > could be outright stopped, it would not be reasonable to allow > > OP_RETURN. When > > it comes to the payment protocol, however, changing the current > > behaviour has > > literally no benefit to the network at all, and the changes proposed > > herein > > are clearly detrimental since it would both encourage spam, and > > potentially > > make users unwilling (maybe even unaware) participants in it. For > these > > reasons, *I highly advise against publishing or implementing this > > BIP, even if > > the later mentioned issues are fixed.* > > > > On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote: > > > An example might be a merchant that adds the hash of a plain text > invoice > > > to the checkout transaction. The merchant could construct the > > > PaymentRequest with the invoice hash in an OP_RETURN and pass it > to the > > > customer's wallet. The wallet could then submit the transaction, > including > > > the invoice hash from the PaymentRequest. The wallet will have > encoded a > > > proof of purchase to the blockchain without the wallet developer > having to > > > coordinate with the merchant software or add features beyond this > BIP. > > > > Such a "proof" is useless without wallet support. Even if you argue > > it could > > be implemented later on, it stands to reason that a scammer will > > simply encode > > garbage if the wallet is not checking the proof-of-purchase upfront. > > To check > > it, you would also need further protocol extensions which are not > > included in > > this draft. > > > > > Merchants and Bitcoin application developers benefit from this BIP > because > > > they can now construct transactions that include OP_RETURN data in > a > > > keyless environment. Again, prior to this BIP, transactions that > used > > > OP_RETURN (with zero value) needed to be constructed and executed > in the > > > same software. By separating the two concerns, this BIP allows > merchant > > > software to create transactions with OP_RETURN metadata on a > server without > > > storing public or private Bitcoin keys. This greatly enhances > security > > > where OP_RETURN applications currently need access to a private > key to sign > > > transactions. > > > > I don't see how this has any relevance to keys at all... > > > > > ## Specification > > > > > > The specification for this BIP is straightforward. BIP70 should be > fully > > > implemented with two changes: > > > > > > 1. Outputs where the script is an OP_RETURN and the value is zero > should be > > > accepted by the wallet. > > > 2. Outputs where the script is an OP_RETURN and the value is > greater than > > > zero should be rejected. > > > > > > This is a change from the BIP70 requirement that all zero value > outputs be > > > ignored. > > > > This does not appear to be backward nor even forward compatible. Old > > clients > > will continue to use the previous behaviour and transparently omit > any > > commitments. New clients on the other hand will fail to include > > commitments > > produced by old servers. In other words, it is impossible to produce > > software > > compatible with both BIP 70 and this draft, and implementing either > > would > > result in severe consequences. > > > > > As it exists today, BIP70 allows for OP_RETURN data storage at the > expense > > > of permanently destroyed Bitcoin. > > > > It is better for the spammers to lose burned bitcoins, than have a > > way to > > avoid them. > > > > Luke > > > > > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 9290 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol 2016-01-26 17:41 ` Toby Padilla @ 2016-02-02 17:07 ` Peter Todd 0 siblings, 0 replies; 24+ messages in thread From: Peter Todd @ 2016-02-02 17:07 UTC (permalink / raw) To: Toby Padilla; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 805 bytes --] On Tue, Jan 26, 2016 at 09:41:01AM -0800, Toby Padilla via bitcoin-dev wrote: > The wording is a little strange and I think it *should* work as you state, > but Bitcoin Core will actually reject any output that has zero value (even > a single OP_RETURN output -- I just tested again to make sure). > > Here's the blocking code: > > https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentserver.cpp#L584 > > I agree that this should be made more clear in my BIP though, I'll clean up > the language. Note that because the dust limit is ignored completely for OP_RETURN outputs, you can work around this by setting the OP_RETURN outputs to 1 satoshi instead. -- https://petertodd.org 'peter'[:-1]@petertodd.org 000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-02-02 19:22 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-26 1:02 [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol Toby Padilla 2016-01-26 2:24 ` Luke Dashjr 2016-01-26 2:54 ` Toby Padilla 2016-01-26 2:56 ` Luke Dashjr 2016-01-26 3:01 ` Toby Padilla 2016-01-26 3:04 ` Luke Dashjr 2016-01-26 3:07 ` Toby Padilla 2016-01-26 3:12 ` Luke Dashjr 2016-01-26 3:17 ` Toby Padilla 2016-01-26 3:23 ` Luke Dashjr 2016-01-26 3:30 ` Toby Padilla 2016-01-26 16:19 ` Thomas Kerin 2016-01-26 17:44 ` Toby Padilla 2016-02-02 17:03 ` Peter Todd 2016-02-02 17:16 ` Pieter Wuille 2016-02-02 17:27 ` Toby Padilla 2016-02-02 17:38 ` Peter Todd 2016-02-02 17:41 ` Toby Padilla 2016-02-02 19:12 ` Peter Todd 2016-02-02 19:22 ` Toby Padilla 2016-02-02 19:14 ` Luke Dashjr 2016-01-26 14:37 ` Andreas Schildbach 2016-01-26 17:41 ` Toby Padilla 2016-02-02 17:07 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox