On 11/16/2014 02:04 PM, Jorge Timón wrote:
> I remember people asking in #bitcoin-dev "Does anyone know any use
> case for greater sizes OP_RETURNs?" and me answering "I do not know of
> any use cases that require bigger sizes".
For reference, there was a brief time where I was irritated that the
As an aside, the decision to make it 40 bytes made sense because it is
enough for timestamping. In fact, you can do cheaper and even secret
(and thus impossible to censor by miners) timestamping using
pay-to-contract [1], which uses exactly 0 extra bytes in your
transaction and the blockchain.
I re
I agree with Luke, we can endlessly discuss the "best defaults" like
the default size allowed for OP_RETURN, minimum fees, anti-dust
policies, first-seen vs replace-by-fee, etc; but the fact is that
policies depend on miners. Unfortunately most miners and pools are
quite apathetic when it comes to
On Sunday, November 16, 2014 4:21:27 PM Flavien Charlon wrote:
> The data that can be embedded as part of an OP_RETURN output is currently
> limited to 40 bytes. It was initially supposed to be 80 bytes, but got
> reduced to 40 before the 0.9 release to err on the side of caution.
>
> After 9 mont
Hi,
The data that can be embedded as part of an OP_RETURN output is currently
limited to 40 bytes. It was initially supposed to be 80 bytes, but got
reduced to 40 before the 0.9 release to err on the side of caution.
After 9 months, it seems OP_RETURN did not lead to a blockchain
catastrophe, so
5 matches
Mail list logo
