From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making OP_TRUE standard?
Date: Wed, 09 May 2018 23:07:49 -0400 [thread overview]
Message-ID: <YOfgzjDA6blassXxfjPMCeNNE77y-Cuyp8rtc2eOdjj6NVPSOrZfa4a6clTE96-Val-IBHKlQteiVrI9vObgFh9SphENQwLRbf2-AKqUXeM=@protonmail.com> (raw)
In-Reply-To: <201805100227.42217.luke@dashjr.org>
Good morning Luke and list,
> 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 understand the issue. On Lightning side, if this rule is used, we would have the two options below:
1. Commitment transactions always use the minimum feerate, but always have the above OP_TRUE output. Then to confirm the commitment transaction we would have to always spend the OP_TRUE output in CPFP transaction that pays for actual fee at unilateral close. This consumes more blockchain space for unilateral closes, as the second transaction is always mandatory.
2. We store two commitment transactions and associated paraphernalia (further transactions to claim the HTLCs). One version has a negotiated feerate without the OP_TRUE output. The other version has a slightly increased feerate and an OP_TRUE output as above. At unilateral close, we see if the negotiated feerate is enough and use that version if possible, but if not we RBF it with other version and in addition also CPFP on top. As mentioned before, we do not have transaction packages, so we need to RBF with higher feerate the commitment transaction, then submit the CPFP transaction which makes the first transaction valid to include in a block as per the rule. This requires that the fallback always have both an RBF bump and a CPFP bump.
>
>(Maybe it should be the first output
>
> instead of the last... Is there any legitimate reason one would have multiple
>
> such dummy outputs?)
It seems there are indeed none.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2018-05-10 3:07 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-08 23:57 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
2018-05-10 3:07 ` ZmnSCPxj [this message]
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='YOfgzjDA6blassXxfjPMCeNNE77y-Cuyp8rtc2eOdjj6NVPSOrZfa4a6clTE96-Val-IBHKlQteiVrI9vObgFh9SphENQwLRbf2-AKqUXeM=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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