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 <bitcoin-dev@lists.linuxfoundation.org>
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>
 <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
In-Reply-To: <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
 or the absence thereof,
 was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Precedence: list

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

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">
      <pre>On 2/26/2022 9:00 PM, ZmnSCPxj wrote:</pre>
    </div>
    <blockquote type="cite"
cite="mid:Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com">...
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">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.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Yes, using channel factories.</pre>
    </blockquote>
    <pre class="moz-quote-pre" wrap="">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.


<blockquote type="cite"><pre class="moz-quote-pre" wrap="">We assume that onboarding new members is much rarer than existing members actually paying each other
</pre></blockquote>
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' ".


<blockquote type="cite"><pre class="moz-quote-pre" wrap="">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.</pre></blockquote>
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
</pre>
  </body>
</html>

--------------5waTeVtYMaDK1zIYKPWbel0a--