📅 Original date posted:2016-01-26
📝 Original message: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 at 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 at dashjr.org
> > <mailto:luke at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160126/ccf44462/attachment-0001.html>;
Toby Padilla [ARCHIVE] /
npub1m9…huekt
2023-06-07 17:48:08
in reply to nevent1q…zrlf
Author Public Key
npub1m99yqj0pat7mwzsdczyn28z84ce47adngzqp9kzft4gc3xke52fqqhuektPublished at
2023-06-07 17:48:08Event JSON
{
"id": "6fe3c540449f647d864984ac514d32188a0476b9705bd2ac4074de149d1f1fde",
"pubkey": "d94a4049e1eafdb70a0dc089351c47ae335f75b3408012d8495d51889ad9a292",
"created_at": 1686160088,
"kind": 1,
"tags": [
[
"e",
"368032d333e01794ac3e7b97c278de084cce6e6228857d943836fb1a934a5739",
"",
"root"
],
[
"e",
"89ae6b5c798b33921ef7d87422bbf7b716256e9b6ecb84f01c67afbed6581f34",
"",
"reply"
],
[
"p",
"3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc"
]
],
"content": "📅 Original date posted:2016-01-26\n📝 Original message:The wording is a little strange and I think it *should* work as you state,\nbut Bitcoin Core will actually reject any output that has zero value (even\na single OP_RETURN output -- I just tested again to make sure).\n\nHere's the blocking code:\n\nhttps://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentserver.cpp#L584\n\nI agree that this should be made more clear in my BIP though, I'll clean up\nthe language.\n\nOn Tue, Jan 26, 2016 at 6:37 AM, Andreas Schildbach via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Discussion about reasoning of OP_RETURN aside, I think your\n\u003e specification needs to be more precise/less ambiguous.\n\u003e\n\u003e Here is what BIP70 currently says about PaymentDetails.outputs:\n\u003e\n\u003e \"one or more outputs where Bitcoins are to be sent. If the sum of\n\u003e outputs.amount is zero, the customer will be asked how much to pay, and\n\u003e the bitcoin client may choose any or all of the Outputs (if there are\n\u003e more than one) for payment. If the sum of outputs.amount is non-zero,\n\u003e then the customer will be asked to pay the sum, and the payment shall be\n\u003e split among the Outputs with non-zero amounts (if there are more than\n\u003e one; Outputs with zero amounts shall be ignored).\"\n\u003e\n\u003e As you can see, zero outputs are not ignored at all. They are used as an\n\u003e indication to allow the user to set an amount. So if you'd come up with\n\u003e one zero-amount OP_RETURN output, it would pop up an amount dialog.\n\u003e Certainly not what you want, right?\n\u003e\n\u003e\n\u003e On 01/26/2016 03:54 AM, Toby Padilla via bitcoin-dev wrote:\n\u003e \u003e It looks like my draft hasn't been approved by the mailing list so if\n\u003e \u003e anyone would like to read it it's also on Gist:\n\u003e \u003e\n\u003e \u003e https://gist.github.com/toby/9e71811d387923a71a53\n\u003e \u003e\n\u003e \u003e Luke - As stated in the Github thread, I totally understand where you're\n\u003e \u003e coming from but the fact is people *will* encode data on the blockchain\n\u003e \u003e using worse methods. For all of the reasons that OP_RETURN was a good\n\u003e \u003e idea in the first place, it's a good idea to support it in\n\u003e PaymentRequests.\n\u003e \u003e\n\u003e \u003e As for keyless - there's no way (that I know of) to construct a\n\u003e \u003e transaction with a zero value OP_RETURN in an environment without keys\n\u003e \u003e since the Payment Protocol is what defines the method for getting a\n\u003e \u003e transaction from a server to a wallet. You can make a custom transaction\n\u003e \u003e and execute it in the same application but without Payments there's no\n\u003e \u003e way to move transactions between two applications. You need to build the\n\u003e \u003e transaction where you execute it and thus need a key.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr \u003cluke at dashjr.org\n\u003e \u003e \u003cmailto:luke at dashjr.org\u003e\u003e wrote:\n\u003e \u003e\n\u003e \u003e This is a bad idea. OP_RETURN attachments are tolerated (not\n\u003e \u003e encouraged!) for\n\u003e \u003e the sake of the network, since the spam cannot be outright stopped.\n\u003e \u003e If it\n\u003e \u003e could be outright stopped, it would not be reasonable to allow\n\u003e \u003e OP_RETURN. When\n\u003e \u003e it comes to the payment protocol, however, changing the current\n\u003e \u003e behaviour has\n\u003e \u003e literally no benefit to the network at all, and the changes proposed\n\u003e \u003e herein\n\u003e \u003e are clearly detrimental since it would both encourage spam, and\n\u003e \u003e potentially\n\u003e \u003e make users unwilling (maybe even unaware) participants in it. For\n\u003e these\n\u003e \u003e reasons, *I highly advise against publishing or implementing this\n\u003e \u003e BIP, even if\n\u003e \u003e the later mentioned issues are fixed.*\n\u003e \u003e\n\u003e \u003e On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote:\n\u003e \u003e \u003e An example might be a merchant that adds the hash of a plain text\n\u003e invoice\n\u003e \u003e \u003e to the checkout transaction. The merchant could construct the\n\u003e \u003e \u003e PaymentRequest with the invoice hash in an OP_RETURN and pass it\n\u003e to the\n\u003e \u003e \u003e customer's wallet. The wallet could then submit the transaction,\n\u003e including\n\u003e \u003e \u003e the invoice hash from the PaymentRequest. The wallet will have\n\u003e encoded a\n\u003e \u003e \u003e proof of purchase to the blockchain without the wallet developer\n\u003e having to\n\u003e \u003e \u003e coordinate with the merchant software or add features beyond this\n\u003e BIP.\n\u003e \u003e\n\u003e \u003e Such a \"proof\" is useless without wallet support. Even if you argue\n\u003e \u003e it could\n\u003e \u003e be implemented later on, it stands to reason that a scammer will\n\u003e \u003e simply encode\n\u003e \u003e garbage if the wallet is not checking the proof-of-purchase upfront.\n\u003e \u003e To check\n\u003e \u003e it, you would also need further protocol extensions which are not\n\u003e \u003e included in\n\u003e \u003e this draft.\n\u003e \u003e\n\u003e \u003e \u003e Merchants and Bitcoin application developers benefit from this BIP\n\u003e because\n\u003e \u003e \u003e they can now construct transactions that include OP_RETURN data in\n\u003e a\n\u003e \u003e \u003e keyless environment. Again, prior to this BIP, transactions that\n\u003e used\n\u003e \u003e \u003e OP_RETURN (with zero value) needed to be constructed and executed\n\u003e in the\n\u003e \u003e \u003e same software. By separating the two concerns, this BIP allows\n\u003e merchant\n\u003e \u003e \u003e software to create transactions with OP_RETURN metadata on a\n\u003e server without\n\u003e \u003e \u003e storing public or private Bitcoin keys. This greatly enhances\n\u003e security\n\u003e \u003e \u003e where OP_RETURN applications currently need access to a private\n\u003e key to sign\n\u003e \u003e \u003e transactions.\n\u003e \u003e\n\u003e \u003e I don't see how this has any relevance to keys at all...\n\u003e \u003e\n\u003e \u003e \u003e ## Specification\n\u003e \u003e \u003e\n\u003e \u003e \u003e The specification for this BIP is straightforward. BIP70 should be\n\u003e fully\n\u003e \u003e \u003e implemented with two changes:\n\u003e \u003e \u003e\n\u003e \u003e \u003e 1. Outputs where the script is an OP_RETURN and the value is zero\n\u003e should be\n\u003e \u003e \u003e accepted by the wallet.\n\u003e \u003e \u003e 2. Outputs where the script is an OP_RETURN and the value is\n\u003e greater than\n\u003e \u003e \u003e zero should be rejected.\n\u003e \u003e \u003e\n\u003e \u003e \u003e This is a change from the BIP70 requirement that all zero value\n\u003e outputs be\n\u003e \u003e \u003e ignored.\n\u003e \u003e\n\u003e \u003e This does not appear to be backward nor even forward compatible. Old\n\u003e \u003e clients\n\u003e \u003e will continue to use the previous behaviour and transparently omit\n\u003e any\n\u003e \u003e commitments. New clients on the other hand will fail to include\n\u003e \u003e commitments\n\u003e \u003e produced by old servers. In other words, it is impossible to produce\n\u003e \u003e software\n\u003e \u003e compatible with both BIP 70 and this draft, and implementing either\n\u003e \u003e would\n\u003e \u003e result in severe consequences.\n\u003e \u003e\n\u003e \u003e \u003e As it exists today, BIP70 allows for OP_RETURN data storage at the\n\u003e expense\n\u003e \u003e \u003e of permanently destroyed Bitcoin.\n\u003e \u003e\n\u003e \u003e It is better for the spammers to lose burned bitcoins, than have a\n\u003e \u003e way to\n\u003e \u003e avoid them.\n\u003e \u003e\n\u003e \u003e Luke\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160126/ccf44462/attachment-0001.html\u003e",
"sig": "df781753c6071f3716b16e767cd6f1db7ffef1cbfd63a83477a8a5962ed944ac50c510cd10143559c50ba85ed6b7a90659d3fd053f976b0c58f611aeffedfa10"
}