From: "Jorge Timón" <jtimon@jtimon•cc>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>,
Flavien Charlon <flavien.charlon@coinprism•com>
Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
Date: Sun, 16 Nov 2014 20:04:48 +0100 [thread overview]
Message-ID: <CABm2gDoi1593ssoGN69E42c-N3s02yYKAqDEDA2m-e+6LqjpTQ@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDpBOtZB01Qj3Dc3dWSpG2zLr+VPYbnwrq8YVh8qfxMW5Q@mail.gmail.com>
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 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".
I'm aware that so called "proof of publication" is not equivalent to
timestamping, but I wasn't aware at the moment (and I don't think it's
very interesting but that's obviously only my opinion, "embedded
systems" developers will disagree).
[1] Here's a video explaining pay-to-contract in the context of
invoicing as a use case: https://www.youtube.com/watch?v=qwyALGlG33Q
Here's a generic working implementation:
https://github.com/Blockstream/contracthashtool
On Sun, Nov 16, 2014 at 7:44 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> 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 configure their own policy.
> In my opinion the best we can do is to make it easier for miners to
> implement their own policies by abstracting out those parts of the
> code. Pull requests like #5071 and #5114 are steps in that direction.
> So if you're interested in having more miners accepting 80 bytes
> OP_RETURN transactions, I suggest you invest some time reviewing and
> testing those PRs.
> Although this wasn't its main purpose, separating script/standard was
> also a little step in the same direction.
next prev parent reply other threads:[~2014-11-16 19:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-16 16:21 Flavien Charlon
2014-11-16 17:24 ` Luke Dashjr
2014-11-16 18:44 ` Jorge Timón
2014-11-16 19:04 ` Jorge Timón [this message]
2014-11-17 3:19 ` Alan Reiner
2014-11-17 10:35 ` Pieter Wuille
2014-11-17 11:20 ` Adam Back
2014-11-17 12:31 ` Chris Pacia
2014-11-17 12:39 ` Pieter Wuille
2014-11-18 22:33 ` Chris Pacia
2014-11-17 11:43 ` Flavien Charlon
2014-11-17 12:00 ` Pieter Wuille
2014-11-17 12:22 ` Jorge Timón
2014-11-18 17:47 ` Btc Drak
2014-11-19 0:46 ` Flavien Charlon
2014-11-17 10:30 ` Wladimir
2014-11-20 23:39 ` Jean-Pierre Rupp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABm2gDoi1593ssoGN69E42c-N3s02yYKAqDEDA2m-e+6LqjpTQ@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=flavien.charlon@coinprism$(echo .)com \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox