On 2/28/2022 1:49 AM, ZmnSCPxj wrote:
...
...
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.
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 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 membership set requires onchain action.
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 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
strangers, spontaneously organize into 1000 factories of 55 people each, (50
newbies 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" is not quite
airtight, because in the case of onboarding the situation 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 join
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 at 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.
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 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 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).
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
