What is Nostr?
Paul Sztorc [ARCHIVE] /
npub10tqā€¦9uu9
2023-06-07 23:03:37
in reply to nevent1qā€¦q0vs

Paul Sztorc [ARCHIVE] on Nostr: šŸ“… Original date posted:2022-02-26 šŸ“ Original message:On 2/26/2022 1:43 AM, ...

šŸ“… Original date posted:2022-02-26
šŸ“ Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220226/58dfa5d7/attachment.html>;
Author Public Key
npub10tqt6wdc2neye0cxwyphtre6n5uccgur94khtqjdry9wxhrvywlq6w9uu9