From: Paul Sztorc <truthcoin@gmail•com>
To: 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 19:20:47 -0500 [thread overview]
Message-ID: <0af7c513-3df8-dcc8-9a14-e7e909e7fdc6@gmail.com> (raw)
In-Reply-To: <Q4kn8GILUIWV5OC37HgXG0xW99smVENze4bDw0esWqDsniVvokPAUN3muW-kNFkBMQlr5x7JlQAjUnmCN04W0uA_XCLxlLlBENNybBhFurc=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3654 bytes --]
next prev parent reply other threads:[~2022-02-28 0:20 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
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 [this message]
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=0af7c513-3df8-dcc8-9a14-e7e909e7fdc6@gmail.com \
--to=truthcoin@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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