[Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Flavien Charlon
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

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Luke Dashjr
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 months,

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Jorge Timón
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

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Jorge Timón
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: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-16 Thread Alan Reiner
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 size