Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 97CC1E8E for ; Tue, 26 Jan 2016 03:17:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F202B63 for ; Tue, 26 Jan 2016 03:17:12 +0000 (UTC) Received: by mail-vk0-f46.google.com with SMTP id e185so84901671vkb.1 for ; Mon, 25 Jan 2016 19:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cUvfx6MaJibBNJbAAylxg7fvN49QAkTncVTVeMy0CPA=; b=B4nsy3FsmF0LOWrquVqhVOyBGqnObh9qw/shbO/2TPp0pfE3GFTzAtR412AgAcoOtx 104qwgGF2WYuq+phTjM9YeEVHd76bPdI9ZChpMVtlV+NOZN35V9M+5kea7PCwRf2Quv1 bI7aXyo/FJb1YoPEutJoTklxinCn3y6R+cB34Jz1qpWKRv/2b6beF6FDzKynRzWyAwq+ y7NXG+pgUXAfykS/lqNZ+czL/zhRz5It8vC0p/9HEP7fmV+rCP3MXx7QI4u9fqY9UjVT BTbN7YQOJX97CazRidtppu0LIDKXcgzVZVxEjNdX7gQMntdmGn/ADGhqslAGLdzlRqWA rg6w== 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; bh=cUvfx6MaJibBNJbAAylxg7fvN49QAkTncVTVeMy0CPA=; b=mjrz6V6QwqpNWZM9cTQqP/VVFLC3lOlX2QEnj8k9wEjkrtBiDg1a1T3coMTrqj3HKm i1OdTXiOX9zcrfw0CqSSf3923GhrhZfgGMpkMr/hqhCsAmXlImNM9XcEfpkpbhsA+EDg GLi70hvJM3AySJXlFM70hhkxDIZd+kRTvlXitlCEwyq1+QEj/6lS0ed7S+nDDWxKTryf fp4ZHsozGZz/POTzjX0H1t9wjLQs4T5GQr9irCoUAHmxRM9CX82eHZRxBXk1DpVBW100 NZgvpwN9WqPz2TTorhZrfUwhDlPB1uwieoo0b+eK91sWp2Sy94UjFdwrle7zLS/L4tlm NTkg== X-Gm-Message-State: AG10YOTCkwAtIWlGbH6CQw+gaoDVkLdib6c4UNn2vYddVROVXp4GiPxRpQybYh7nBOSwAW/AFBssCnq2cEJrcw== MIME-Version: 1.0 X-Received: by 10.31.9.72 with SMTP id 69mr11531504vkj.126.1453778232121; Mon, 25 Jan 2016 19:17:12 -0800 (PST) Received: by 10.31.96.85 with HTTP; Mon, 25 Jan 2016 19:17:12 -0800 (PST) In-Reply-To: <201601260312.25248.luke@dashjr.org> References: <201601260304.34013.luke@dashjr.org> <201601260312.25248.luke@dashjr.org> Date: Mon, 25 Jan 2016 19:17:12 -0800 Message-ID: From: Toby Padilla To: Luke Dashjr Content-Type: multipart/alternative; boundary=001a11440dfa1ba168052a341fc8 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, URIBL_SBL 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: Wed, 27 Jan 2016 00:49:29 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org 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 03:17:13 -0000 --001a11440dfa1ba168052a341fc8 Content-Type: text/plain; charset=UTF-8 I don't think every application of OP_RETURN could be classified as "spam". I also don't think burning the value is going to dissuade anyone from going down that route. I don't think lost value is better for anyone. On Mon, Jan 25, 2016 at 7:12 PM, Luke Dashjr wrote: > On Tuesday, January 26, 2016 3:07:40 AM Toby Padilla wrote: > > > I don't see any benefit to changing that. It is better that coins are > > > burned. > > > > I think this is our fundamental disagreement. People will burn coins to > > encode data, why allow this when there's a better alternative? > > My point is that there isn't a better alternative. The coins being burned, > is > strictly better than it being gratis. > > > > You *always* need a key, to redeem inputs... regardless of values. > > > > Correct, but with BIP70 that key is in the user's wallet and you can > > construct transactions on another machine (thus not needing a key during > > construction). Right now there's no way to do the transaction > construction > > on another machine with zero value OP_RETURNs. > > This is also a good thing. Spam should not be made easier or cheaper. > > Luke > --001a11440dfa1ba168052a341fc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think every application of OP_RETURN could be = classified as "spam". I also don't think burning the value is= going to dissuade anyone from going down that route. I don't think los= t value is better for anyone.

On Mon, Jan 25, 2016 at 7:12 PM, Luke Dashjr <luke@dashjr.= org> wrote:
On Tuesday, January 26, 2016 3:07:40 AM Toby Padilla wrote:
> > I don't see any benefit to changing that. It is better that c= oins are
> > burned.
>
> I think this is our fundamental disagreement. People will burn coins t= o
> encode data, why allow this when there's a better alternative?

My point is that there isn't a better alternative. The coins bei= ng burned, is
strictly better than it being gratis.

> > You *always* need a key, to redeem inputs... regardless of values= .
>
> Correct, but with BIP70 that key is in the user's wallet and you c= an
> construct transactions on another machine (thus not needing a key duri= ng
> construction). Right now there's no way to do the transaction cons= truction
> on another machine with zero value OP_RETURNs.

This is also a good thing. Spam should not be made easier or cheaper= .

Luke

--001a11440dfa1ba168052a341fc8--