From: Christian Decker <decker.christian@gmail•com>
To: Johnson Lau <jl2012@xbt•hk>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
Date: Fri, 21 Dec 2018 12:15:37 +0100 [thread overview]
Message-ID: <87woo3uo4m.fsf@gmail.com> (raw)
In-Reply-To: <34A8F2C4-4732-4BE7-84F5-699B8D709D06@xbt.hk>
Johnson Lau <jl2012@xbt•hk> writes:
>> If we are using a trigger transaction the output of the setup
>> transaction would simply be `2 Au Bu 2 OP_CMS`. If we were to use a CLTV
>> in there we would not have an option to later attach a collaborative
>> close transaction that is valid immediately. Furthermore the timeout of
>> the CLTV would start ticking down the exact moment the setup transaction
>> is confirmed, hence whatever effect we are trying to achieve with that
>> timelock is limited, and we have a limit to the total lifetime of the
>> channel.
>
> CLTV is absolute locktime. Only CSV will have the “time ticking”
> issue, but that’s not used here. The required locktime <s> is many
> years in the past. To collaboratively close, you just need to sign
> with SIGHASH_ALL, with a locktime s+1.
Correct, we're using the CLTV here as a weird "compare two numbers that
are committed to in the signatures" operation, by using locktimes in the
past as you correctly point out.
> I think the use of OP_CSV (BIP112) is not needed here (although it
> doesn’t really harm except taking a few more bytes). All you need is
> to sign the settlement tx with a BIP68 relative locktime. Since this
> is a 2-of-2 branch, both parties need to agree with the relative
> locktime, so it is not necessary to restrict it through OP_CSV
I keep forgetting about BIP68, but you're right, that should be
sufficient for our use-case and would safe us a few bytes.
>> In the unilateral case, one party isn't there anymore, or refuses to
>> sign. So we take the trigger transaction (not signed with NOINPUT) and
>> the latest update_n transaction (signed with NOINPUT) and broadcast
>> them. Then we wait for the CSV timeout to expire, and then send the
>> settlement transaction, which gives us the enforcement of the latest
>> state that we agreed on. The chain sees a setup transaction and a
>> trigger transaction (normal transactions for all intents and purposes,
>> except for the output script of the trigger, but we can hide that with
>> taproot), followed by two more transactions which are signed with
>> NOINPUT. So 4 transactions in the worst case, of which 2 are special,
>> and 2 transactions in the good case.
>>
>>
>> So all in all I think it's a tradeoff between having a larger on-chain
>> footprint (4 txs vs 3 txs in the worst case) and putting a fixed
>> lifetime on the channel for the refund case if one party disappears
>> right away. We'll probably find out what acceptable parameters are for
>> these and where the cutoff points are :-)
>
> If no one is cheating (i.e. only the last update is broadcast), you
> always need only 3 txs. Think about this: every update tx could be a
> trigger tx, and you can settle directly on a trigger tx, so
> effectively you eliminate trigger tx.
I seem to keep mentally mixing different variants of the protocol in my
head. You are of course correct that the trigger and the update can be
considered the same, hence the 3 txs limit is right. Sorry for the
confusion :-(
next prev parent reply other threads:[~2018-12-21 11:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 12:32 Johnson Lau
2018-12-17 15:48 ` Ruben Somsen
2018-12-17 20:08 ` Johnson Lau
2018-12-18 10:48 ` Johnson Lau
2018-12-19 22:09 ` Christian Decker
2018-12-20 11:00 ` Johnson Lau
2018-12-20 17:20 ` Christian Decker
2018-12-20 18:04 ` Johnson Lau
2018-12-21 11:15 ` Christian Decker [this message]
2018-12-21 16:21 ` Johnson Lau
2018-12-21 11:40 ` ZmnSCPxj
2018-12-21 15:37 ` Johnson Lau
2018-12-22 14:25 ` ZmnSCPxj
2018-12-22 16:56 ` Johnson Lau
2018-12-24 11:47 ` ZmnSCPxj
2019-01-31 6:04 ` Anthony Towns
2019-02-01 9:36 ` ZmnSCPxj
2019-02-08 19:01 ` Jonas Nick
2019-02-09 10:01 ` Alejandro Ranchal Pedrosa
2019-02-09 16:48 ` Johnson Lau
2019-02-10 4:46 ` Anthony Towns
2019-02-09 16:54 ` Jonas Nick
2019-02-09 10:15 ` Johnson Lau
2019-02-09 16:52 ` Jonas Nick
2019-02-09 17:43 ` Johnson Lau
2019-02-19 19:04 ` Luke Dashjr
2019-02-19 19:22 ` Johnson Lau
2019-02-19 20:24 ` Luke Dashjr
2019-02-19 20:36 ` Johnson Lau
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=87woo3uo4m.fsf@gmail.com \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/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