> 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.
The sidechain can push zero bytes on-chain, just by placing a sidechain hash in
OP_RETURN inside TapScript. Then, every sidechain node can check that "this
sidechain hash is connected with this Taproot address", without pushing 32
bytes on-chain.
On 2022-02-28 08:13:03 user ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning Paul,
> 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.
I am not wrong about this.
You can cut-through the closure of one channel factory with the opening of
another channel factory with the same 5 fixed pubkeys *plus* an additional 100
new fixed pubkeys.
With `SIGHASH_ANYPREVOUT` (which we need to Decker-Russell-Osuntokun-based
channel factories) you do not even need to make new signatures for the existing
channels, you just reuse the existing channel signatures and whether or not the
*single*, one-input-one-output, close+reopen transaction is confirmed or not,
the existing channels remain usable (the signatures can be used on both
pre-reopen and post-reopen).
That is why I said changing the membership set requires onchain action.
But the onchain action is *only* a 1-input-1-output transaction, and with
Taproot the signature needed is just 64 bytes witness (1 weight unit per byte),
I had several paragraphs describing that, did you not read them?
Note as well that with sidechains, onboarding also requires action on the
mainchain, in the form of a sideblock merge-mined on the mainchain.
>
> > 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.
Fortunately even without channel factories the onboarding rate of LN is much
much higher than that.
I mean, like, LN *is* live and *is* working, today, and (at least where I have
looked, but I could be provincial) has a lot more onboarding activity than
half-hearted sidechains like Liquid or Rootstock.
> 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'
> ".
Your numbers absolutely suck and have no basis in reality, WTF.
Even without batched channel openings and a typical tranaction of 2 inputs, 1
LN channel, and a change output, you can onboard ~1250 channels per mainchain
block (admittedly, without any other activity).
Let us assume every user needs 5 channels on average and that is still 250
users per 10 minutes.
I expect channel factories to increase that by about 10x to 100x more, and then
you are going to hit the issue of getting people to *use* Bitcoin rather than
many users wanting to get in but being unable to due to block size limits.
>
> > 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
Yes, and 33% of the planet want to use Bitcoin in the next month.
The onboarding rate only needs to be as fast as the rate at which people want
to join Bitcoin, and any security you sacrifice in order to get a higher number
than that is security you are sacrificing needlessly for extra capacity you are
unable to utilize.
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.
Now of course there is always the possibility that the 51% miner is in *every*
channel factory globally.
But there is also the possibility that the 51% miner exists, but is *not* on
every channel factory.
Indeed, for any arbitrary channel or factory, I expect that the probability of
the 51% miner being a member is less than 100%, thus the combined probability
is lower than Drivechains.
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).
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
