public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [bitcoin-dev] Making OP_TRUE standard?
Date: Thu, 10 May 2018 02:27:41 +0000	[thread overview]
Message-ID: <201805100227.42217.luke@dashjr.org> (raw)
In-Reply-To: <87po25lmzs.fsf@rustcorp.com.au>

An OP_TRUE-only script with a low value seems like a good example of where the 
weight doesn't reflect the true cost: it uses a UTXO forever, while only 
costing a weight of 4.

I like Johnson's idea to have some template (perhaps OP_2-only, to preserve 
expected behaviour of OP_TRUE-only) that when combined with a 0-value is 
always valid only if spent in the same block.

I wonder if it would make sense to actually tie it to a transaction version 
bit, such that when the bit is set, the transaction is serialised with +1 on 
the output count and 00000000000000000181 is simply injected into the 
transaction hashing... But for now, simply having a consensus rule that a bit 
MUST be set for the expected behaviour, and the bit may ONLY be set when the 
last output is exactly 00000000000000000181, would allow us to code the 
transaction serialisation up later. (Maybe it should be the first output 
instead of the last... Is there any legitimate reason one would have multiple 
such dummy outputs?)

Luke


On Tuesday 08 May 2018 23:57:11 Rusty Russell via bitcoin-dev 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



  parent reply	other threads:[~2018-05-10  2:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-08 23:57 [bitcoin-dev] Making OP_TRUE standard? Rusty Russell
2018-05-09  0:24 ` Olaoluwa Osuntokun
2018-05-09  3:02   ` ZmnSCPxj
2018-05-10  2:08   ` Rusty Russell
2018-05-09 17:56 ` Johnson Lau
2018-05-09 19:27   ` Peter Todd
2018-05-09 20:19     ` Johnson Lau
2018-05-09 20:59       ` Peter Todd
2018-05-09 22:06   ` Olaoluwa Osuntokun
2018-05-10  2:06   ` Rusty Russell
2018-05-10  2:27 ` Luke Dashjr [this message]
2018-05-10  3:07   ` ZmnSCPxj
2018-05-15  1:22   ` ZmnSCPxj
2018-05-17  2:44   ` Rusty Russell
2018-05-17 10:28     ` ZmnSCPxj
2018-05-17 17:35       ` Christian Decker
2018-05-17 20:06     ` Jim Posen
2018-05-21  3:44       ` Rusty Russell
2018-05-21  3:56         ` Peter Todd
2018-05-30  2:47           ` Rusty Russell
2018-05-31  2:47             ` Rusty Russell
2018-05-21 14:20         ` Russell O'Connor
2018-05-10  9:33 ` Jorge Timón
2018-05-10  9:33   ` Jorge Timón
2018-05-10  9:43   ` Luke Dashjr
2018-05-11  2:44     ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201805100227.42217.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox