Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6818D900 for ; Thu, 10 May 2018 09:33:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC5A6683 for ; Thu, 10 May 2018 09:33:41 +0000 (UTC) Received: by mail-io0-f182.google.com with SMTP id f21-v6so2243386iob.13 for ; Thu, 10 May 2018 02:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:references:from:date:message-id:subject:to; bh=cFaD4NIezeKflDe29aRywxr0hz3enu2it5twtDSZV+8=; b=1a22CPjjB5ObtzjUWA6a8l10ZSnee4mUutxp4o9Ny4gt9EALTqatMT0saaBTI/stTY RBtKsTMtsoCCDLeDkaMAWm67C03iUdr+f12G+eSXQCDmdRD1HlXDgEDzKk/W8ThqWe55 rw4wkxOkIkScdeizy9qORVcKZdTWhpiFIqwbTQEfICNRjV75xr3qdMLLPQzBOoOHGDcm XSNi0mblJ81lKOF46qyN2W0g9172+t67rzCRmZRdfMPM2kPicJX01fPfkbRVB0yKBN23 cPeH55S1z//UH3REwWGVedIIRCEkBwe/frtya2hIUmsqK2+3t1AvAXDlxTFGQyCbnzWl aeZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to; bh=cFaD4NIezeKflDe29aRywxr0hz3enu2it5twtDSZV+8=; b=ZJm7AJb727MereC9m/B5t2gUWUwjkaNVDv/F1MSAurUXNc62/DGkD5V88rLiBO77cA r7845o3ed6HByxlpGaYilETFbr1oLbqzckntwTGlnShKhOyndyuJN9bkN+j8e+MTN4Lz FntNdgBCbMARqny6NePE0LjVwYs+sBu31+AMt1XVFJDqHk75phV+IWNGjmvZDLllfVss u/uij6nC0KZ7kMGWoTxwBjpI241dsg1iU5hZ0DOhhMdRtyy4lI11StqcDYXhzB5RkBkE J7QsM4BiPTf+d7fh/6nBeyAtfKUYB7lCkXUZZM/KsQnr5+AMQke6rG9MfyhlRxaRlErC /GqA== X-Gm-Message-State: ALKqPwfuVW5Y1rEV4Sq2OAovgp8P+iLPF/vFIk+k6spjtlOyH6x96Cio aajOc00sniohhg8yYrMyeysZIRh5p0M83/zRpfNQVA== X-Google-Smtp-Source: AB8JxZoAmNGeKkU8RvGsND1Vb0jr98yBASpM4G8A3a0Tyr2yySb2VeIiAGrSB9wPKdrm+YEbpfXY8tpCS+o7vbfkfKE= X-Received: by 2002:a6b:88e3:: with SMTP id s96-v6mr643927ioi.45.1525944821249; Thu, 10 May 2018 02:33:41 -0700 (PDT) MIME-Version: 1.0 References: <87po25lmzs.fsf@rustcorp.com.au> From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Thu, 10 May 2018 09:33:30 +0000 Message-ID: To: Rusty Russell , Bitcoin Dev Content-Type: multipart/alternative; boundary="000000000000048a81056bd6b7d0" X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FROM_EXCESS_BASE64, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Making OP_TRUE standard? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 09:33:42 -0000 --000000000000048a81056bd6b7d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But in prnciple I don't oppose to making it stardard, just want to understand what's the point. On Thu, 10 May 2018, 02:16 Jorge Tim=C3=B3n, wrote: > I fail to see what's the practical difference between sending to op_true > and giving the coins are fees directly. Perhaps it is ao obvious to you > that you forget to mention it? > If you did I honestlt missed it. > > On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hi all, >> >> The largest problem we are having today with the lightning >> protocol is trying to predict future fees. Eltoo solves this elegantly, >> but meanwhile we would like to include a 546 satoshi OP_TRUE output in >> commitment transactions so that we use minimal fees and then use CPFP >> (which can't be done at the moment due to CSV delays on outputs). >> >> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is >> non-standard. Are there any reasons not to suggest such a policy >> change? >> >> Thanks! >> Rusty. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --000000000000048a81056bd6b7d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But in prnciple I don't oppose to making it stardard,= just want to understand what's the point.

On Thu, 10 May 2018, 02:16 Jorge Tim=C3=B3n, <j= timon@jtimon.cc> wrote:
I fail to see what's the practical difference between sending= to op_true and giving the coins are fees directly. Perhaps it is ao obviou= s to you that you forget to mention it?=C2=A0
If you did I= honestlt missed it.

On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <bitcoin-dev@lists.linuxfo= undation.org> wrote:
Hi all,=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The largest problem we are having today with th= e lightning
protocol is trying to predict future fees.=C2=A0 Eltoo solves this elegantl= y,
but meanwhile we would like to include a 546 satoshi OP_TRUE output in
commitment transactions so that we use minimal fees and then use CPFP
(which can't be done at the moment due to CSV delays on outputs).

Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE= ' is
non-standard.=C2=A0 Are there any reasons not to suggest such a policy
change?

Thanks!
Rusty.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000048a81056bd6b7d0--