public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Johnson Lau <jl2012@xbt.hk>
To: Christian Decker <decker.christian@gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
Date: Thu, 20 Dec 2018 19:00:53 +0800	[thread overview]
Message-ID: <195B4583-CE97-4C3A-9582-3C0C013CC1E9@xbt.hk> (raw)
In-Reply-To: <87efadp3rl.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]



> On 20 Dec 2018, at 6:09 AM, Christian Decker <decker.christian@gmail.com> wrote:
> 
> Ruben Somsen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>>
> writes:
> 
>> Hi Johnson,
>> 
>> The design considerations here seem similar to the ML discussion of
>> whether Graftroot should be optional [1].
>> 
>>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>> 
>> As far as I can tell it should be compatible with Statechains [2],
>> since it pretty much mirrors Eltoo in setup.
>> 
>> My understanding is somewhat lacking, so perhaps I am missing the
>> mark, but it is not completely clear to me how this affects
>> fungibility if taproot gets added and the setup and trigger tx for
>> Eltoo get combined into a single transaction. Would the NOINPUT
>> spending condition be hidden inside the taproot commitment?
> 
> I'm not aware of a way to combine the setup and trigger transaction. The
> trigger transaction was introduced in order to delay the start of the
> timeouts until a later time, to avoid having an absolute lifetime limit
> and having really huge timeout. If we were to combine the trigger
> transaction with the setup transaction (which is broadcast during
> channel creation), all of those timeouts would start counting down
> immediately, and we could just skip the trigger transaction
> altogether. It'd be more interesting to combine update and trigger
> transactions in a sort of cut-through combination, but that doesn't seem
> possible outside of Mimblewimble.
> 
> Cheers,
> Christian


Correct me if I’m wrong.

For the sake of simplicity, in the following I assume BIP118, 143, and 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible optimisations.

1. A and B are going to setup a channel.

2. They create one setup tx, with a setup output of the following script: <s> CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign

3. They create the update tx 0, spending the setup output with NOINPUT and locktime = s+1, to the update-0 output with the script:
IF 2 As0 Bs0 2 CHECKMULTISIG ELSE <s+1> CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF

4. They create the settlement tx 0, spending the update-0 output with As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs

5. They sign the setup tx and let it confirm

6. To update, they create the update tx 1, spending the setup output with NOINPUT and locktime = s+2, to the update-1 output with the script:
IF 2 As1 Bs1 2 CHECKMULTISIG ELSE <s+2> CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF
and create the settlement tx 1, spending the update-1 output with As1 and Bs1 using relative-locktime, with 2 settlement outputs

7. To close the channel, broadcast update tx 1. Wait for several confirmations. And broadcast settlement-tx-1



[-- Attachment #2: Type: text/html, Size: 15958 bytes --]

  reply	other threads:[~2018-12-20 11:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-13 12:32 [bitcoin-dev] Safer NOINPUT with output tagging 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 [this message]
2018-12-20 17:20       ` Christian Decker
2018-12-20 18:04         ` Johnson Lau
2018-12-21 11:15           ` Christian Decker
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=195B4583-CE97-4C3A-9582-3C0C013CC1E9@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=decker.christian@gmail.com \
    /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