public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Greg Sanders <gsanders87@gmail.com>
To: Christian Decker <decker.christian@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: tom@commerceblock.com
Subject: Re: [bitcoin-dev] Statechain implementations
Date: Thu, 26 Mar 2020 13:17:13 -0400	[thread overview]
Message-ID: <CAB3F3Dt0z5bDMpzRGGJxJV8KpCk_4XGF23MGmYVkLppRbG7Wnw@mail.gmail.com> (raw)
In-Reply-To: <87369v6nw3.fsf@gmail.com>

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

> Wouldn't that result in a changing pubkey at each update, and thus
require an onchain move to be committed?

Suggestion was in line with original proposal where no keys are changing
ever, just not presupposing existence of MuSig.

On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Ruben Somsen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> writes:
> > Regarding modification 1, I agree with ZmnSCPxj that
> > Decker-Wattenhofer is your next best option, given that eltoo is not
> > yet available. But if you are going to use a kickoff transaction, keep
> > in mind that every previous owner will have a copy of it. Because of
> > this, you can't include a fee, and will instead need to have a second
> > output for CPFP. This way a previous owner will at least have to pay
> > the fee if they want to publish it. Note that it's still an
> > improvement, because even if the kickoff transaction gets posted, it
> > basically becomes no different than what it would have been, had you
> > not used a kickoff transaction at all.
>
> It might be worth adopting the late fee binding we have in eltoo by
> having the kickoff transaction input spending the funding tx signed with
> sighash_single. This works because we only have 1 input and 1 output
> that we really care about, and can allow others to attach fees at
> will. That'd at least remove the need to guess the feerate days or
> months in advance and thus having to overestimate.
>
> > Regarding modification 2, I like it a lot conceptually. It hadn't
> > occurred to me before, and it's a clear security improvement. The only
> > question is something Greg Sanders mentioned: whether it's enough to
> > justify the added complexity of using 2P ECDSA. The alternative would
> > be to simply use a regular 2-of-2 multisig (until Schnorr arrives,
> > possibly).
>
> Wouldn't that result in a changing pubkey at each update, and thus
> require an onchain move to be committed?
>
> > I'm looking forward to seeing statechains become a reality.
>
> That'd indeed be great :-)
>
> Cheers,
> Christian
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

  reply	other threads:[~2020-03-26 17:17 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 [this message]
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
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=CAB3F3Dt0z5bDMpzRGGJxJV8KpCk_4XGF23MGmYVkLppRbG7Wnw@mail.gmail.com \
    --to=gsanders87@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=decker.christian@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