From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id C7DE3C001A for ; 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 ; 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 ; 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 ; 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 , Paul Sztorc , Bitcoin Protocol Discussion In-Reply-To: Date: Mon, 28 Feb 2022 08:55:29 +0100 Message-Id: <132721155-8dab92d416edaf63c15cd32201400ae3@pmq8v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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