From: Christian Decker <decker.christian@gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 tom@commerceblock.com,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPv7TjZ45VD_5sGSFiQxmt981uDodq28mHOW=2LYLofXams43w@mail.gmail.com>
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
 <79753214-9d5e-40c7-97ac-1d4e9ea3c64e@www.fastmail.com>
 <CAPv7TjZ45VD_5sGSFiQxmt981uDodq28mHOW=2LYLofXams43w@mail.gmail.com>
Date: Thu, 26 Mar 2020 18:12:44 +0100
Message-ID: <87369v6nw3.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] Statechain implementations
Precedence: list

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