Date: Mon, 28 Feb 2022 06:49:22 +0000
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: <Ee7fnlpSPyqoJ4X0o5M4uEDZfEvLO2ljhhADYc2QgmSworKdNMJelLbH5BSzcRO_-fZ7aWIvgZXM8bYC0CdYL4sVwi59pkYAD81Z2psajuk=@protonmail.com>
In-Reply-To: <0af7c513-3df8-dcc8-9a14-e7e909e7fdc6@gmail.com>
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.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>
 <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
 <0af7c513-3df8-dcc8-9a14-e7e909e7fdc6@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
Precedence: list

Good morning Paul,

> On 2/26/2022 9:00 PM, ZmnSCPxj wrote:
>
> > ...
> >
> > > 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 w=
hat-they-were when the channel was opened).
> > > #2: The new part-owners (who are getting coins from the rich man), wi=
ll have 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.
>
> I think you may be wrong about this.
> Channel factories do not meet requirement #2, as they cannot grow to onbo=
ard new users (ie, new pubkeys).
> The factory-open requires that people pay to (for example), a 5-of-5 mult=
isig. So all 5 fixed pubkeys must be known, before the factory-open is conf=
irmed, not after.

I am not wrong about this.
You can cut-through the closure of one channel factory with the opening of =
another channel factory with the same 5 fixed pubkeys *plus* an additional =
100 new fixed pubkeys.
With `SIGHASH_ANYPREVOUT` (which we need to Decker-Russell-Osuntokun-based =
channel factories) you do not even need to make new signatures for the exis=
ting channels, you just reuse the existing channel signatures and whether o=
r not the *single*, one-input-one-output, close+reopen transaction is confi=
rmed or not, the existing channels remain usable (the signatures can be use=
d on both pre-reopen and post-reopen).

That is why I said changing the membership set requires onchain action.
But the onchain action is *only* a 1-input-1-output transaction, and with T=
aproot the signature needed is just 64 bytes witness (1 weight unit per byt=
e), I had several paragraphs describing that, did you not read them?

Note as well that with sidechains, onboarding also requires action on the m=
ainchain, in the form of a sideblock merge-mined on the mainchain.

>
> > We assume that onboarding new members is much rarer than existing membe=
rs actually paying each other
>
> Imagine that Bitcoin could only onboard 5 new users per millennium, but o=
nce onboarded they had payment nirvana (could transact hundreds of trillion=
s of times per second, privately, smart contracts, whatever).
> Sadly, the payment nirvana would not matter. The low onboarding rate woul=
d kill the project.

Fortunately even without channel factories the onboarding rate of LN is muc=
h much higher than that.
I mean, like, LN *is* live and *is* working, today, and (at least where I h=
ave looked, but I could be provincial) has a lot more onboarding activity t=
han half-hearted sidechains like Liquid or Rootstock.

> The difference between the two rates [onboarding and payment], is not rel=
evant. EACH rate must meet the design goal.
> It is akin to saying: " Our car shifts from park to drive in one-milliont=
h of a second, but it can only shift into reverse once per year; but that i=
s OK because 'we assume that going in reverse is much rarer than driving fo=
rward' ".

Your numbers absolutely suck and have no basis in reality, WTF.
Even without batched channel openings and a typical tranaction of 2 inputs,=
 1 LN channel, and a change output, you can onboard ~1250 channels per main=
chain block (admittedly, without any other activity).
Let us assume every user needs 5 channels on average and that is still 250 =
users per 10 minutes.
I expect channel factories to increase that by about 10x to 100x more, and =
then you are going to hit the issue of getting people to *use* Bitcoin rath=
er than many users wanting to get in but being unable to due to block size =
limits.

>
> > 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 publish=
ed.
>
> That's true, but I think you have neglected to actually take out your cal=
culator and run the numbers.
>
> Hypothetically, 10 largeblock-sidechains would be 320 bytes per block (00=
.032%, essentially nothing).
> Those 10, could onboard 33% of the planet in a single month [footnote], e=
ven if each sc-onboard required an average of 800 sc-bytes.
>
> Certainly not a perfect idea, as the SC onboarding rate is the same as th=
e payment rate. But once they are onboarded, those users can immediately jo=
in the LN *from* their sidechain. (All of the SC LNs would be interoperable=
.)
>
> Such a strategy would take enormous pressure *off* of layer1 (relative to=
 the "LN only" strategy). The layer1 blocksize could even **shrink** from 4=
 MB (wu) to 400 kb, or lower. That would cancel out the 320 bytes of overhe=
ad, many hundreds of times over.
>
> Paul
>
> [footnote] Envelope math, 10 sidechains, each 50 MB forever-fixed blocksi=
ze (which is a mere 12.5x our current 4M wu limit): 10 * 6*24*30 * ((50*100=
0*1000)/800) / 8.2 billion =3D .32926

Yes, and 33% of the planet want to use Bitcoin in the next month.

The onboarding rate only needs to be as fast as the rate at which people wa=
nt to join Bitcoin, and any security you sacrifice in order to get a higher=
 number than that is security you are sacrificing needlessly for extra capa=
city you are unable to utilize.

As I pointed out in the other thread:

* LN:
  * Funds can be stolen IF:
    * There is a 51% miner, AND
    * The 51% miner is a member of a channel/channel factory you are in.
* Drivechains:
  * Funds can be stolen IF:
    * There is a 51% miner.

Now of course there is always the possibility that the 51% miner is in *eve=
ry* channel factory globally.
But there is also the possibility that the 51% miner exists, but is *not* o=
n every channel factory.
Indeed, for any arbitrary channel or factory, I expect that the probability=
 of the 51% miner being a member is less than 100%, thus the combined proba=
bility is lower than Drivechains.

So there is a real degradation of security in Drivechains, and if you compu=
te the numbers, I am reasonably sure that 33% of the world is unlikely to w=
ant to use Bitcoin within one month.
I mean we already had a pandemic and everyone going online and so on, and y=
et Bitcoin blockchain feerates are *still* small, I had to fix a bug in CLB=
OSS that came up only due to hitting the minimum feerate, so no --- people =
are not joining Bitcoin at a rate faster than Bitcoin + LN can handle it, e=
ven with a pretty good reason to move payments online.

Worse, once 100% of the world is onboarded, the extra onboarding capacity i=
s useless since the onboarding rate can only match the birth rate (includin=
g birth of legal persons such as corporations), which we expect is much low=
er than 33% increase per ***month***.

You are buying too much capacity at a real degradation in security, and I a=
m not convinced the extra capacity is worth the loss of security.

Separating the onboarding rate from the payment rate is a *good thing*, bec=
ause we can then design their structures differently.
Make onboarding slow but secure (so that their money is very secure), but m=
ake payment rate faster and less secure (because in-flight payments are lik=
ely to be much smaller than the total owned funds).


Regards,
ZmnSCPxj