* [Bitcoin-development] Bug with handing of OP_RETURN?
@ 2014-05-03 18:04 Flavien Charlon
2014-05-03 18:39 ` Peter Todd
2014-05-04 5:15 ` Jeff Garzik
0 siblings, 2 replies; 10+ messages in thread
From: Flavien Charlon @ 2014-05-03 18:04 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]
Can someone enlighten me on why the following transaction is being rejected
by Bitcoind 0.9.1 with error code -22 on Mainnet.
01000000015594a8c1f84b926e84d70c3a3d5e517e0c12dc07cb1a774b587121fef08f91b8000000006b48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c16ffff9b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cbffffffff0358020000000000001976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac00000000000000000a6a054f4101000102753d60860000000000001976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac00000000
Debug.log shows the following:
ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey
Here is the decoded transaction:
{
> "lock_time":0,
> "inputs":[
> {
> "prev_out":{
> "index":0,
>
> "hash":"b8918ff0fe2171584b771acb07dc120c7e515e3d3a0cd7846e924bf8c1a89455"
> },
>
> "script":"48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c16ffff9b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cb"
> }
> ],
> "vout_sz":3,
>
> "hash":"44130e812fa15f411c6accb739082eb81ecf074470cefb8e617ecf105690f6e1",
> "vin_sz":1,
> "out":[
> {
> "address":"12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv",
> "script_string":"OP_DUP OP_HASH160
> 0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG",
> "value":600,
> "script":"76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac"
> },
> {
> "script_string":"OP_RETURN 4f41010001 753d",
> "value":0,
> "script":"6a054f4101000102753d"
> },
> {
> "address":"12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv",
> "script_string":"OP_DUP OP_HASH160
> 0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG",
> "value":34400,
> "script":"76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac"
> }
> ],
> "size":245,
> "version":1
> }
>
Outputs are above dust, inputs are not spent. OP_RETURN is supposed to be
standard in 0.9.1 and the data is well below 40 bytes, so why is this being
rejected?
Thanks,
Flavien
[-- Attachment #2: Type: text/html, Size: 3648 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Bug with handing of OP_RETURN?
2014-05-03 18:04 [Bitcoin-development] Bug with handing of OP_RETURN? Flavien Charlon
@ 2014-05-03 18:39 ` Peter Todd
2014-05-03 18:55 ` Mark Friedenbach
2014-05-04 5:15 ` Jeff Garzik
1 sibling, 1 reply; 10+ messages in thread
From: Peter Todd @ 2014-05-03 18:39 UTC (permalink / raw)
To: Flavien Charlon, Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
The standard format ended up being exactly:
OP_RETURN <0 to 40-byte PUSHDATA>
You've split the data across two PUSHDATA's. The standard should have let the data be split up like that; pull requests accepted.
On 3 May 2014 13:04:52 GMT-05:00, Flavien Charlon <flavien.charlon@coinprism•com> wrote:
>Can someone enlighten me on why the following transaction is being
>rejected
>by Bitcoind 0.9.1 with error code -22 on Mainnet.
>
>01000000015594a8c1f84b926e84d70c3a3d5e517e0c12dc07cb1a774b587121fef08f91b8000000006b48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c16ffff9b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cbffffffff0358020000000000001976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac00000000000000000a6a054f4101000102753d60860000000000001976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac00000000
>
>
>Debug.log shows the following:
>
>ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey
>
>
>Here is the decoded transaction:
>
>{
>> "lock_time":0,
>> "inputs":[
>> {
>> "prev_out":{
>> "index":0,
>>
>>
>"hash":"b8918ff0fe2171584b771acb07dc120c7e515e3d3a0cd7846e924bf8c1a89455"
>> },
>>
>>
>"script":"48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c16ffff9b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cb"
>> }
>> ],
>> "vout_sz":3,
>>
>>
>"hash":"44130e812fa15f411c6accb739082eb81ecf074470cefb8e617ecf105690f6e1",
>> "vin_sz":1,
>> "out":[
>> {
>> "address":"12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv",
>> "script_string":"OP_DUP OP_HASH160
>> 0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG",
>> "value":600,
>>
>"script":"76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac"
>> },
>> {
>> "script_string":"OP_RETURN 4f41010001 753d",
>> "value":0,
>> "script":"6a054f4101000102753d"
>> },
>> {
>> "address":"12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv",
>> "script_string":"OP_DUP OP_HASH160
>> 0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG",
>> "value":34400,
>>
>"script":"76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac"
>> }
>> ],
>> "size":245,
>> "version":1
>> }
>>
>
>Outputs are above dust, inputs are not spent. OP_RETURN is supposed to
>be
>standard in 0.9.1 and the data is well below 40 bytes, so why is this
>being
>rejected?
>
>Thanks,
>Flavien
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>Instantly run your Selenium tests across 300+ browser/OS combos. Get
>unparalleled scalability from the best Selenium testing platform
>available.
>Simple to use. Nothing to install. Get started now for free."
>http://p.sf.net/sfu/SauceLabs
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQFQBAEBCAA6BQJTZTfsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhQHmCADIcIs8w0FCDslGpbg1
audI1fAg/XnZ2J/862egYLtV2P0ooQnQz6g4kA0YIQGJI5tqyr9NEB6q/FVeKT61
3ecs3YsRtUkXmum6Wnq7QUGjvyMQo5nwLx2b3kDYEvb9v+aAKoBNKdz1xmp7jxE3
6bCx9eBeRBmhDWp1Xrr3VQI7KEUx4BfUxaLioYnCvaSuPsU+QQfXPFc+9ypRRclc
ymAj0VRGRPe2LQMNjerG4DMH8MRd5LOXjUxYV3XO3LyKSKvM18Lte+16w/uU3uBV
msIMbWEgm/DXI5fLWL7MFuLIsFrPs9BzjZSSZA7zQvntLtlQWCMnGeXsozjK14ol
lUl8
=0kuQ
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Bug with handing of OP_RETURN?
2014-05-03 18:39 ` Peter Todd
@ 2014-05-03 18:55 ` Mark Friedenbach
2014-05-03 19:08 ` Gregory Maxwell
2014-05-04 12:07 ` Sergio Lerner
0 siblings, 2 replies; 10+ messages in thread
From: Mark Friedenbach @ 2014-05-03 18:55 UTC (permalink / raw)
To: bitcoin-development
I don't think such a pull request would be accepted. The point was to
minimize impact to the block chain. Each extras txout adds 9 bytes
minimum, with zero benefit over serializing the data together in a
single OP_RETURN.
On 05/03/2014 11:39 AM, Peter Todd wrote:
> The standard format ended up being exactly:
>
> OP_RETURN <0 to 40-byte PUSHDATA>
>
> You've split the data across two PUSHDATA's. The standard should have let the data be split up like that; pull requests accepted.
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Bug with handing of OP_RETURN?
2014-05-03 18:55 ` Mark Friedenbach
@ 2014-05-03 19:08 ` Gregory Maxwell
2014-05-03 19:15 ` Mark Friedenbach
2014-05-04 12:07 ` Sergio Lerner
1 sibling, 1 reply; 10+ messages in thread
From: Gregory Maxwell @ 2014-05-03 19:08 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Development
On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach <mark@monetize•io> wrote:
> I don't think such a pull request would be accepted. The point was to
> minimize impact to the block chain. Each extras txout adds 9 bytes
> minimum, with zero benefit over serializing the data together in a
> single OP_RETURN.
In this case it's not a question extra txouts, its a question of
additional pushes. Assuming you didn't get the push overhead for free,
the only issue I see with that off the cuff is extra complexity in the
IsStandard rule... but really, why? Your application already needs to
define the meaning of the data— what point is there in making your
hash commitment less uniform with the rest of the network?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Bug with handing of OP_RETURN?
2014-05-03 19:08 ` Gregory Maxwell
@ 2014-05-03 19:15 ` Mark Friedenbach
2014-05-04 13:25 ` Jeff Garzik
0 siblings, 1 reply; 10+ messages in thread
From: Mark Friedenbach @ 2014-05-03 19:15 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
Is it more complex? The current implementation using template matching
seems more complex than `if script.vch[0] == OP_RETURN &&
script.vch.size() < 42`
On 05/03/2014 12:08 PM, Gregory Maxwell wrote:
> On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach <mark@monetize•io> wrote:
>> I don't think such a pull request would be accepted. The point was to
>> minimize impact to the block chain. Each extras txout adds 9 bytes
>> minimum, with zero benefit over serializing the data together in a
>> single OP_RETURN.
>
> In this case it's not a question extra txouts, its a question of
> additional pushes. Assuming you didn't get the push overhead for free,
> the only issue I see with that off the cuff is extra complexity in the
> IsStandard rule... but really, why? Your application already needs to
> define the meaning of the data— what point is there in making your
> hash commitment less uniform with the rest of the network?
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Bug with handing of OP_RETURN?
2014-05-03 18:04 [Bitcoin-development] Bug with handing of OP_RETURN? Flavien Charlon
2014-05-03 18:39 ` Peter Todd
@ 2014-05-04 5:15 ` Jeff Garzik
2014-05-04 10:05 ` Flavien Charlon
1 sibling, 1 reply; 10+ messages in thread
From: Jeff Garzik @ 2014-05-04 5:15 UTC (permalink / raw)
To: Flavien Charlon; +Cc: Bitcoin Dev
On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon
<flavien.charlon@coinprism•com> wrote:
> Outputs are above dust, inputs are not spent. OP_RETURN is supposed to be
> standard in 0.9.1 and the data is well below 40 bytes, so why is this being
> rejected?
The carried data must all be contained within one pushdata.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Bug with handing of OP_RETURN?
2014-05-04 5:15 ` Jeff Garzik
@ 2014-05-04 10:05 ` Flavien Charlon
0 siblings, 0 replies; 10+ messages in thread
From: Flavien Charlon @ 2014-05-04 10:05 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 597 bytes --]
Thanks, that makes sense, just wanted to make sure this what the problem
was.
On Sun, May 4, 2014 at 6:15 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:
> On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon
> <flavien.charlon@coinprism•com> wrote:
> > Outputs are above dust, inputs are not spent. OP_RETURN is supposed to be
> > standard in 0.9.1 and the data is well below 40 bytes, so why is this
> being
> > rejected?
>
> The carried data must all be contained within one pushdata.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
[-- Attachment #2: Type: text/html, Size: 1118 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Bug with handing of OP_RETURN?
2014-05-03 18:55 ` Mark Friedenbach
2014-05-03 19:08 ` Gregory Maxwell
@ 2014-05-04 12:07 ` Sergio Lerner
2014-05-05 17:30 ` Jeff Garzik
1 sibling, 1 reply; 10+ messages in thread
From: Sergio Lerner @ 2014-05-04 12:07 UTC (permalink / raw)
To: bitcoin-development
El 03/05/2014 03:55 p.m., Mark Friedenbach escribió:
>
> On 05/03/2014 11:39 AM, Peter Todd wrote:
>> The standard format ended up being exactly:
>>
>> OP_RETURN <0 to 40-byte PUSHDATA>
>>
Please remember that the code actually does not implement the "standard
format" (at least the last time I checked it). Any opcode after
OP_RETURN is accepted:
For example: OP_RETURN OP_CHECKSIG
is accepted.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Bug with handing of OP_RETURN?
2014-05-03 19:15 ` Mark Friedenbach
@ 2014-05-04 13:25 ` Jeff Garzik
0 siblings, 0 replies; 10+ messages in thread
From: Jeff Garzik @ 2014-05-04 13:25 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Development
On Sat, May 3, 2014 at 3:15 PM, Mark Friedenbach <mark@monetize•io> wrote:
> Is it more complex? The current implementation using template matching
> seems more complex than `if script.vch[0] == OP_RETURN &&
> script.vch.size() < 42`
Not much more complex.
The template matches a two-chunk script with OP_RETURN + one pushdata
(or just OP_RETURN with no push). The pushdata is further limited to
MAX_OP_RETURN_RELAY bytes.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Bitcoin-development] Bug with handing of OP_RETURN?
2014-05-04 12:07 ` Sergio Lerner
@ 2014-05-05 17:30 ` Jeff Garzik
0 siblings, 0 replies; 10+ messages in thread
From: Jeff Garzik @ 2014-05-05 17:30 UTC (permalink / raw)
To: Sergio Lerner; +Cc: Bitcoin Dev
Correct, though that was somewhat unintentional. The pushed-data size
is limited to <= 40 bytes, and as non-pushdata opcodes carry zero
pushed data, they are accepted.
On Sun, May 4, 2014 at 8:07 AM, Sergio Lerner <sergiolerner@certimix•com> wrote:
> El 03/05/2014 03:55 p.m., Mark Friedenbach escribió:
>>
>> On 05/03/2014 11:39 AM, Peter Todd wrote:
>>> The standard format ended up being exactly:
>>>
>>> OP_RETURN <0 to 40-byte PUSHDATA>
>>>
> Please remember that the code actually does not implement the "standard
> format" (at least the last time I checked it). Any opcode after
> OP_RETURN is accepted:
>
> For example: OP_RETURN OP_CHECKSIG
>
> is accepted.
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-05-05 17:30 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-03 18:04 [Bitcoin-development] Bug with handing of OP_RETURN? Flavien Charlon
2014-05-03 18:39 ` Peter Todd
2014-05-03 18:55 ` Mark Friedenbach
2014-05-03 19:08 ` Gregory Maxwell
2014-05-03 19:15 ` Mark Friedenbach
2014-05-04 13:25 ` Jeff Garzik
2014-05-04 12:07 ` Sergio Lerner
2014-05-05 17:30 ` Jeff Garzik
2014-05-04 5:15 ` Jeff Garzik
2014-05-04 10:05 ` Flavien Charlon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox