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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
