public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Robin Linus <robinlinus@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol
Date: Mon, 13 Jan 2020 02:02:53 +0000	[thread overview]
Message-ID: <2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@protonmail.com> (raw)
In-Reply-To: <Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com>

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 <ZmnSCPxj@protonmail.com> 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




  reply	other threads:[~2020-01-13  2:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-12 18:54 [bitcoin-dev] Coins: A trustless sidechain protocol Robin Linus
2020-01-13  0:21 ` ZmnSCPxj
2020-01-13  2:02   ` Robin Linus [this message]
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
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='2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@protonmail.com' \
    --to=robinlinus@protonmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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