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 wrote:
> El 03/05/2014 03:55 p.m., Mark Friedenbach escribió:
>>
>> On 05/03/2014
On Sat, May 3, 2014 at 3:15 PM, Mark Friedenbach 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 + o
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
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 wrote:
> On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon
> wrote:
> > Outputs are above dust, inputs are not spent. OP_RETURN is supposed to be
> > standard in 0.9.1 and th
On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon
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
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 wrote:
>> I don't think such a pull request w
On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach 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 ca
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 bei
-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,
Can someone enlighten me on why the following transaction is being rejected
by Bitcoind 0.9.1 with error code -22 on Mainnet.
0100015594a8c1f84b926e84d70c3a3d5e517e0c12dc07cb1a774b587121fef08f91b86b48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f021
10 matches
Mail list logo
