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 258D6E9E for ; Tue, 26 Jan 2016 17:44:50 +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 40E46129 for ; Tue, 26 Jan 2016 17:44:49 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id e185so96024083vkb.1 for ; Tue, 26 Jan 2016 09:44:49 -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:cc :content-type; bh=InfDDaJYCGAzNsV56BM9FIS/fwJDp4Uhw+7tuvDMSss=; b=tbU91w48TkQCICLjj/ks1jurakwjtdm00XON3OsHSBXWdueGJZ9o22161umr09xjAW wBtaWGR4p8ftzwNu/X48eXcyMaebR62qv2hGzMRTArJc5l7bGcEKbigf4/8viSlBasIK fqrrRJmieA1g+lReA5swckjUX2VNRdECs1CcheYHUI2O94q0cSFPPKnpyR9AwQqOyxIQ 7FnztW3U4PFW0WVsmum+P52mLKAzLcfiAvuRX8vWPffGBU+rrYtKW7To1kCEhSyMMYjx pqc8C/Zj3Y8AGpRaK4Ed0wjJc7boN903tPu9P8x7Go27PB5jSNvOqEH2Vy4d0Mw7jONO 6O1Q== 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:cc:content-type; bh=InfDDaJYCGAzNsV56BM9FIS/fwJDp4Uhw+7tuvDMSss=; b=jXoANHDGJObs99w0jvjGR485ZVf3p6p5A6b39mjXGaFSuHFzXf0pRmXpEzy7U/NO8b zvnizEJaSn/e1/xZ9UgGobIktO6ra6w8iPlEPiujkgDMzuIE8XvvxQrvuWGcdDB4WSti kOIUXP16fnzkVeX57UEdj0gYpLrVQ3kfwc978fc/is3GUD5YsodChPlZjX/y1Ys2MuRu b3WOLg8qs7OXw98HPLQ3He+8jXg73S8O0Qzw3r2hGo1dnDqVnxix6mM9JNRsDFoC6OOY TjDh6FnqJ0k7QuKtDONAYAaCjwwzxFnFwjsXKuYY9Al9S3HKbIFyGi9NVwzauO97OPl4 NzNw== X-Gm-Message-State: AG10YOS0/ioBiyDNvftowax7Vko0zJ380pj2hvUxcU9bFOL4NHYLAjIyZZJrE087ivK6/0otmsi8JM7KCZuneQ== MIME-Version: 1.0 X-Received: by 10.31.0.136 with SMTP id 130mr14050426vka.139.1453830288391; Tue, 26 Jan 2016 09:44:48 -0800 (PST) Received: by 10.31.96.85 with HTTP; Tue, 26 Jan 2016 09:44:48 -0800 (PST) In-Reply-To: <56A79C86.1030902@gmail.com> References: <201601260312.25248.luke@dashjr.org> <201601260323.14993.luke@dashjr.org> <56A79C86.1030902@gmail.com> Date: Tue, 26 Jan 2016 09:44:48 -0800 Message-ID: From: Toby Padilla Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a113d9ccae7428f052a403d5e X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no 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 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 17:44:50 -0000 --001a113d9ccae7428f052a403d5e Content-Type: text/plain; charset=UTF-8 OP_RETURN was not part of isStandard? from day one. Once it was supported by Core it became necessary to actually support it, not try to support it in one part of the software and not in others. The whole reason it was supported is because without it people will use more heinous methods to encode data on the blockchain. There's no way to stop people from doing that, so this compromise seemed best for everyone. I think we should actually define "spam". To me a valid transaction someone willing pays for is never spam. Also PaymentRequests would be a very inefficient way to spam. It would be much easier to write a script to automatically create and submit transactions yourself. With PaymentRequests customers have to initiate the transaction and submit/pay for it one by one. What is actually the worst case scenario that those opposed to this are concerned about? That this takes off like wild fire and all of the sudden millions of people are using PaymentRequests and creating small transactions? That seems like a win for Bitcoin. It will help spread support for the Payment protocol and IF it becomes a problem it's because so many people are using it. In which case there's a very valid use case for Bitcoin that people are obviously excited about. I really don't like the idea of policing other people's use of the protocol. If a transaction pays its fee and has a greater than dust value, it makes no sense to object to it. On Tue, Jan 26, 2016 at 8:19 AM, Thomas Kerin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113d9ccae7428f052a403d5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OP_RETURN was not part of= isStandard? from day one. Once it was supported by Core it became necessar= y to actually support it, not try to support it in one part of the software= and not in others. The whole reason it was supported is because without it= people will use more heinous methods to encode data on the blockchain. The= re's no way to stop people from doing that, so this compromise seemed b= est for everyone.

I think we should actually define "spam". = To me a valid transaction someone willing pays for is never spam. Also Paym= entRequests would be a very inefficient way to spam. It would be much easie= r to write a script to automatically create and submit transactions yoursel= f. With PaymentRequests =C2=A0customers have to initiate the transaction an= d submit/pay for it one by one.

What is actually the worst case scenari= o that those opposed to this are concerned about? That this takes off like = wild fire and all of the sudden millions of people are using PaymentRequest= s and creating small transactions? That seems like a win for Bitcoin. It wi= ll help spread support for the Payment protocol and IF it becomes a problem= it's because so many people are using it. In which case there's a = very valid use case for Bitcoin that people are obviously excited about.

I really don't like the idea of policing other people's use of th= e protocol. If a transaction pays its fee and has a greater than dust value= , it makes no sense to object to it.

On Tue, Jan 26, 2016 at 8:19 AM, Thomas Kerin via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:

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 n= ow
> 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 fun= ctionality for
> voting based on aggregate OP_RETURN value. *Not* to store data on the<= br> > 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 scr= atch
> here.

I'd generally agree with Luke. Removing the cost of this hurts b= itcoin,
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<= br> applications success depends on people spamming OP_RETURN hashes of
every torrent they like.
___________________________________= ____________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a113d9ccae7428f052a403d5e--