path: root/0c/fbfb62475357bfef5b0574b13a9d40f8d771d0

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 06D77104F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 19 Sep 2019 02:02:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
	[185.70.40.130])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CA1B48A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 19 Sep 2019 02:02:01 +0000 (UTC)
Date: Thu, 19 Sep 2019 02:01:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1568858518;
	bh=Rf9J0A+E7/JbCsBkcrIFmsdCT0+wUI+TMxwwCY6WEYs=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=hu4Xe7IN1zOgqxPb0Igj0eIJLtE317Duue2IZtAMvXues2fYGaTfQ57SIwRU9CglW
	Lziw8yV06aH76m7eMT4kEh0wvQxjRw49W41ScJwaSQttivBHyZ8gFjZf/vVcM+nubW
	zzF53j242Bfflc6RvZ0Kj01OKxvbT8mBchyhArUU=
To: Christian Decker <decker.christian@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com>
In-Reply-To: <87ef0doh0w.fsf@gmail.com>
References: <87mufhva0k.fsf@gmail.com>
	<G_LSM42y_gQFNVrTfHHN5hqR_foZU6AlOJkfz9zMDLFyQGdk4opZ14QC97w2rjrw4UmWTwEkJDKEc_eUMItdmxEsQOl7S-gBO2y8ovFPBc0=@protonmail.com>
	<CACJVCgLe-hmSoPZtsXBMDToqa-rh04EroppO14zBQqEjdWacQw@mail.gmail.com>
	<RQVxRFj-yzhYfEPMZhVrSYCaEvFhRrlxkSI-sYmqwEE7bRO6hKPV-vdB2ijcFYND-2x_5esnr7aofW6-74B3mHFLiLlHm-FM4WPeiJo-GhQ=@protonmail.com>
	<CACJVCg+wuODW-NoNoAvwdcnr0gZbLFrDyip6-0unw9hFu2-oOg@mail.gmail.com>
	<ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.com>
	<87ef0doh0w.fsf@gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	"lightning-dev\\@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>, Richard Myers <rich@gotenna.com>
Subject: Re: [bitcoin-dev] [Lightning-dev] Reconciling the off-chain and
	on-chain models with eltoo
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 02:02:04 -0000

Good morning Christian, and list,


> > > uncooperative membership change:
> > >
> > > -   a subset of channel parties might want to cooperatively sign a ch=
annel splicing transaction to 'splice out' uncooperative parties
> >
> > I believe this is currently considered unsafe.
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/00=
1975.html
> > Unless you refer to another mechanism...?
> > I believe this will end up requiring deep confirmation of the
> > uncooperative close followed by a new mechanism open.
>
> Not necessarily. If we have an escape hatch in the scripts that allows
> to spend any output attached to the settlement transaction by n-1
> participants we could reclaim these into a new open right away.

This would have to be very very carefully designed.
The entire point of requiring an n-of-n signature is:

* By using an n-of-n signatory where *you* are a signer, you are completely=
 immune to Sybil attacks: even if everybody other than *you* in the signato=
ry set is secretly just one entity, this is no different from doing a 2-of-=
2 bog-standard boring sleepy Zzzzzz Poon-Dryja Lightning Network channel.
  * Any m-of-n signatory where strictly m < n allows anybody with the abili=
ty to run m nodes to outright steal money from you.
    * As processing power is cheap nowadays, there is no m that can be cons=
idered safe.
      Your alternative is to fall back on proof-of-work, but that just mean=
s going onchain, so you might as well just do things onchain.
  * This is why 2-of-2 channels work so well, it's the minimum useable cons=
truction and any multiparty construction, when Sybilled, devolves to a 2-of=
-2 channel.

So the n-1 participants would have to be very very very carefully limited i=
n what they can do.
And if the only "right" the n-1 participants can do is to force the nth par=
ticipant to claim its funds onchain, then that is implementable with a tran=
saction doing just that, which is pre-signed by the nth participant and giv=
en to participants 1..n-1.

> > > mining, mining reward and difficulty adjustment
> > >
> > > -   no equivalent concept for multi-party channels
> >
> > Fees for each update. Consider how HTLC routing in Lightning
> > implicitly pays forwarding nodes to cooperate with the forwarding. I
> > imagine most nodes in a multiparticipant offchain system will want to
> > be paid for cooperation, even if just a nominal sub-satoshi amount.
>
> If we allow generic contracts on top of the base update mechanism it'll
> be rather difficult to identify the beneficiary of an update, so it's
> hard to know who should pay a fee. I'd rather argue that cooperating is
> in the interest of all participants since they'd eventually want to
> create an update of their own, and there is no upside to become
> unresponsive.
>
> Notice that the fees we leverage in LN are because we expose our funds
> to the risk of not being available by allocating them to an HTLC, not
> for the updates themselves. Since in the forwarding scenario we're only
> exposing the funds of the forwarding nodes to this risk it's only
> natural that they'd be the ones leveraging a fee, not the other
> participants that simply sign off on the change.

I suppose that could be argued.

However, I imagine it is possible for some of the updates to be implementab=
le via HTLCs within sub-mechanisms of the higher mechanism.
If so, a participant may refuse to sign for the higher mechanism in order t=
o force others to use HTLCs on the lower mechanisms, and thereby earn fees =
due to HTLC usage.
I believe I argue as much here: https://lists.linuxfoundation.org/pipermail=
/lightning-dev/2019-July/002055.html

> ZmnSCPxj can request a factory channel reorganization to move some funds =
from the ZmnSCPxj<->Rene channel to the ZmnSCPxj<->YAijbOJA channel.
> This has the same effect, i.e. it allows a forwarding attempt to push thr=
ough, that would not be possible without the factory-level channel reorgani=
zation.
>
> Further, assuming only ZmnSCPxj, YAijbOJA, and Rene are in the channel fa=
ctory, then it is the same: all three need to be online in order for the JI=
T-routing to work.
>
> But I observed above that, in a channel rebalance using current channels =
(without factories) Rene cannot be convinced to waive the fee.

The counterargument above is that if rebalances can be made fee-free, then =
the above argument disappears.


>
> > > privacy:
> > >
> > > -   disassociate a particular update from signer(s)
> > > -   disassociate IP address of signers from signature
> > > -   using SIGHASH_ALL for cooperative closes
> >
> > I suppose Tor can be used to disassociate IP address from signers if
> > everyone is from a hidden service. However, we need to include some
> > kind of mix mechanism to allow individual signers to disassociate
> > their ownership of funds from their identity as signers. Though such
> > mechanisms already exist as theoretical constructs, so "just needs
> > implementing".
> > But then again: if you own funds in the mechanism, you should be a
> > signer (else you are trusting a federation). So a basic fact here is
> > that if you are a participant in some offchain mechanism, you are
> > likely (approaching 100% probability) to own money in it.
>
> Notice that we are negotiating whether or not to apply generic
> transactions to a shared state. This also means that there is no direct
> relationship between the ownership of an output and the ID signing off
> on a change.
>
> The privacy guarantees are identical to Bitcoin on-chain, with the one
> caveat that we may identify the proposing participant, but we can defend
> against this by mixing as you propose.

Yes, but if we later combine this with allowing multiilateral kick-out of a=
 member that is unresponsive (i.e. we splice out the outputs it has at leas=
t partial ownership of, and keep only those that are owned only by the rema=
ining members), then each member would have to honestly claim which UTXOs i=
t is interested in keeping after it is kicked out of the membership set, de=
feating this point entirely.
I believe this is roughly what you propose in the next point, and roughly w=
hat you would want with the "n-1 participants" earlier.

>
> > > liveness:
> > >
> > > -   if signers know they will be offline, can they pre-sign updates t=
hat just commit their own outputs, rather then splice out?
> > > -   contingent tap-leafs to splice out non-responsive signers
> >
> > It might be possible to create a new mechanism-within-mechanism layer,
> > if a signer knows they will be offline.
> > For example, suppose entities A, B, and C have an offchain update
> > mechanism, which we shall call a "factory". Suppose this factory
> > contains an A-B channel, a B-C channel, a A-C channel, and some funds
> > owned by B only. Then suppose A knows he or she will be offline for
> > some time. Before A goes offline, they can move from this UTXO set:
> >
> > -   A-B channel
> > -   B-C channel
> > -   A-C channel
> > -   B funds
> >
> > To this UTXO set:
> >
> > -   A-B channel
> > -   A-C channel
> > -   B-C offchain update mechanism (sub-factory), which itself has its o=
wn UTXO set:
> >     -   B-C channel
> >     -   B funds
> >
> > This allows B and C to manage the B-C channels and B funds without
> > cooperation of A. Then, later, when A returns online, the B-C
> > offchain update mechanism is collapsed back to the parent A-B-C
> > offchain update mechanism.
> > This assumes A knows it will be offline (which it might do for
> > e.g. regular maintenance, or software updates).
>
> We could theoretically play this game, having each participant create
> two updates with the same state-number at each update:
>
> 1.  A normal one that just keeps them in the contract
> 2.  A fallback splice all outputs they own (direct ones, HTLCs, ...) and
>     putting the rest back into a channel without them.
>
>     In case of one user becoming inactive the others can sign the splice,
>     dropping the inactive participant and continue like nothing
>     happened. The worst case scenario is that the normal update gets
>     broadcast and confirmed instead, which means we are back to the
>     unilateral close that we'd have to do anyway without this mechanism.
>
>     Notice however that this only works if participants drop off one by o=
ne,
>     otherwise we get a combinatorial explosion for the fallback cases whe=
re
>     each combination of inactive participants needs to splice themselves
>     out. It also adds the complexity of having to identify which particip=
ant
>     is the co-owner of an output, otherwise I can claim ownership of an
>     unrelated output and force that to move on-chain by including it in m=
y
>     fallback and then becoming unresponsive (added rounds of communicatio=
n
>     can help here, but are cumbersome).

This might be a plausible way of implementing the "n-1 participants can kic=
k out nth participant".

>
>     It may be a bit much added complexity for a small complexity to be
>     honest, hopefully this won't be needed too often :-)

Statement makes no sense, unless you meant to say "It may be a bit much com=
plexity for a small benefit" or similar?

Regards,
ZmnSCPxj