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 E84D7C001A for ; Mon, 28 Feb 2022 22:54:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id C08F64060F for ; Mon, 28 Feb 2022 22:54:52 +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, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 KATiB2b8MRTI for ; Mon, 28 Feb 2022 22:54:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) by smtp2.osuosl.org (Postfix) with ESMTPS id 55295405F8 for ; Mon, 28 Feb 2022 22:54:51 +0000 (UTC) Received: by mail-qv1-xf29.google.com with SMTP id w7so15231874qvr.3 for ; Mon, 28 Feb 2022 14:54:51 -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=gPqTASsRgI6ffNRP5TU4MnU5xA9FRX8anhUyk9iWhgE=; b=nuDSa86fLiZ9qWL0yN7pThaLtnfQJ8hkipyFdv2k1gCdE+5LMdga+HhEvD8n6a1pnA iouIaD53FM+8XoWQsmb3P7qgHHoYDAKNpJPtK3dRr4dsz7MhbK49UlLavJVy8L50HU4s gbFnc4jYev3xYV7MEqwwMEaqQLN1uD49pILZSD3tUxgbVYQ6pXTtget3YuTJsfFo3Noh r+00BGVyPfi4qKlgIsIwaGkhaB/E0uXz0wTXg8HiFwo+A9xkx503AsYEcY3OjW2YjmY7 4ulaX3cCcNxGy7FsUVgbGVqEOnIplZ+QahFoB5QusJ9YR9+9h/kNgj08gJJASTnZJQ5K jAuQ== 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=gPqTASsRgI6ffNRP5TU4MnU5xA9FRX8anhUyk9iWhgE=; b=XiQNXbnNZmzaGpkEun3GREGstL8922hKila4wszzyaFdlpmGdGIifMfBUnQEABaYJa nxnM7SNMQEWFjEkCktC4jaKmDhxx0uaue7zuzozktWTjoh5xf91IAT7U5GIh58A4gOMm tulvUwnCE/YBA/VCNWi2B+fF2L3Dbh/I1vhYQryayTNQpXkwUTX70D01AQPrVMR3scw9 mAqXlG7UpLx+fck1H/z/Yx/oXls0ADlic+AIZ/DMaOwGUQSut8/FB6GKpqVa820uUzwD XX/kTKtbH4VNGmvcqra4o8ceCjhuf3DW58ENodPUP2b4xXMdQJxfm7xgX2l1jpsSBOGS VVeg== X-Gm-Message-State: AOAM5339oonFlS+PTu9ATWy12hjzMWrHT/pjiGawFg0d6a1fquoiK4Xy g1J9BeaU0l5Qw/7JpoCz9rR+t7riKak= X-Google-Smtp-Source: ABdhPJxU89bmwJACePyq+dRnjC4Flb0l/wmKsafl9AhIAKB7AH9P5YDAypgvOcfXvP8HxdwJ149bFQ== X-Received: by 2002:ac8:5c06:0:b0:2de:2da5:e603 with SMTP id i6-20020ac85c06000000b002de2da5e603mr17955421qti.25.1646088889680; Mon, 28 Feb 2022 14:54: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 w9-20020a05620a148900b005f188f755adsm5610871qkj.32.2022.02.28.14.54.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Feb 2022 14:54:49 -0800 (PST) Content-Type: multipart/alternative; boundary="------------2vPVWRZ64vXJVjGuSX5havOw" Message-ID: <4e896010-ce85-5ee9-8f7d-1d29f2271621@gmail.com> Date: Mon, 28 Feb 2022 17:54: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: <20220224065305.GB1965@erisian.com.au> <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com> <0af7c513-3df8-dcc8-9a14-e7e909e7fdc6@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 22:54:53 -0000 This is a multi-part message in MIME format. --------------2vPVWRZ64vXJVjGuSX5havOw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/28/2022 1:49 AM, ZmnSCPxj wrote: > ... >>>> ... >>>> >>>> Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 bytes. >>>> >>>> If so, a "rich man" could open a LN channel, and gradually transfer it to new people. >>>> >>>> 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. >> ... > I am not wrong about this. Well, let's take a closer look then. The topic was: "a way, to LN-onboard [a new pubkey] WITHOUT needing new layer1 bytes". By which I meant, that I could generate a new pubkey right now, and add it to the LN, without any onchain action. I can shorten and restate the two requirements (and reorder them) as: #2: Can later add a new public key to the membership set. #1: Without an onchain action. And yet you yourself say, very clearly: > ... That is why I said changing the membership set requires onchain action. Which would seem to directly contradict what you say about channel factories. Unless you can show me how to add my new pubkey_4, to a 3-of-3 channel factory opened last year. Without using an onchain action. You seem to want to instead change the subject. (To something like: 'we can do better the rate (32 bytes per 5 onboards), from your footnote'.) Which is fine. But it is not what I bought up. *** In general, you seem to have a future in mind, where new users onboard via factory. For example, 50,000 new users want to onboard in the next block. These strangers, spontaneously organize into 1000 factories of 55 people each, (50 newbies with zero coins + 5 wealthier BTCs who have lots of coins). They then broadcast into the block and join Bitcoin. And this one factory provides them with many channels, so it can meet most/all of their needs. I am not here to critique factories. I was simply observing that your logic "sidechains don't scale, because you have to share your messages" is not quite airtight, because in the case of onboarding the situation is reversed and so supports the exact opposite conclusion. I believe I have made my point by now. It should be easy for people to see what each of us has in mind, and the strengths and weaknesses. I am curious about something, though. Maybe you can help me. Presumably there are risks to large factories. Perhaps an attacker could join each new factory with just $1 of BTC, spend this $1, and then refuse to cooperate with the factory any further. Thus they can disable the factory at a cost of $1 rented dollar. If 1000 factories are opened per block, this would be 52.5 M factories per year, $52.5 million USD per year to disable all the factories out of spite. (All of which they would eventually get back.) I can think of a few people who might try it. > I mean, like, LN ... has a lot more onboarding activity than half-hearted sidechains like Liquid or Rootstock. I don't see the relevance of this. We are talking about the future (theoretical), not the past (empirical). For example, someone could say "Ethereum has a lot more onboarding activity than LN ..." but this would also make no difference to anything. > ...The onboarding rate only needs to be as fast as the rate at which people want to join Bitcoin. > ... > > 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. > ... > So there is a real degradation of security in Drivechains, and if you compute the numbers, I am reasonably sure that 33% of the world is unlikely to want to use Bitcoin within one month. > I mean we already had a pandemic and everyone going online and so on, and yet Bitcoin blockchain feerates are *still* small, I had to fix a bug in CLBOSS 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, even with a pretty good reason to move payments online. > > Worse, once 100% of the world is onboarded, the extra onboarding capacity is useless since the onboarding rate can only match the birth rate (including birth of legal persons such as corporations), which we expect is much lower than 33% increase per ***month***. > > You are buying too much capacity at a real degradation in security, and I am not convinced the extra capacity is worth the loss of security. > > Separating the onboarding rate from the payment rate is a *good thing*, because we can then design their structures differently. > Make onboarding slow but secure (so that their money is very secure), but make payment rate faster and less secure (because in-flight payments are likely to be much smaller than the total owned funds). Obviously I don't agree with any of these sentences (most are irrelevant, some false). But I would only be repeating myself. Paul --------------2vPVWRZ64vXJVjGuSX5havOw Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
On 2/28/2022 1:49 AM, ZmnSCPxj wrote:
...

...

Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new layer1 bytes.

If so, a "rich man" could open a LN channel, and gradually transfer it to new people.

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.
...

I am not wrong about this.

Well, let's take a closer look then.

The topic was: "a way, to LN-onboard [a new pubkey] WITHOUT needing new layer1 bytes".

By which I meant, that I could generate a new pubkey right now, and add it to the LN, without any onchain action.

I can shorten and restate the two requirements (and reorder them) as:
#2: Can later add a new public key to the membership set.
#1: Without an onchain action.

And yet you yourself say, very clearly:


... That is why I said changing the membership set requires onchain action.


Which would seem to directly contradict what you say about channel factories.

Unless you can show me how to add my new pubkey_4, to a 3-of-3 channel factory opened last year. Without using an onchain action.

You seem to want to instead change the subject. (To something like: 'we can do better the rate (32 bytes per 5 onboards), from your footnote'.)

Which is fine. But it is not what I bought up.

***

In general, you seem to have a future in mind, where new users onboard via factory.
For example, 50,000 new users want to onboard in the next block. These strangers, spontaneously organize into 1000 factories of 55 people each, (50 newbies with zero coins + 5 wealthier BTCs who have lots of coins). They then broadcast into the block and join Bitcoin.
And this one factory provides them with many channels, so it can meet most/all of their needs.

I am not here to critique factories. I was simply observing that your logic "sidechains don't scale, because you have to share your messages" is not quite airtight, because in the case of onboarding the situation is reversed and so supports the exact opposite conclusion.
I believe I have made my point by now. It should be easy for people to see what each of us has in mind, and the strengths and weaknesses.

I am curious about something, though. Maybe you can help me.
Presumably there are risks to large factories. Perhaps an attacker could join each new factory with just $1 of BTC, spend this $1, and then refuse to cooperate with the factory any further. Thus they can disable the factory at a cost of $1 rented dollar.
If 1000 factories are opened per block, this would be 52.5 M factories per year, $52.5 million USD per year to disable all the factories out of spite. (All of which they would eventually get back.) I can think of a few people who might try it. 


I mean, like, LN ... has a lot more onboarding activity than half-hearted sidechains like Liquid or Rootstock.

I don't see the relevance of this. We are talking about the future (theoretical), not the past (empirical).
For example, someone could say "Ethereum has a lot more onboarding activity than LN ..." but this would also make no difference to anything.


...The onboarding rate only needs to be as fast as the rate at which people want to join Bitcoin.
...

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.
...
So there is a real degradation of security in Drivechains, and if you compute the numbers, I am reasonably sure that 33% of the world is unlikely to want to use Bitcoin within one month.
I mean we already had a pandemic and everyone going online and so on, and yet Bitcoin blockchain feerates are *still* small, I had to fix a bug in CLBOSS 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, even with a pretty good reason to move payments online.

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

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

Separating the onboarding rate from the payment rate is a *good thing*, because we can then design their structures differently.
Make onboarding slow but secure (so that their money is very secure), but make payment rate faster and less secure (because in-flight payments are likely to be much smaller than the total owned funds).
Obviously I don't agree with any of these sentences (most are irrelevant, some false). But I would only be repeating myself.

Paul
--------------2vPVWRZ64vXJVjGuSX5havOw--