From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 45F19F84 for ; Tue, 26 Jan 2016 16:19:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 81793166 for ; Tue, 26 Jan 2016 16:19:21 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id l65so110977853wmf.1 for ; Tue, 26 Jan 2016 08:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=hTAnnfs35LmQ5tfOgi1C0Xj+EVY537c3FgFjzEKmiGQ=; b=TSBcTy0mNBhttdq5VWmTfrney+KtjDde2+fsr/6msQcy2GAl47eqgXfuUzMwd3eWZk KEWdmAlfGoLwXDthWfVmcRBtECUpMOjQIxRGpzD4ikWU+ypJnk2g9Ta1/qK9RtU1u75c 8vcWK9hd7oCWf8xVUPXs3lGLeJstI1hj6Y50mh0PuXvAfuN03uwQ2EBVT1chAa+Bs45W EzHKH2Vzwvp0B4xA9Y9YgkRF4Z3HEQ23D3YZeCiw/oYPt5b3rV4p5AOAodZBEydGICsT VcV/BRJsYKusE6Sw8kjRmLSqvS56OpfFNQF6fWMwKvPi5PKKblI3xbcFxhNsHZx+tVu8 8n/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=hTAnnfs35LmQ5tfOgi1C0Xj+EVY537c3FgFjzEKmiGQ=; b=XpFuYbKvToP1yFEIBHX29oSJ600ImHrrLF23ZJGqOQUISkpJzLjvhK/NTZ7aF8kHlC owmA1PCCei/2NVTnX+EjWsDq+HjzYaFs4ghkvbk2MOUTu+4OxKvjxONyB/psiyZxX327 zH/XQQk9mIqfPbGs9EgwsMlVZP4e9UNKaxD+WjxmbYRvHGR3jF+j/0dR682vVE3SKKYo G1w6HLadAKYpg6wAR5NfebI1JbFkLuL94jbExmJsaCQKSYmt8FrLpToN4XPfypYYy50y py5YmUHEQewyrA8JSfOoAe0hNNfqXf60xbyt6qWOax2WcmcM5Z7LYTa6ny+O/9RVP+4f js/w== X-Gm-Message-State: AG10YOQDKXLoloS2m0DnwV7DmDoZpPbvr4D9RGpvVgm+2g5cwv1WjBwPhkEgSBqG13OSZQ== X-Received: by 10.194.133.164 with SMTP id pd4mr28419609wjb.133.1453825160130; Tue, 26 Jan 2016 08:19:20 -0800 (PST) Received: from [192.168.192.50] ([109.255.154.81]) by smtp.gmail.com with ESMTPSA id 75sm4202737wmo.22.2016.01.26.08.19.19 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 08:19:19 -0800 (PST) To: bitcoin-dev@lists.linuxfoundation.org References: <201601260312.25248.luke@dashjr.org> <201601260323.14993.luke@dashjr.org> From: Thomas Kerin X-Enigmail-Draft-Status: N1110 Message-ID: <56A79C86.1030902@gmail.com> Date: Tue, 26 Jan 2016 16:19:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 26 Jan 2016 16:52:04 +0000 Subject: Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 16:19:22 -0000 On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote: > There are already valid use cases for OP_RETURN, it only makes sense > to fully support the feature. The only reason it's not supported now > is because the Payments protocol came before OP_RETURN. > You keep saying OP_RETURN is new, but it has been there from day one. It's purpose is causing script execution to end if encountered. Since then, we have tolerated putting pushdata's after it, and even raised the limit for the size of this data. It still doesn't mean every proposal has to be rewritten to cater for a new allowance we give OP_RETURN. > I've also been exploring this area with key.run > (https://git.playgrub.com/toby/keyrun) and want the functionality for > voting based on aggregate OP_RETURN value. *Not* to store data on the > blockchain, but to associate content pointers with transactions. > > I think that since OP_RETURN has already been approved and supported > it doesn't make much sense for me to have to re-defend it from scratch > here. I'd generally agree with Luke. Removing the cost of this hurts bitcoin, and ironically, your application to a certain degree. Just because you can do a thing one way, it doesn't mean you should. Especially if your applications success depends on people spamming OP_RETURN hashes of every torrent they like.