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 F2CD01013 for ; Tue, 26 Jan 2016 03:07:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 57DB163 for ; Tue, 26 Jan 2016 03:07:41 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id k1so84959188vkb.2 for ; Mon, 25 Jan 2016 19:07:41 -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=oBJw7CL3H9zML32Z0iEgEc3V4kmQpGMUfC9DZNd0tQA=; b=xbpzF/lgNul9BzuXW+Y/z+L7mWlCrCrE93zqiQIWaxJg6pfy+lSTEEqyUFNS+14gVF 1+Q06kxqnVBBqtnmLOX0FGJaZgSSuXOAV7WabglCnaN2eB4jD/S4fDXwcGN5/ErKV+2L ltWQmNf7ZiT+nNrypZCb0bMpYHUV9ch1d9ECDqAkbQRvLRGIZR30y3ngZ36270XOtvD7 jrlhPs3ysWpYcqc/ZksGtoTNb3Ue6q9tFC82QwGlgrdy3QI/YID7ceIT/DocrnJTy3HQ H1c+kfIFu5ftyFoAWuM0XjC8Wo1DRRac11nZcB08zarTkRpZeZUsD8rCrZkcXpSPVm1b 5Dnw== 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=oBJw7CL3H9zML32Z0iEgEc3V4kmQpGMUfC9DZNd0tQA=; b=bMF5Jp8UKjfm0J/n3l63SPNYpMugD0vVpk635bT4M4v0qNTt1C77ZdCT17W0N2ia8B OE3aKhUi6syg5PJF3omsB/uFqethKuXqQE0ai4+w9RagzCaB6QXY9afnPYiHPMWhjNZZ Q6br/ohLGJc7HCz/q+8OYoAsqQ4NXXZ0Ac3CFBNqizuDR3XguE6yUwyKUW70PkfmMedN FcAwtRjULYA0kwT3xULFzDVWHv3dy8ezRRknWncJfrb9Ay/SJimyiNZvWsvr1q16krFW 73Hwx+HqjWSRoP5uMgEte2TIyVeACJZj2QFlvdL5+4r/lLMNkotMzgcHAotTIFAg4jK3 SiDQ== X-Gm-Message-State: AG10YOQgiXi5S1KHPiTPSxwi7gHsmm/E3CCyQav6DJzEukFv6C03ZAiIWJRh6EnwhDWshsUZbIcbE6KFQqhgbQ== MIME-Version: 1.0 X-Received: by 10.31.56.202 with SMTP id f193mr13209576vka.134.1453777660348; Mon, 25 Jan 2016 19:07:40 -0800 (PST) Received: by 10.31.96.85 with HTTP; Mon, 25 Jan 2016 19:07:40 -0800 (PST) In-Reply-To: <201601260304.34013.luke@dashjr.org> References: <201601260256.55378.luke@dashjr.org> <201601260304.34013.luke@dashjr.org> Date: Mon, 25 Jan 2016 19:07:40 -0800 Message-ID: From: Toby Padilla To: Luke Dashjr Content-Type: multipart/alternative; boundary=001a114409de0710c5052a33fd25 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: Tue, 26 Jan 2016 03:14:55 +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:07:42 -0000 --001a114409de0710c5052a33fd25 Content-Type: text/plain; charset=UTF-8 > 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? > 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. On Mon, Jan 25, 2016 at 7:04 PM, Luke Dashjr wrote: > On Tuesday, January 26, 2016 3:01:13 AM Toby Padilla wrote: > > > As I explained, none of those reasons apply to PaymentRequests. > > > > As they exist today PaymentRequests allow for essentially the same types > of > > transactions as non-PaymentRequest based transactions with the limitation > > that OP_RETURN values must be greater. In that sense they're basically a > > pre-OP_RETURN environment. OP_RETURN serves a purpose and it can't be > used > > with PaymentRequest transactions. > > OP_RETURN can be used, but you need to burn coins. I don't see any benefit > to > changing that. It is better that coins are burned. > > > > I have no idea what you are trying to say here. > > > > I think if you think through how you would create an OP_RETURN > transaction > > today without this BIP you'll see you need a key at some point if you > want > > a zero value. > > You *always* need a key, to redeem inputs... regardless of values. > > Luke > --001a114409de0710c5052a33fd25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0I don't see= any benefit to
changing that. It is better that coins are burned.

I think this is our=C2=A0fundamental=C2=A0disagreement. People w= ill burn coins to encode data, why allow this when there's a better alt= ernative?

>=C2=A0You *always* need a key, to redeem inputs... regardless of v= alues.

<= div>Correct, but with BIP70 that key is in= the user's wallet and you can construct transactions on another machin= e (thus not needing a key during construction). Right now there's no wa= y to do the transaction construction on another machine with zero value OP_= RETURNs.

On Mon, Jan 25, 2016 at 7:04 PM, Luke Dashjr &l= t;luke@dashjr.org&= gt; wrote:
On Tue= sday, January 26, 2016 3:01:13 AM Toby Padilla wrote:
> > As I explained, none of those reasons apply to PaymentRequests. >
> As they exist today PaymentRequests allow for essentially the same typ= es of
> transactions as non-PaymentRequest based transactions with the limitat= ion
> that OP_RETURN values must be greater. In that sense they're basic= ally a
> pre-OP_RETURN environment. OP_RETURN serves a purpose and it can't= be used
> with PaymentRequest transactions.

OP_RETURN can be used, but you need to burn coins. I don't see a= ny benefit to
changing that. It is better that coins are burned.

> > I have no idea what you are trying to say here.
>
> I think if you think through how you would create an OP_RETURN transac= tion
> today without this BIP you'll see you need a key at some point if = you want
> a zero value.

You *always* need a key, to redeem inputs... regardless of values.
Luke

--001a114409de0710c5052a33fd25--