path: root/29/3edd93a271f5d5228c544aebd641eb2a45e6e0

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C7DE3C001A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Feb 2022 07:55:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A0B904007C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Feb 2022 07:55:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 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,
 RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id I3IBENlYZ5C4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Feb 2022 07:55:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo107.poczta.onet.pl (smtpo107.poczta.onet.pl
 [213.180.149.160])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 721AE4006F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Feb 2022 07:55:37 +0000 (UTC)
Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4K6Xjt0FCXz1sQ1;
 Mon, 28 Feb 2022 08:55:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1646034930; bh=LhPzCSGE3oLnh3wiOiyLVXnoSXxjdBagTD3+6QaTsgw=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=g2qVOwJ/rhw669VaIDwNfI77BdlUGYrpY8q0QZtwWGqKSWnpBRF+ZKHSEbHYMpzxn
 xJXrhZ63P6pRydvN8trapWdohTjTImWr/fXvXoyL59dt3jvyHoNAo8E33zowVm5mP0
 Gfgw3KypXWrba0jQ8cXEuB0noa8jjJ4IEl5T3zUk=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [82.177.167.2] by pmq8v.m5r2.onet via HTTP id ;
 Mon, 28 Feb 2022 08:55:30 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, Paul Sztorc <truthcoin@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <Ee7fnlpSPyqoJ4X0o5M4uEDZfEvLO2ljhhADYc2QgmSworKdNMJelLbH5BSzcRO_-fZ7aWIvgZXM8bYC0CdYL4sVwi59pkYAD81Z2psajuk=@protonmail.com>
Date: Mon, 28 Feb 2022 08:55:29 +0100
Message-Id: <132721155-8dab92d416edaf63c15cd32201400ae3@pmq8v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;82.177.167.2;PL;3
X-Mailman-Approved-At: Mon, 28 Feb 2022 16:03:15 +0000
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: Mon, 28 Feb 2022 07:55:39 -0000

> Continuous operation of the sidechain then implies a constant stream of 3=
2-byte commitments, whereas continuous operation of a channel factory, in t=
he absence of membership set changes, has 0 bytes per block being published.

The sidechain can push zero bytes on-chain, just by placing a sidechain has=
h in OP_RETURN inside TapScript. Then, every sidechain node can check that =
"this sidechain hash is connected with this Taproot address", without pushi=
ng 32 bytes on-chain.

On 2022-02-28 08:13:03 user ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.lin=
uxfoundation.org> wrote:
> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev