path: root/5e/84c7ab93b7c5cc7935a4f46f9db4572d085d96

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id ECD61C001A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Feb 2022 02:00:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id E930582F6F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Feb 2022 02:00:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 FROM_FMBLA_NEWDOM=1.498, FROM_LOCAL_NOVOWEL=0.5,
 RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id TcFDAI_EXST7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Feb 2022 02:00:48 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 2506882F3D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 27 Feb 2022 02:00:48 +0000 (UTC)
Date: Sun, 27 Feb 2022 02:00:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1645927245;
 bh=6PAQWKggUgMh0oBbz5lnAUNOXTUlTZMdy906YmRoQuU=;
 h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
 From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID;
 b=l9mZoOgL5BZiwK5RU2t1XUlfWQ94zANxqBNSs8cZ0H9E9wbZdTSsN1usVzBDRl4bB
 X62UqQYBY2SvWuNOohPC1zCPhLnD9FCaVCBaClqQD2iAqvFWaii+kRcTLFr/HuxwUh
 /zxqDZ80INsRvBC/Bc0agIMLZyAVdTqTa5peVaKIwoo9KfBpzeLz61r28RdOq9UMm+
 aCT3moeiCRxIa0GS1rGRgf2u50qLdJXRRH2McI9gF8sxKKrtQldkniukqIpd2qa2ST
 qqDpoTfl1Rmqwor7Qa4PojSVO9+A7YFH757/qx/7kTnRYrQ4UUWnLIh21xMR71HdYQ
 iGMAsRPx8YE5g==
To: Paul Sztorc <truthcoin@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
In-Reply-To: <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com>
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <87leymuiu8.fsf@rustcorp.com.au>
 <CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com>
 <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
 <i710HUIxNHIqCNhkh07dzlShyDp9ZkoEokw9ZBezCFvsk05ZUy5fXK1xx_IQifLh4f3RYb8FJM_MFm7hAaQFaUM3Jy3E8QhfSzkaogAu1Gs=@protonmail.com>
 <20220224065305.GB1965@erisian.com.au>
 <bQvm5sSOMGRKR2udDFTNCJlOv_2vuIjkkBsoYqi4463y8ZjFDY4kxVvJEz7yv0GfxbyrMo-eOhOnEnd6sKPrWSk6PXn8KNerRlWsiGsWZRU=@protonmail.com>
 <CAGpPWDaVN4iAzfDKEQs2hmoQOHtToyPao1FgDCsMTJvt7pbq5g@mail.gmail.com>
 <fV9nkjr6K9fQWJWXtO4b3uZGzpHvDNdQa89X73yUB2YVsvuNVPDqsJln88pEef1fzHsui-qnneXdmYsO7CDibxMrm9PBDOO0Ls8RV1Bx1BI=@protonmail.com>
 <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
	or the absence thereof,
	was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and
	ANYPREVOUT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sun, 27 Feb 2022 02:00:49 -0000

Good morning Paul,

> ***
>
> You have emphasized the following relation: "you have to show your transa=
ction to everyone" =3D "thing doesn't scale".
>
> However, in LN, there is one transaction which you must, in fact, "show t=
o everyone": your channel-opener.
>
> Amusingly, in the largeblock sidechain, there is not. You can onboard usi=
ng only the blockspace of the SC.
> (One "rich guy" can first shift 100k coins Main-to-Side, and he can hence=
forth onboard many users over there. Those users can then onboard new users=
, forever.)
>
> So it would seem to me, that you are on the ropes, even by your own crite=
rion. [Footnote 1]
>
> ***
>
> Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new lay=
er1 bytes.
>
> If so, a "rich man" could open a LN channel, and gradually transfer it to=
 new people.
>
> Such a technique would need to meet two requirements (or, so it seems to =
me):
> #1: The layer1 UTXO (that defines the channel) can never change (ie, the =
32-bytes which define the p2sh/tapscript/covenant/whatever, must stay what-=
they-were when the channel was opened).
> #2: The new part-owners (who are getting coins from the rich man), will h=
ave new pubkeys which are NOT known, until AFTER the channel is opened and =
confirmed on the blockchain.
>
> Not sure how you would get both #1 and #2 at the same time. But I am not =
up to date on the latest LN research.

Yes, using channel factories.

A channel factory is a N-of-N where N >=3D 3, and which uses the same offch=
ain technology to host multiple 2-of-2 channels.
We observe that, just as an offchain structure like a payment channel can h=
ost HTLCs, any offchain structure can host a lot of *other* contracts, beca=
use the offchain structure can always threaten to drop onchain to enforce a=
ny onchain-enforceable contract.
But an offchain structure is just another onchain contract!
Thus, an offchain structure can host many other offchain structures, and th=
us an N-of-N channel factory can host multiple 2-of-2 channel factories.

(I know we discussed sidechains-within-sidechains before, or at least I men=
tioned that to you in direct correspondence, this is basically that idea br=
ought to its logical conclusion.)

Thus, while you still have to give *one* transaction to all Bitcoin users, =
that single transaction can back several channels, up to (N * (N - 1)) / 2.

It is not quite matching your description --- the pubkeys of the peer parti=
cipants need to be fixed beforehand.
However, all it means is some additional pre-planning during setup with no =
scope for dynamic membership.

At least, you cannot dynamically change membership without onchain action.
You *can* change membership sets by publishing a one-input-one-output trans=
action onchain, but with Taproot, the new membership set is representable i=
n a single 32-byte Taproot address onchain (admittedly, the transaction inp=
ut is a txin and thus has overhead 32 bytes plus 1 byte for txout index, an=
d you need 64 bytes signature for Taproot as well).
The advantage is that, in the meantime, if membership set is not changed, p=
ayments can occur *without* any data published on the blockchain (literally=
 0 data).

With sidechains, changing the ownership set requires that the sidechain pro=
duce a block.
That block requires a 32-byte commitment in the coinbase.
What is more, if *any* transfers occur on the sidechain, they cannot be rea=
l without a sidechain block, that has to be committed on the mainchain.

Thus, while changing the membership set of a channel factory is more expens=
ive (it requires a pointer to the previous txout, a 64-byte Taproot signatu=
re, and a new Taproot address), continuous operation does not publish any d=
ata at all.
While in sidehchains, continuous operation and ordinary payments requires i=
deally one commitment of 32 bytes per mainchain block.
Continuous operation of the sidechain then implies a constant stream of 32-=
byte commitments, whereas continuous operation of a channel factory, in the=
 absence of membership set changes, has 0 bytes per block being published.

We assume that onboarding new members is much rarer than existing members a=
ctually paying each other in an actual economy (after the first burst of on=
boarding, new members will only arise in proportion to the birth rate, but =
typical economic transactions occur much more often), so optimizing for the=
 continuous operation seems a better tradeoff.


Channel factories have the nice properties:

* N-of-N means that nobody can steal from you.
  * Even with a 51% miner, nobody can steal from you as long as none of the=
 N participants is the 51% miner, see the other thread.
* Graceful degradation: even if if 1 of the N is offline, payments are done=
 over the hosted 2-of-2s, and the balance of probability is that most of th=
e 2-of-2s have both participants online and payments can continue to occur.

--

The reason why channel factories do not exist *yet* is that the main offcha=
in construction we have, Poon-Dryja, is 2-of-2.
We have Decker-Wattenhofer, which supports N >=3D 2, but it needs to publis=
h a lot of onchain data in case of dispute, and has lousy UX due to how it =
uses delays (you can only be safely offline for some small number of blocks=
, but you have to wait out a large multiple of that parameter).

We also have the newer Decker-Russell-Osuntokun ("eltoo"), but that require=
s `SIGHASH_NOINPUT`, which is now today called `SIGHASH_ANYPREVOUT`.

`OP_CTV` also is useful for publishing commitments-to-promised-outputs with=
out having to publish outputs right now.

This is why I want to focus on getting both on Bitcoin first, *before* any =
recursive-contract-enabling technologies.

Admittedly, the recursive-covenant-enabling constructs look like they enabl=
e functionality equivalent to `SIGHASH_NOINPUT` and `OP_CTV`, though as I u=
nderstand them, they would require more bytes than `SIGHASH_NOINPUT` or `OP=
_CTV`.
And scaling is really improved by reducing the number of bytes published, s=
o there is value in merging in `SIGHASH_ANYPREVOUT` and `OP_CTV` at some po=
int, so why not now.


Regards,
ZmnSCPxj