Toby Padilla [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-26 📝 Original message:The wording is a little ...
📅 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>;
📝 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>;