From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9F4DBC001A for ; Sun, 27 Feb 2022 00:58:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 7881483E02 for ; Sun, 27 Feb 2022 00:58:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 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, FROM_FMBLA_NEWDOM=1.498, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.117, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7KKUHzcxr8C for ; Sun, 27 Feb 2022 00:58:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5EC4B83DFB for ; Sun, 27 Feb 2022 00:58:05 +0000 (UTC) Received: by mail-qk1-x731.google.com with SMTP id b13so7689771qkj.12 for ; Sat, 26 Feb 2022 16:58:05 -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=LLhtDbpG5A84a8u+QUJ5yT5U/ZWvzaVFm/5JSdKFPeA=; b=UzTbkM6czYpkrCuVnqEICOS5aEqWueachyOdnxHtPiT82yfj/6OLr05Y4s8j+ggteo RI8f5L00vFKxVMRtLxl/u9IFsV5kI6B+tdNf1Y/9kEDt6W3CUy9MB7rOSu7vwnYW4U6w TmhGuv6J+V0DIA2Xn98XKsJjsHwGCT19gUObpkh+V1p2KM2DK7KOBLQ3N2d8Z9cnzOo6 LyzyQ9IpRcQ0irIpO1CboUVbnKxyWSv4dh+XOyZH+W63tAoBTQ3Ysaa5MZoOGXxweyth qYS9gum0gMf0AIPnAs1wEWubwj4J3yW1J1d23MFKzKcGourVFu9LydauameGxffxLhw/ mYWw== 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=LLhtDbpG5A84a8u+QUJ5yT5U/ZWvzaVFm/5JSdKFPeA=; b=y4F5gAEUgxASNsk5MK9iRAHmQqh1tqQmzybU9gC9iq7vCdqS57lwfDCsQhPp2zp6Hf HVLseGGOgLQxAw1g3ubiycohu7tpfRtQTkupB/xVm+GSmlAsfJSRADeDLkxeLPgknYPv A3ghdYLRVcSCqW22g3mW2lGiyRn327EELROssB3wiTr0NY3QgP9Qeo04lwFhofPQtCKQ Mgz+GneK/86OVrYvzYfoHIQNkqzdZespxNImzWpy9lEUyWOykWdWx50SXsBgRJY8yX5b YxJBJ9Mm1sgFAMX23gnXkHeiwyAc75mqbUldT/TkjSDZr5H2CjZZ1t6lOkFrITJ/5Cy0 XsYw== X-Gm-Message-State: AOAM5337+ssw4PkBmqctngUCCPIuDEcbUgFxIfiKvjGy8DYgFkC/euke fB/jf/1VKp5++PYEh6e5jselF/UtNLU= X-Google-Smtp-Source: ABdhPJwHQpyezfVXo52XYsdXy3sX+zVcRoUkJ+WpDTTvSW2e8wcgWs+2KhtT9mReAMeCUWPmUvsGEA== X-Received: by 2002:a05:620a:125c:b0:648:ad0a:4deb with SMTP id a28-20020a05620a125c00b00648ad0a4debmr8120878qkl.629.1645923483829; Sat, 26 Feb 2022 16:58:03 -0800 (PST) Received: from [192.168.0.165] (ool-45714b6d.dyn.optonline.net. [69.113.75.109]) by smtp.googlemail.com with ESMTPSA id p20-20020a05620a22b400b00648ca1458b4sm3167887qkh.5.2022.02.26.16.58.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 26 Feb 2022 16:58:03 -0800 (PST) Content-Type: multipart/alternative; boundary="------------k8qCMw50rbuzzLc0pF4oRaB8" Message-ID: <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com> Date: Sat, 26 Feb 2022 19:58:01 -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> 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: Sun, 27 Feb 2022 00:58:06 -0000 This is a multi-part message in MIME format. --------------k8qCMw50rbuzzLc0pF4oRaB8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2/26/2022 1:43 AM, ZmnSCPxj via bitcoin-dev wrote: > ... > Drivechains are not a scaling solution [FOOTNOTE 1] ... > I personally am interested only in scaling solutions, adding more non-scaling-useable functionality is not of interest to me and I do not really care > ... > But if there is consensus that those arguments are bogus, then go ahead --- add Drivechains and/or recursive covenants. > ... > > [FOOTNOTE 1] Sidechains are not a scaling solution ... Blockchains are inefficient ... and you have to show your transaction to everyone. > ... > Now you might conter-argue that you can have multiple smaller sidechains and just use HTLCs to trade across them ... I would then counter-counter-argue that bringing this to the most extreme conclusion, you would have tons of sidechains with only 2 participants each ... Do you really hang your entire --"sidechains are not a scaling solution"-- argument on this frail logic? The scaling strategy (in LN and DC) is the same: try NOT to "show your transaction to everyone". The details are of course different. I think largeblock sidechains should be reconsidered: * They are not a blocksize increase. * They endorse the principle of scaling in layers. * They allow users to be different. Some can pay more (for more decentralization), some less (for less decentralization). (We are currently gambling the entire future of BTC, on the premise that strong decentralization will always be needed at all points in time.) (This leaves us vulnerable to a strategy where our adversaries temporarily favor/promote centralized chains, so as to "domesticate" / control these in the future.) * We can learn from past mistakes -- when a new largeblock sidechain is needed, we can make a new one from scratch, using everything we know. * Different teams can compete, releasing different chains independently; thus curtailing "toxicity". * All of the fees, paid on all blockchains, arrive as revenue to the same group of miners, thus improving total hashrate/difficulty. * Sidechains will organize geographically, which may help security (ie, USA could spitefully run full nodes of the "China" largeblock sidechain). * Relative to LN, users enjoy: unlimited "inbound liquidity", can receive money while offline, no risk that the channel will close, etc. Certainly, sidechains are NOT for everyone. (Just as [I imagine] the LN is not for everyone.) However, in 2015, many hardfork-largeblockers said: "we do not run a full node, full nodes are not important; we use SPV; read the whitepaper" etc. They used SPV completely; and wanted large blocks. Presumably they would be happy users of a largeblock sidechain. So it would be >0 users. Sadly, this idea is neglected, (I think) because of its unfortunate resemblance to naive-largeblock-ism. This is irrational. *** You have emphasized the following relation: "you have to show your transaction to everyone" = "thing doesn't scale". However, in LN, there is one transaction which you must, in fact, "show to everyone": your channel-opener. Amusingly, in the largeblock sidechain, there is not. You can onboard using only the blockspace of the SC. (One "rich guy" can first shift 100k coins Main-to-Side, and he can henceforth onboard many users over there. Those users can then onboard new users, forever.) So it would seem to me, that you are on the ropes, even by your own criterion. [Footnote 1] *** 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. Paul [Footnote 1] I am certainly not a LN expert, so perhaps this analysis is misconceived. But consider these "best case scenario" assumptions for LN: * Each new channel-open consumes just 32 vbytes (since they are all done via one or more "rich men" who batches all these into one block, 24/7/365) * Each new channel-open, onboards 5 users at once who are a permanent trust group / channel factory / what-have-you (these five newcomers must coordinate with each other and the "rich man", presumably via calendly link or whatever, for their one shot at getting on the blockchain). * That one single channel is able to meet 100% of the user's payment needs (it never has any problems, with liquidity /balancing /routing /uptime /hotwallet-crashing /counterparty-fees /etc) (and also, people do NOT desire >1 channel for other reasons: their alt nyms, small business, church, etc) * 99.9% of the 1MB (vB) blocksize is used for channel-opens (the spare 1000 vb = the coinbase + the single "rich man"-input) * World population becomes a fixed 8.2 billion (and henceforth stops growing) By simple envelop math, 6*24*365*(((1000000*.999)/32)*5) / 8.2 billion = ~exactly one year to onboard everyone. But if the above assumptions contain, say, two orders of magnitude of "optimism", then it would instead take 100 years. --------------k8qCMw50rbuzzLc0pF4oRaB8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
On 2/26/2022 1:43 AM, ZmnSCPxj via bitcoin-dev wrote:

...
Drivechains are not a scaling solution [FOOTNOTE 1] ...
I personally am interested only in scaling solutions, adding more non-scaling-useable functionality is not of interest to me and I do not really care
...
But if there is consensus that those arguments are bogus, then go ahead --- add Drivechains and/or recursive covenants.
...

[FOOTNOTE 1] Sidechains are not a scaling solution ... Blockchains are inefficient ... and you have to show your transaction to everyone.  
...
 Now you might conter-argue that you can have multiple smaller sidechains and just use HTLCs to trade across them ... I would then counter-counter-argue that bringing this to the most extreme conclusion, you would have tons of sidechains with only 2 participants each ...

Do you really hang your entire --"sidechains are not a scaling solution"-- argument on this frail logic?

The scaling strategy (in LN and DC) is the same: try NOT to "show your transaction to everyone". The details are of course different.

I think largeblock sidechains should be reconsidered:
 * They are not a blocksize increase.
 * They endorse the principle of scaling in layers.
 * They allow users to be different. Some can pay more (for more decentralization), some less (for less decentralization).
    (We are currently gambling the entire future of BTC, on the premise that strong decentralization will always be needed at all points in time.)
    (This leaves us vulnerable to a strategy where our adversaries temporarily favor/promote centralized chains, so as to "domesticate" / control these in the future.)
 * We can learn from past mistakes -- when a new largeblock sidechain is needed, we can make a new one from scratch, using everything we know.
 * Different teams can compete, releasing different chains independently; thus curtailing "toxicity".
 * All of the fees, paid on all blockchains, arrive as revenue to the same group of miners, thus improving total hashrate/difficulty.
 * Sidechains will organize geographically, which may help security (ie, USA could spitefully run full nodes of the "China" largeblock sidechain).
 * Relative to LN, users enjoy: unlimited "inbound liquidity", can receive money while offline, no risk that the channel will close, etc.

Certainly, sidechains are NOT for everyone. (Just as [I imagine] the LN is not for everyone.)

However, in 2015, many hardfork-largeblockers said: "we do not run a full node, full nodes are not important; we use SPV; read the whitepaper" etc.
They used SPV completely; and wanted large blocks. Presumably they would be happy users of a largeblock sidechain. So it would be >0 users.

Sadly, this idea is neglected, (I think) because of its unfortunate resemblance to naive-largeblock-ism. This is irrational.

***

You have emphasized the following relation: "you have to show your transaction to everyone" = "thing doesn't scale".

However, in LN, there is one transaction which you must, in fact, "show to everyone": your channel-opener.

Amusingly, in the largeblock sidechain, there is not. You can onboard using only the blockspace of the SC.
(One "rich guy" can first shift 100k coins Main-to-Side, and he can henceforth onboard many users over there. Those users can then onboard new users, forever.)

So it would seem to me, that you are on the ropes, even by your own criterion. [Footnote 1]

***

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.

Paul


[Footnote 1]
I am certainly not a LN expert, so perhaps this analysis is misconceived. But consider these "best case scenario" assumptions for LN:
 * Each new channel-open consumes just 32 vbytes (since they are all done via one or more "rich men" who batches all these into one block, 24/7/365)
 * Each new channel-open, onboards 5 users at once who are a permanent trust group / channel factory / what-have-you
      (these five newcomers must coordinate with each other and the "rich man", presumably via calendly link or whatever, for their one shot at getting on the blockchain).
 * That one single channel is able to meet 100% of the user's payment needs
      (it never has any problems, with liquidity /balancing /routing /uptime /hotwallet-crashing /counterparty-fees /etc)
      (and also, people do NOT desire >1 channel for other reasons: their alt nyms, small business, church, etc)
 * 99.9% of the 1MB (vB) blocksize is used for channel-opens (the spare 1000 vb = the coinbase + the single "rich man"-input)
 * World population becomes a fixed 8.2 billion (and henceforth stops growing)

By simple envelop math, 6*24*365*(((1000000*.999)/32)*5) / 8.2 billion = ~exactly one year to onboard everyone.
But if the above assumptions contain, say, two orders of magnitude of "optimism", then it would instead take 100 years.
--------------k8qCMw50rbuzzLc0pF4oRaB8--