From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xq583-0001Vk-Md for bitcoin-development@lists.sourceforge.net; Sun, 16 Nov 2014 19:04:55 +0000 Received: from mail-wg0-f51.google.com ([74.125.82.51]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xq582-0004XY-9p for bitcoin-development@lists.sourceforge.net; Sun, 16 Nov 2014 19:04:55 +0000 Received: by mail-wg0-f51.google.com with SMTP id k14so3898178wgh.38 for ; Sun, 16 Nov 2014 11:04:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+TyQAx5fkmqoKiz96PgLCcwgxawFe1gVG/2xqQsIPdA=; b=NuZSKicLSumk1D7IPcvzS+M4EuVhkuxaFE+RjXrHruPAjEm8hYlw9hcVr3sSI7lWZo cNvEaMWNTocwmd1k9DnyjNcQSqgDfe5XFgiQ7rY6IWtnThCzxeBnU2FPgvwk1V9NdeTL Ym1pmpq4gePgntjcnfkavuO3Was85+FDd8n1roilaBsTfNXOgubPiG5uCbVdcjn54r05 Z34tEJ27CFMIgC3LO6/YQCSdT05cIixkIRa1QrWp94FIPrkm0+qEEZ6EL1JJoCp1YGkB eCD8Tik856EKgFZZRXX3sNvl6+7rTJCiXo37j6rWE7SGxqvBrJhabs+Ckj5LqOItC2FU p+5w== X-Gm-Message-State: ALoCoQlWljVuMCqNmU4uSsajhwb2NvYweZ1lS4gOy5ozOq7Z5tXvZBTHl0JUPV/wokqR/yS1gjed MIME-Version: 1.0 X-Received: by 10.194.192.2 with SMTP id hc2mr31497716wjc.75.1416164688255; Sun, 16 Nov 2014 11:04:48 -0800 (PST) Received: by 10.194.19.38 with HTTP; Sun, 16 Nov 2014 11:04:48 -0800 (PST) X-Originating-IP: [92.251.101.114] In-Reply-To: References: <201411161724.19573.luke@dashjr.org> Date: Sun, 16 Nov 2014 20:04:48 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Luke Dashjr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Xq582-0004XY-9p Cc: Bitcoin Dev , Flavien Charlon Subject: Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 19:04:55 -0000 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=3DqwyALGlG33Q Here's a generic working implementation: https://github.com/Blockstream/contracthashtool On Sun, Nov 16, 2014 at 7:44 PM, Jorge Tim=C3=B3n 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.