Good morning Paul,
> ***
>
> 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.
Yes, using channel factories.
A channel factory is a N-of-N where N >= 3, and which uses the same offchain
technology to host multiple 2-of-2 channels.
We observe that, just as an offchain structure like a payment channel can host
HTLCs, any offchain structure can host a lot of *other* contracts, because the
offchain structure can always threaten to drop onchain to enforce any
onchain-enforceable contract.
But an offchain structure is just another onchain contract!
Thus, an offchain structure can host many other offchain structures, and thus
an N-of-N channel factory can host multiple 2-of-2 channel factories.
(I know we discussed sidechains-within-sidechains before, or at least I
mentioned that to you in direct correspondence, this is basically that idea
brought to its logical conclusion.)
Thus, while you still have to give *one* transaction to all Bitcoin users, that
single transaction can back several channels, up to (N * (N - 1)) / 2.
It is not quite matching your description --- the pubkeys of the peer
participants need to be fixed beforehand.
However, all it means is some additional pre-planning during setup with no
scope for dynamic membership.
At least, you cannot dynamically change membership without onchain action.
You *can* change membership sets by publishing a one-input-one-output
transaction onchain, but with Taproot, the new membership set is representable
in a single 32-byte Taproot address onchain (admittedly, the transaction input
is a txin and thus has overhead 32 bytes plus 1 byte for txout index, and you
need 64 bytes signature for Taproot as well).
The advantage is that, in the meantime, if membership set is not changed,
payments can occur *without* any data published on the blockchain (literally 0
data).
With sidechains, changing the ownership set requires that the sidechain produce
a block.
That block requires a 32-byte commitment in the coinbase.
What is more, if *any* transfers occur on the sidechain, they cannot be real
without a sidechain block, that has to be committed on the mainchain.
Thus, while changing the membership set of a channel factory is more expensive
(it requires a pointer to the previous txout, a 64-byte Taproot signature, and
a new Taproot address), continuous operation does not publish any data at all.
While in sidehchains, continuous operation and ordinary payments requires
ideally one commitment of 32 bytes per mainchain block.
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.
We assume that onboarding new members is much rarer than existing members
actually paying each other in an actual economy (after the first burst of
onboarding, new members will only arise in proportion to the birth rate, but
typical economic transactions occur much more often), so optimizing for the
continuous operation seems a better tradeoff.
Channel factories have the nice properties:
* N-of-N means that nobody can steal from you.
* Even with a 51% miner, nobody can steal from you as long as none of the N
participants is the 51% miner, see the other thread.
* Graceful degradation: even if if 1 of the N is offline, payments are done
over the hosted 2-of-2s, and the balance of probability is that most of the
2-of-2s have both participants online and payments can continue to occur.
--
The reason why channel factories do not exist *yet* is that the main offchain
construction we have, Poon-Dryja, is 2-of-2.
We have Decker-Wattenhofer, which supports N >= 2, but it needs to publish a
lot of onchain data in case of dispute, and has lousy UX due to how it uses
delays (you can only be safely offline for some small number of blocks, but you
have to wait out a large multiple of that parameter).
We also have the newer Decker-Russell-Osuntokun ("eltoo"), but that requires
`SIGHASH_NOINPUT`, which is now today called `SIGHASH_ANYPREVOUT`.
`OP_CTV` also is useful for publishing commitments-to-promised-outputs without
having to publish outputs right now.
This is why I want to focus on getting both on Bitcoin first, *before* any
recursive-contract-enabling technologies.
Admittedly, the recursive-covenant-enabling constructs look like they enable
functionality equivalent to `SIGHASH_NOINPUT` and `OP_CTV`, though as I
understand them, they would require more bytes than `SIGHASH_NOINPUT` or
`OP_CTV`.
And scaling is really improved by reducing the number of bytes published, so
there is value in merging in `SIGHASH_ANYPREVOUT` and `OP_CTV` at some point,
so why not now.
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
