From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Paul Sztorc <truthcoin@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Date: Sun, 27 Feb 2022 02:00:37 +0000 [thread overview]
Message-ID: <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com> (raw)
In-Reply-To: <0a6d4fea-2451-d4e7-8001-dd75a2e140ae@gmail.com>
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
next prev parent reply other threads:[~2022-02-27 2:00 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 17:20 [bitcoin-dev] " Russell O'Connor
2022-01-26 22:16 ` Jeremy
2022-01-27 4:20 ` James Lu
2022-01-27 19:16 ` Russell O'Connor
2022-01-28 0:18 ` James O'Beirne
2022-01-28 13:14 ` Michael Folkson
2022-01-28 14:17 ` Anthony Towns
2022-01-28 16:38 ` Jeremy
2022-01-28 14:13 ` Russell O'Connor
2022-01-28 15:14 ` James O'Beirne
2022-01-29 15:43 ` Russell O'Connor
2022-01-29 17:02 ` Jeremy Rubin
[not found] ` <CAD5xwhjHv2EGYb33p2MRS=VSz=ciGwAsiafX1yRHjxQEXfykSA@mail.gmail.com>
2022-01-29 17:14 ` Russell O'Connor
2022-01-31 2:18 ` Anthony Towns
2022-01-28 1:34 ` Anthony Towns
2022-01-28 13:56 ` Russell O'Connor
2022-02-01 1:16 ` Anthony Towns
2022-02-08 2:16 ` Russell O'Connor
2022-02-17 14:27 ` Anthony Towns
2022-02-17 14:50 ` Russell O'Connor
2022-02-08 3:40 ` Rusty Russell
2022-02-08 4:34 ` Jeremy Rubin
2022-02-11 0:55 ` [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " David A. Harding
2022-02-11 3:42 ` Jeremy Rubin
2022-02-11 17:42 ` James O'Beirne
2022-02-11 18:12 ` digital vagabond
2022-02-12 10:54 ` darosior
2022-02-12 15:59 ` Billy Tetrud
2022-02-17 15:15 ` Anthony Towns
2022-02-18 7:34 ` ZmnSCPxj
2022-02-23 11:28 ` ZmnSCPxj
2022-02-23 18:14 ` Paul Sztorc
2022-02-24 2:20 ` ZmnSCPxj
2022-02-24 6:53 ` Anthony Towns
2022-02-24 12:03 ` ZmnSCPxj
2022-02-26 5:38 ` Billy Tetrud
2022-02-26 6:43 ` ZmnSCPxj
2022-02-27 0:58 ` Paul Sztorc
2022-02-27 2:00 ` ZmnSCPxj [this message]
2022-02-27 7:25 ` ZmnSCPxj
2022-02-27 16:59 ` Billy Tetrud
2022-02-27 23:50 ` Paul Sztorc
2022-02-28 0:20 ` Paul Sztorc
2022-02-28 6:49 ` ZmnSCPxj
2022-02-28 7:55 ` vjudeu
2022-03-04 8:42 ` ZmnSCPxj
2022-03-04 13:43 ` vjudeu
2022-02-28 22:54 ` Paul Sztorc
2022-03-01 5:39 ` Billy Tetrud
2022-03-02 0:00 ` Paul Sztorc
2022-03-04 12:35 ` Billy Tetrud
2022-03-04 20:06 ` Paul Sztorc
2022-02-26 6:00 ` Anthony Towns
2022-02-15 8:45 ` [bitcoin-dev] " Rusty Russell
2022-02-15 18:57 ` Jeremy Rubin
2022-02-15 19:12 ` Russell O'Connor
2022-02-16 2:26 ` Rusty Russell
2022-02-16 4:10 ` Russell O'Connor
2022-02-14 2:40 [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " Lucky Star
2022-02-26 7:47 Prayank
2022-02-26 16:18 ` Billy Tetrud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=truthcoin@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox