From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Robin Linus <robinlinus@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol
Date: Tue, 14 Jan 2020 00:53:24 +0000 [thread overview]
Message-ID: <-XqpIGL2s4yhkiWLsuqhvfpQKm1iRdTZHoTy83d_rKW9bY0Qhz5WHxcET5JSzEMxQUXiq5e-VmDqgp2zZ8locphCSjnztSB_yNV_esq111s=@protonmail.com> (raw)
In-Reply-To: <6pcznun9_VnOIV7D28YeCiWqSLtPnN7syJvgGVp_VIo_DAZyp2mDYZQxg6IT5dJagroU-TKgUUjLrJm12TlbhLCzwjftY6_OhIB3ej6o44E=@protonmail.com>
Good morning Robin,
> Hi Joachim,
>
> > > Regarding Reason #1:
> > > This proposal is less like Bitcoin vs. Altcoins and much more like Ethereum vs. ERC20 tokens, because the derivatives are not in competition with BTC, but depend on it heavily. You support Bitcoin's growth by supporting such a sidechain.
> > > Also, they won't work as separate currencies. For endusers you can abstract away all underlying complexities such that they have to think only in BTC. Exchanges rates can be hidden in TX fees. The sidechain derivatives would be nothing but a means of transfer. The unit of account is still BTC.
> >
> > I can't see any difference and advantage over doing the same with say Litecoin. All you need is to create a special wallet which offers atomic swaps LTC-BTC and its unit of account displayed to user is going to be BTC. All you say will work perfectly with this special LTC wallet. Therefore your idea is as good as any other altcoin. In your case, someone else should indeed be able to create such a wallet in which the unit of account will be the new token, thus emulating the current LTC wallets. So the only difference in Litecoin is that the special wallet with BTC as unit is going to be created after the native one, while in your case it is vice versa.
> >
> > I simply can't see why I'd call this construction of yours a Bitcoin sidechain and any other altcoin not. So I'd call both altcoins.
>
> Let me try to explain where I am coming from: Whenever I want to onboard a not-so-techy friend to Bitcoin by sending him $5 worth of BTC, I don't have many good options. Usually we end up using BlueWallet. It works great. Though it only works so well because it is fully custodial. That is how they solve all the tough LN problems like inbound-capacity of new users, watchtowers and channel backends. Their service is just an Excel table connect to the LN. Unfortunately, that is the best UX we can currently offer to endusers. To me that's unsatisfying. Is that how we want to enter the emerging markets and on-board the next Billion users? I like that BlueWallet gives me the option to run my own LndHub for my friends. Still, does that scale globally? More importantly, do we want that?
>
> Now let's think about the altcoins argument. We want to serve a billion users. Blockchains do scale well to about a couple Million UTXOs, so we require a network of a couple thousand altcoins to serve our users.
> We know how to build a nice LN for all of our altcoins with a star-shaped topology around Bitcoin as the central settlement layer. Atomic swaps FTW. We can abstract away their native currencies. We display to our users only BTC, hide the exchange rates in the TX fees and we're done. That is actually a scalability solution. So why don't we do that?
Because Lightning remains a superior *scalability* solution to microchains.
(The below is a Fermi estimate; it is intended to give an intuition on the rough orders of magnitude that we are discussing, not strict predictions of how the world works)
Let us suppose that N users would produce N * t bytes of transactions.
Under Lightning, that data is sent to a tiny subset of the entire LN.
As Lightning limits routes to at most 20 hops, let us take the worst case and say that under Lightning, those users will force 20 * N * t bytes to be processed globally.
If all users were to use a *single* blockchain, because all users must process all transactions within the blockchain, that will mean everyone has to process N * N * t bytes.
Now the microchain concept is that, we can split the N in half, so instead of a single N * N * t bytes being processed, we get two (N / 2) * (N / 2) * t, or more generally, if there are c chains: c * ((N / c) ^ 2) * t or N * N * t / c.
So for microchains to beat Lightning, you would have to make N * N * t / c < 20 * N * t, or equivalently N / c < 20, i.e. 20 users per sidechain.
If you have as low as 20 users per sidechain, you might as well just use channel factories to host Lightning channels, so channel factories + channels (i.e. Lightning Network) is probably better than having tiny sidechaisn with 20 users each.
Again the above is a very rough Fermi estimate, but it gives you a hint on the orders of magnitude you should consider, i.e. about a few dozen users per sidechain, and a few dozens users in a sidechain is probably not a lot to give security to that sidechain, whereas with Lightning channel factories you can drop onchain any time to upgrade your security to the full mining hashpower (and we hope that the threat of being able to do so is enough to discourage attempts at theft).
What Lightning cannot do is add certain kinds of features other than scalability, for example Turing-complete disasters (RSK) or confidential assets (LBTC).
Sidechains are for features, not scale, so your proposed sidechain concept remains of interest at least as a possible way to anchor sidechains with new features.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-01-14 0:53 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-12 18:54 Robin Linus
2020-01-13 0:21 ` ZmnSCPxj
2020-01-13 2:02 ` Robin Linus
2020-01-13 2:33 ` ZmnSCPxj
2020-01-13 17:34 ` Joachim Strömbergson
2020-01-13 22:05 ` Jeremy
2020-01-16 1:21 ` Angel Leon
2020-01-13 18:06 ` Joachim Strömbergson
2020-01-13 19:47 ` Robin Linus
2020-01-13 20:49 ` Joachim Strömbergson
2020-01-13 22:22 ` Robin Linus
2020-01-14 0:53 ` ZmnSCPxj [this message]
2020-01-14 2:19 ` Robin Linus
2020-01-14 2:59 ` ZmnSCPxj
2020-01-14 4:12 ` Robin Linus
2020-01-14 15:06 ` Joachim Strömbergson
2020-01-14 15:26 ` ZmnSCPxj
2020-01-15 1:43 ` Robin Linus
2020-01-15 5:46 ` ZmnSCPxj
2020-01-17 4:17 ` Robin Linus
2020-01-17 13:54 ` ZmnSCPxj
2020-01-18 8:21 ` Robin Linus
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='-XqpIGL2s4yhkiWLsuqhvfpQKm1iRdTZHoTy83d_rKW9bY0Qhz5WHxcET5JSzEMxQUXiq5e-VmDqgp2zZ8locphCSjnztSB_yNV_esq111s=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=robinlinus@protonmail$(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