Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0313CC001A for ; Tue, 1 Mar 2022 05:39:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id E1AAB4033B for ; Tue, 1 Mar 2022 05:39:56 +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: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9ci8M0EnneLq for ; Tue, 1 Mar 2022 05:39:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by smtp4.osuosl.org (Postfix) with ESMTPS id 1B1D94033A for ; Tue, 1 Mar 2022 05:39:54 +0000 (UTC) Received: by mail-ej1-x633.google.com with SMTP id hw13so29143037ejc.9 for ; Mon, 28 Feb 2022 21:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JSiICQ/nDfV9KKEL7b+e+1NFVNO6GgxoQJSH6rIJkdw=; b=amQX8msWykAohTkiRqeBFjHFZMFyP/RQnqzlPoH0OrUFuZNqDsqvVIB/Y3P1cQn33L tdEX/zxVjgYt2Y0QHz5NxAozzqQNi2RGCVgMi+s0NYPDXLR4us03FsPfbl1AEnFgauIb LbetoN/yAVDH2q3AiVh2zw0/EWqZ8ErbHNLWoHOARPqFzmJekNjFXibVRY830Jy52LAC /NxwteLSqb5UjdruuiGd0Rj1Tah6nmGAyFkjXbxGenVUv8K669Pjc51SCV4QixsPNfde l2zojRlLCfENWtWpBzNOO7oAb3VaeMzXarLu2AANuGbSzjTEP3b/XMMZAFPCRHFx5fSB +LRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JSiICQ/nDfV9KKEL7b+e+1NFVNO6GgxoQJSH6rIJkdw=; b=MUWwO6RDNt+nFqbSLkRQXekdMKe1plrd/+R2mco8R6ZBMmiZopdbn7nzep8yPWccE2 ZBPq34VYmIqCLwe32hFd/7+ZQ4hlr83HWJYBaw2RZ5agbn0BVMld+xejvVaPK2k9TW+i LXOhoHjRI5qAEbYcZEpdA/jPhGPBaqM8gS/7Rx5gsE6y3FOlmsrVDLpfd9CU0iZW1mqm fNa27b+OBUm8pC6rCxpNQsoH/neITATJtnIlc3sm+/AVLipCjN62Us9vx1wnGE3GPsDg QrtYZk92aeGO+ae7AbiiYlRJH1sC8Z9LCKfnMncCghNySogGTsVQf0aRdOTfCclxdm8j 9qIg== X-Gm-Message-State: AOAM531fvs1cZTkTlcNHLCbDLTodtJIYyknfh/2M+9VZ7QAafMeBcosB +BKQylrUEiu5sshgcj/24sU3pGG+KvVzViNJIkTwN/nzf2k= X-Google-Smtp-Source: ABdhPJwFmX60IdVRsfaRTcmVXtaGXqLA7aGc8em0MQZs90X3oN3pNOunHZPdHySIWs/0IbMnqhPvZ3b8WRAMkN7vam0= X-Received: by 2002:a17:906:80c7:b0:6cf:9c76:1404 with SMTP id a7-20020a17090680c700b006cf9c761404mr17257851ejx.207.1646113192577; Mon, 28 Feb 2022 21:39:52 -0800 (PST) MIME-Version: 1.0 References: <20220224065305.GB1965@erisian.com.au> <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com> <0af7c513-3df8-dcc8-9a14-e7e909e7fdc6@gmail.com> <4e896010-ce85-5ee9-8f7d-1d29f2271621@gmail.com> In-Reply-To: <4e896010-ce85-5ee9-8f7d-1d29f2271621@gmail.com> From: Billy Tetrud Date: Mon, 28 Feb 2022 23:39:36 -0600 Message-ID: To: Paul Sztorc , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000001a96a305d92198d5" X-Mailman-Approved-At: Tue, 01 Mar 2022 14:00:24 +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: Tue, 01 Mar 2022 05:39:57 -0000 --0000000000001a96a305d92198d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Paul > I believe that money has very strong network effects. ... users will "clump up" and get "stuck". I'm of the same opinion. > This entire issue is avoided completely, if all the chains --decentralized and centralized-- and in the same monetary unit. Then, the monetary network effects never interfere, and the decentralized chain is always guaranteed to exist. It sounds like what you're saying is that without side chains, everyone might switch entirely to some altcoin and bitcoin will basically die. And at that point, the insecurity of that coin people switched to can be heavily exploited by some attacker(s). Is that right? Its an interesting thought experiment. However, it leads me to wonder: if a sidechain gets so popular that it dominates the main chain, why would people keep that main chain around at all? A sidechain could eject the main chain and all its baggage if it got so big. So I don't think it can really be said that the problem can be avoided "completely". But in any case, I see your line of thinking. > someone is actually in the wrong, if they proactively censor an experiment of any type. If a creator is willing to stand behind something, then it should be tried. > it makes no difference if users have their funds stolen from a centralized Solana contract or from a bip300 centralized bit-Solana sidechain. I don't see why the tears shed would be any different. I agree with you. My point was not that we should stop anyone from doing this. My point was only that we shouldn't advocate for ideas we think aren't good. You were advocating for a "largeblock sidechain", and unless you have good reasons to think that is an idea likely to succeed and want to share them with us, then you shouldn't be advocating for that. But certainly if someone *does* think so and has their own reasons, I wouldn't want to censor or stop them. But I wouldn't advocate for them to do it unless their ideas were convincing to me, because I know enough to know the dangers of large block blockchains. On Mon, Feb 28, 2022 at 4:55 PM Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 2/28/2022 1:49 AM, ZmnSCPxj wrote: > > ... > > ... > > Perhaps, someone will invent a way, to LN-onboard WITHOUT needing new lay= er1 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 h= ave 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 l= ayer1 bytes". > > By which I meant, that I could generate a new pubkey right now, and add i= t 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 actio= n. > > 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 se= em > 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 vi= a factory. > For example, 50,000 new users want to onboard in the next block. These st= rangers, spontaneously organize into 1000 factories of 55 people each, (50 = newbies with zero coins + 5 wealthier BTCs who have lots of coins). They th= en broadcast into the block and join Bitcoin. > And this one factory provides them with many channels, so it can meet mos= t/all of their needs. > > I am not here to critique factories. I was simply observing that your log= ic "sidechains don't scale, because you have to share your messages" is not= quite airtight, because in the case of onboarding the situation is reverse= d and so supports the exact opposite conclusion. > I believe I have made my point by now. It should be easy for people to se= e 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 t= o 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 pe= r year, $52.5 million USD per year to disable all the factories out of spit= e. (All of which they would eventually get back.) I can think of a few peop= le 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 peop= le 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 com= pute 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 C= LBOSS that came up only due to hitting the minimum feerate, so no --- peopl= e 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 (includ= ing birth of legal persons such as corporations), which we expect is much l= ower 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*, b= ecause 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 l= ikely 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000001a96a305d92198d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Paul
>=C2=A0I believe that money has very strong network effects. ... users will "clump up" an= d get "stuck".

I'm of t= he same opinion.

=
> This entire issue is avoided completely, if al= l the chains --decentralized and centralized-- and in the same monetary uni= t. Then, the monetary network effects never interfere, and the decentralize= d chain is always guaranteed to exist.

It sounds like what you're saying is that without side chains, everyo= ne might switch entirely to some altcoin and bitcoin will basically die. An= d at that point, the insecurity of that coin people switched to can be heav= ily exploited by some attacker(s). Is that right? Its an interesting though= t experiment. However, it leads me to wonder: if a sidechain gets so popula= r that it dominates the main chain, why would people keep that main chain a= round at all? A sidechain could eject the main chain and all its baggage if= it got so big. So I don't think it can really be said that the problem= can be avoided "completely". But in any case, I see your line o= f thinking.

> someone is actually in the wrong, if they proacti= vely censor an experiment of any type. If a creator is willing to stand beh= ind something, then it should be tried.
> it make= s no difference if users have their funds stolen from a centralized Solana = contract or from a bip300 centralized bit-Solana sidechain. I don't see= why the tears shed would be any different.

I agree with you. My point was not that we should stop anyone from d= oing this. My point was only that we shouldn't advocate for ideas we th= ink aren't good. You were advocating for a "largeblock sidechain&q= uot;, and unless you have good reasons to think that is an idea likely to s= ucceed and want to share them with us, then you shouldn't be advocating= for that. But certainly if someone *does* think so and has their own reaso= ns, I wouldn't want to censor or stop them. But I wouldn't advocate= for them to do it unless their ideas were convincing to me, because I know= enough to know the dangers of large block blockchains.
<= span style=3D"white-space:pre-wrap">


<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 28, 2022 at 4:55 PM Paul S= ztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=20 =20 =20 
On 2/28/2022 1:49 AM, ZmnSCPxj wrote:
...

...

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

If so, a "rich man" could open a LN channel, and gradually transf=
er 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-th=
ey-were when the channel was opened).
#2: The new part-owners (who are getting coins from the rich man), will hav=
e new pubkeys which are NOT known, until AFTER the channel is opened and co=
nfirmed 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 ne=
w 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 membersh=
ip set requires onchain action.


Which would seem to directly contradict what you say about channel factorie=
s.

Unless you can show me how to add my new pubkey_4, to a 3-of-3 channel fact=
ory 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 stra=
ngers, spontaneously organize into 1000 factories of 55 people each, (50 ne=
wbies 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&=
quot; is not quite airtight, because in the case of onboarding the situatio=
n 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 jo=
in 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 a=
t 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.=20


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 ab=
out the future (theoretical), not the past (empirical).
For example, someone could say "Ethereum has a lot more onboarding act=
ivity than LN ..." but this would also make no difference to anything.


...The onboarding rate only needs to be as fast as the rate at w=
hich 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 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).
Obviously I don't agree with any of these sentences (most are =
irrelevant, some false). But I would only be repeating myself.

Paul
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000001a96a305d92198d5--