public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Tom Trevethan <tom@commerceblock.com>
Subject: Re: [bitcoin-dev] Statechain implementations
Date: Mon, 30 Mar 2020 01:25:36 +0000	[thread overview]
Message-ID: <70epI8yeOu69uXQfxbyWEfrH7hYLzsx9CDIgA9gL_GlaqDEmshtP4Ogf6Dl7GH408GTPDveir1MKy1euEcPbOhJEtzjLbV9m506quXhnKOg=@protonmail.com> (raw)
In-Reply-To: <CAPv7Tjb5a5RbXH802m8qHoUKw-5rZV6nOw01z9+hx4yTJYV3Cw@mail.gmail.com>

Good morning Ruben,

> Hi ZmnSCPxj,
>
> > the current owner can ask the statechain entity to sign an alternative to the first stage, with 0 relative locktime
>
> Unless I am misunderstanding something, this seems to run into the problem that the original first stage transaction is already out there (and its relative timelock started ticking). There is no mechanism ensuring that the new tx will have precedence. And even if it did work, I doubt it's cleaner than doing a cooperative peg-out that simultaneously happens to peg back in, creating a brand new statechain UTXO with no history.


If:

* You are sure the old first stage tx has > 0 relative locktime.
* The replacement tx (which replaces the old first stage) has a 0 relative locktime.
  * The replacement tx redirects the funds to a new funding output for a (logically continuous, onchain new) statechain.

Then the replacement tx, having a smaller relative locktime than the old first stage, has precedence.
Indeed, having a *smaller* relative locktime is exactly the mechanism Decker-Wattenhofer uses.

So this is the state, with the kickoff having just been confirmed onchain:


    ***blockchain***
       [funding tx]->[kickoff tx]-+
         _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _
     offchain                     |
                                  +->[[ 7] stage]->[[ 0] stage]->[[14] stage]-> state outputs

Since the first stage is still "ticking" it is not yet confirmable onchain.

You ask the statechain to create an alternative, 0-relative-locktime, re-funding tx, and create a new mechanism:

    ***blockchain***
       [funding tx]->[kickoff tx]-+
         _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _
     offchain                     |
                                  +->[[ 7] stage]->[[ 0] stage]->[[14] stage]-> state outputs
                                 (OR)
                                  |
                                  +->[[ 0] funding tx]->[kickoff tx]->[[14] stage]->[[14] stage]->[[14] stage]->state outputs

Because it has a time advantage, this new re-funding tx has higher priority (and is the same mechanism Decker-Wattenhofer has anyway).

Regards,
ZmnSCPxj


  reply	other threads:[~2020-03-30  1:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 13:52 [bitcoin-dev] Statechain implementations Tom Trevethan
2020-03-26  1:20 ` ZmnSCPxj
2020-03-26  3:55 ` Albert
2020-03-26 12:36   ` Ruben Somsen
2020-03-26 17:12     ` Christian Decker
2020-03-26 17:17       ` Greg Sanders
2020-03-26 18:53         ` Ruben Somsen
2020-03-27  1:46           ` ZmnSCPxj
2020-03-27 15:12             ` Ruben Somsen
2020-03-28  2:20               ` ZmnSCPxj
2020-03-26 14:52   ` Bob McElrath
2020-03-27 17:10 ` Bob McElrath
2020-03-28  2:42   ` ZmnSCPxj
2020-03-28 17:38     ` Ruben Somsen
2020-03-28 17:42       ` Ruben Somsen
2020-03-30  1:25         ` ZmnSCPxj [this message]
2020-03-31 10:35 ` David A. Harding
2020-03-31 11:41   ` Tom Trevethan
2020-04-02 22:56     ` Tom Trevethan
2020-04-03 16:37       ` Nadav Kohen
2020-04-04 12:07         ` ZmnSCPxj
2020-04-05 14:17         ` Bob McElrath
2020-04-05 18:24           ` ZmnSCPxj
2020-04-05 21:25           ` Tom Trevethan
2020-05-07 14:54             ` Tom Trevethan

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='70epI8yeOu69uXQfxbyWEfrH7hYLzsx9CDIgA9gL_GlaqDEmshtP4Ogf6Dl7GH408GTPDveir1MKy1euEcPbOhJEtzjLbV9m506quXhnKOg=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=rsomsen@gmail.com \
    --cc=tom@commerceblock.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