Good morning ZmnSCPxj,
Thank you for your detailed feedback! Two topics:
## Lightning vs Sidechains
Why an either-or-solution, if we can connect sidechains via the LN to get the
best of both worlds?
The LN works exceptionally great under the following conditions:
- you're always online
- you have BTC to manage your channels' inbound-capacity
- you can afford BTC transactions
- in your channel is much more than the minimum on-chain TX fees
The next Billion users do not fit that category. They are on unreliable cell
phone connections and do not have any BTC yet.
And the more popular Bitcoin becomes, the fewer people can afford LN channels.
Even Eltoo requires your funds to be significantly higher than Bitcoin's TX
fees, right?
Already today, more and more services like tippin.me, BlueWallet, etc, provide
custodial solutions.
For small amounts, custody is an acceptable workaround. And I love their
usability. Install it and immediately I can send you $0.01. Yet, scaling their
approach globally does not lead to desirable outcomes, since we'd be back to
trusting banks with their Excel sheets.
So let's make their internal ledgers public and trustless, via independent
sidechains. Decentralized Blockchains do scale decently up to a couple Million
UTXOs. So a couple thousand Sidechains is probably sufficient for a global
medium of exchange. Cross-chain communication without requiring cross-chain
validation is possible via atomic swaps and through Bitcoin's LN. That scales
because it separates chain-validators from swap-validators.
Bitcoin's LN acts as the central settlement layer for efficient cross-chain
transactions between all sidechains.
So Endusers "living" in sidechains instead of directly in the LN has many
advantages:
- no bitcoin blockspace required for on-boarding new users
- no need to lock funds to provide inbound-capacity
- no need to stay online or pay watch towers
- no need to store channel histories
- account balances can be much smaller than BTC TX fees
Those are the exact same reasons why BlueWallet built their LndHub. But
sidechains can be trustless. Also a generic protocol provides flexibility for
sidechain innovations with arbitrary digital assets and consensus rules.
## Collateral Contract
Thanks for mentioning that! I like the simplicity of your variant! It's better
than my workarounds. I'll add it to the paper. However, in the long term, the
cleanest solution is to destroy the funds. Giving it to miners assumes Alice
does not control much Hash power, which is harder to reason about.
Regards,
robin
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 13, 2020 1:21 AM, ZmnSCPxj <[email protected]> wrote:
> Good morning Robin,
>
> The reason why I stopped considering sidechains for scaling and have since
> moved to Lightning Network development was that, on reflection, I realized
> sidechains still do not scale, even with stakes anchored on the mainchain.
> The issue is that sidechains, like any blockchain, still require that
> everyone interested in it to propagate all their transaction to everyone else
> interested in it.
> Contrast this with Lightning Network, where you select only a tiny handful of
> nodes to inform about your payment, even if you have a gigantic Lightning
> Network.
>
> Or, more blithely: Let me get this straight, you already know blockchains
> cannot scale, so your scaling proposal involves making more blockchains?
>
> You might point to the use of large numbers of sidechains with limited
> userbase, and the use of cross-chain atomic swaps to convert between
> sidecoins.
> I would then point out that Lightning Network channel are cryptocurrency
> systems with two users (with significantly better security than a 2-user
> sidechain would have), and that Lightning Network payment routing is just the
> use of cross-channel atomic swaps to convert between channelcoins.
> Indeed, with a multiparticipant offchain updateable cryptocurrency system
> mechanism, like Decker-Wattenhofer or Decker-Russell-Osuntokun ("eltoo"), you
> could entirely replace sidechains with a mechanism that does not give custody
> to your funds to anyone else, since you can always insist on using n-of-n
> signing with you included in the signer set to prevent state changes that do
> not have your approval.
>
>
>
> Regards,
> ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
