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 E23CCF8C for ; Tue, 26 Jan 2016 03:01:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D89B63 for ; Tue, 26 Jan 2016 03:01:14 +0000 (UTC) Received: by mail-vk0-f49.google.com with SMTP id n1so84823925vkb.3 for ; Mon, 25 Jan 2016 19:01:14 -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=B47Zy3Kjx6cutT49iKWJ2dz705gEJNIQJcIWbv7iVds=; b=PwbLPcQfRMHrZWylecRDRtLqclXDHkk80cA+gBXzeYGhj3jlvHXdZrzDa5htkQJNev nAbHFZmlZLEGSlPJ2PlOmpD4zK1w6fh9AC9TNzG+n1V1gCcei0OvhiqDKM77L4UFr09Z z8ncy9awTetuMFMjUya7lhV3e3kGq+hPB2kOZij60o75PtA0t+4NbVO1p10ZyPOxzp7f GP7y5RosIvKnzenRLM5LVJyjvrFkaTHfTs7FA+TCw3oxd3315ItA/T1z+WkngZzoZXTA mjELnm6BNb8p162aQsD90CjmjbtT5AdulRDFOAyNjLPc8j0DZSRnppFnhtwruZZpJ8yz FW/w== 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=B47Zy3Kjx6cutT49iKWJ2dz705gEJNIQJcIWbv7iVds=; b=Q22m/YSKPU3eQyF5o2gmxf+EgjQZHBwI8bPHlARlFuUkKso2ni8ldJDskEzuI02jNM /4Vnixx6JN5flKpb+mfxpPnQbb24friN4CWKQ+E7kLNguY+pTS1RglmSKASwBYwAEugL Gw/vdb+gFKdKJKu/2o2gfq4siHGUs4creOcuWfFC2hS/j4zztxYJvnIH6A0xSTp0MeX7 bB0MLYrhZw7PMsY/5cMgd8u8V09I468fSpLdIdCLDM1/Usl9RgGV2sk8TyikbcztWdEv Gn/ouO8PL9Hc6gvirGWiagMXe205oj6EGCsEl/w4gNfyt6aUUDNtwZlJyr0i5U3QjUX+ 4iFA== X-Gm-Message-State: AG10YORSgbzkuQsTxYsNR/bsLPUVtWQVGtxfiLe6PNoSJDxOfDqxp9VfOkEcU3gOT0Fz2nxlhl6xqcaS9knezg== MIME-Version: 1.0 X-Received: by 10.31.52.73 with SMTP id b70mr11572895vka.16.1453777273326; Mon, 25 Jan 2016 19:01:13 -0800 (PST) Received: by 10.31.96.85 with HTTP; Mon, 25 Jan 2016 19:01:13 -0800 (PST) In-Reply-To: <201601260256.55378.luke@dashjr.org> References: <201601260224.16917.luke@dashjr.org> <201601260256.55378.luke@dashjr.org> Date: Mon, 25 Jan 2016 19:01:13 -0800 Message-ID: From: Toby Padilla To: Luke Dashjr Content-Type: multipart/alternative; boundary=001a1143fa4cf5937b052a33e51c 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:47 +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:01:15 -0000 --001a1143fa4cf5937b052a33e51c Content-Type: text/plain; charset=UTF-8 > 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. > 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. On Mon, Jan 25, 2016 at 6:56 PM, Luke Dashjr wrote: > On Tuesday, January 26, 2016 2:54:16 AM Toby Padilla wrote: > > Luke - As stated in the Github thread, I totally understand where you're > > coming from but the fact is people *will* encode data on the blockchain > > using worse methods. For all of the reasons that OP_RETURN was a good > idea > > in the first place, it's a good idea to support it in PaymentRequests. > > As I explained, none of those reasons apply to PaymentRequests. > > > As for keyless - there's no way (that I know of) to construct a > transaction > > with a zero value OP_RETURN in an environment without keys since the > > Payment Protocol is what defines the method for getting a transaction > from > > a server to a wallet. You can make a custom transaction and execute it in > > the same application but without Payments there's no way to move > > transactions between two applications. You need to build the transaction > > where you execute it and thus need a key. > > I have no idea what you are trying to say here. > > Luke > --001a1143fa4cf5937b052a33e51c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0As I explained,= none of those reasons apply to PaymentRequests.

As= they exist today PaymentRequests allow for essentially the same types of t= ransactions as non-PaymentRequest based transactions with the limitation th= at 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 u= sed with PaymentRequest transactions.

> I have no idea what you are trying to= say here.

I think if you think through how y= ou 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.

On Mon, Jan 25,= 2016 at 6:56 PM, Luke Dashjr <luke@dashjr.org> wrote:
On Tuesday, January 26, 2016 2:= 54:16 AM Toby Padilla wrote:
> Luke - As stated in the Github thread, I totally understand where you&= #39;re
> coming from but the fact is people *will* encode data on the blockchai= n
> using worse methods. For all of the reasons that OP_RETURN was a good = idea
> in the first place, it's a good idea to support it in PaymentReque= sts.

As I explained, none of those reasons apply to PaymentRequests.

> As for keyless - there's no way (that I know of) to construct a tr= ansaction
> with a zero value OP_RETURN in an environment without keys since the > Payment Protocol is what defines the method for getting a transaction = from
> a server to a wallet. You can make a custom transaction and execute it= in
> the same application but without Payments there's no way to move > transactions between two applications. You need to build the transacti= on
> where you execute it and thus need a key.

I have no idea what you are trying to say here.

Luke

--001a1143fa4cf5937b052a33e51c--