From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 596E9C001A for ; Mon, 28 Feb 2022 00:20:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 33481400D8 for ; Mon, 28 Feb 2022 00:20:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgTrA8Lr8x4g for ; Mon, 28 Feb 2022 00:20:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) by smtp2.osuosl.org (Postfix) with ESMTPS id B9822400C6 for ; Mon, 28 Feb 2022 00:20:50 +0000 (UTC) Received: by mail-qk1-x735.google.com with SMTP id bm39so9228176qkb.0 for ; Sun, 27 Feb 2022 16:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to; bh=cQ1ZpjaAizDXsZXo8/NitRLmUFpeZxQZFASgrGa0hPQ=; b=TE7TsKXtQFlfnP3EZSpNelZE0QQbOoFqtBc+L5/pCwY9S8MmTXccOwNNbSFJygrg5+ KhLRZTSWXbjdeAzxc2nK8ZYlSzT+ZifCbfJi0oLbuCS7IEAgbnTa0zPEvCaU8/YhxFhl pcrb3c4R5mKQAKrSYHf6FLxfr9KVjfTr4Ly53CpJGw5wJ0xYaAUYWCimkNcVjxkdcNgz YElXebv+4SgT2RFZwmkc2Bw+TDVndcjzOpBWJP4SLYSFQYpaHPsy4clhie0CkOTGm0Sz 7ZDRXt58VWCnDJLfDQuyLmxE5AJAFdBw9Aml8rhNibbWHK3loqg0zIQd5qMwVlgA0XZf ZmjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to; bh=cQ1ZpjaAizDXsZXo8/NitRLmUFpeZxQZFASgrGa0hPQ=; b=F4BAdlvXzKvoi4FcmB80/XaTo7SLMGtD0Y/SvoXOQ20Kby3zij2wQU0WVu9prgjgkL QbYsrs1aI8/TjnwZa7GWFMbcaezDqtjYWq7PiaWxIBGyTB0U630sZg7D1GO5KoczpdVq p5uVGUdNKYk4wyTEygfEPGFKlSp2X/6jvqAIrqbGTdgPQF5aot3KXGr45Q8YDclqsTuo Ci04uUgDDi8rfAkkVXuLWKpk6lWkigVaIqrQH0JNve3cgqZvIC5EKs3DbHK4rpc7BQDC d9/LCivlTv6AB9t2/HiPPJWunyloG3BSDqc0S1TdgiC7Em5KqucZq7fG5FRXbNtgknHd nzsQ== X-Gm-Message-State: AOAM5322Kd1YQNRnAIHToi+Ws3bSvx577iffVzCM3IGyclDlVbN5FG50 AIgJziXOfgHaa4NT2G62Ddj/LPqBWho= X-Google-Smtp-Source: ABdhPJxQrulxWE3SqcscloHQV7LqFuAzXQmdRpsYSYGGwf8q01i2EXiGD7m2aIuPVlvqbg+OiIZCng== X-Received: by 2002:a05:620a:a82:b0:508:b41b:c44b with SMTP id v2-20020a05620a0a8200b00508b41bc44bmr10113461qkg.100.1646007649209; Sun, 27 Feb 2022 16:20:49 -0800 (PST) Received: from [192.168.0.165] (ool-45714b6d.dyn.optonline.net. [69.113.75.109]) by smtp.googlemail.com with ESMTPSA id o1-20020a37be01000000b00648eadafd9bsm4363287qkf.24.2022.02.27.16.20.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Feb 2022 16:20:48 -0800 (PST) Content-Type: multipart/alternative; boundary="------------5waTeVtYMaDK1zIYKPWbel0a" Message-ID: <0af7c513-3df8-dcc8-9a14-e7e909e7fdc6@gmail.com> Date: Sun, 27 Feb 2022 19:20:47 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Content-Language: en-US To: Bitcoin Protocol Discussion References: <87leymuiu8.fsf@rustcorp.com.au> <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com> <20220224065305.GB1965@erisian.com.au> <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com> From: Paul Sztorc In-Reply-To: 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 00:20:52 -0000 This is a multi-part message in MIME format. --------------5waTeVtYMaDK1zIYKPWbel0a Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 what-they-were when the channel was opened). >> #2: The new part-owners (who are getting coins from the rich man), will 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 onboard new users (ie, new pubkeys). The factory-open requires that people pay to (for example), a 5-of-5 multisig. So all 5 fixed pubkeys must be known, before the factory-open is confirmed, not after. > We assume that onboarding new members is much rarer than existing members actually paying each other Imagine that Bitcoin could only onboard 5 new users per millennium, but once onboarded they had payment nirvana (could transact hundreds of trillions of times per second, privately, smart contracts, whatever). Sadly, the payment nirvana would not matter. The low onboarding rate would kill the project. The difference between the two rates [onboarding and payment], is not relevant. EACH rate must meet the design goal. It is akin to saying: " Our car shifts from park to drive in one-millionth of a second, but it can only shift into reverse once per year; but that is OK because 'we assume that going in reverse is much rarer than driving forward' ". > 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. That's true, but I think you have neglected to actually take out your calculator 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], even 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 the payment rate. But once they are onboarded, those users can immediately join 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 overhead, many hundreds of times over. Paul [footnote] Envelope math, 10 sidechains, each 50 MB forever-fixed blocksize (which is a mere 12.5x our current 4M wu limit): 10 * 6*24*30 * ((50*1000*1000)/800) / 8.2 billion = .32926 --------------5waTeVtYMaDK1zIYKPWbel0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
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 what-they-were when the channel was opened).
#2: The new part-owners (who are getting coins from the rich man), will 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 onboard new users (ie, new pubkeys).
The factory-open requires that people pay to (for example), a 5-of-5 multisig. So all 5 fixed pubkeys must be known, before the factory-open is confirmed, not after.



We assume that onboarding new members is much rarer than existing members actually paying each other


Imagine that Bitcoin could only onboard 5 new users per millennium, but once onboarded they had payment nirvana (could transact hundreds of trillions of times per second, privately, smart contracts, whatever).
Sadly, the payment nirvana would not matter. The low onboarding rate would kill the project.

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



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.

That's true, but I think you have neglected to actually take out your calculator 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], even 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 the payment rate. But once they are onboarded, those users can immediately join 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 overhead, many hundreds of times over.

Paul

[footnote] Envelope math, 10 sidechains, each 50 MB forever-fixed blocksize (which is a mere 12.5x our current 4M wu limit): 10 * 6*24*30 * ((50*1000*1000)/800) / 8.2 billion = .32926
--------------5waTeVtYMaDK1zIYKPWbel0a--