Date: Mon, 13 Jan 2020 02:33:21 +0000
To: Robin Linus <robinlinus@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@protonmail.com>
In-Reply-To: <2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@protonmail.com>
References: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com>
 <Qa9HJ5p2bYnXsjvgcTz-J_stEwJ80SU9UTZF5abv96i5eM_6y3pmy9Bu4tEnFXOc_lBs-y2BFoMh4xOGjl2US56hAFPvxDZM2eyhJkEdBLM=@protonmail.com>
 <2mw_wd_ocLESpSG9ST3yJBsJriHf1l5LsdQ2jLamTUUKTMmwUpcjEeohClnMHJl4qjXNW9mHQJiK65jmDHfLG3-nVSRse9PdXnXokGZ2_ac=@protonmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol
Precedence: list

Good morning Robin,


> 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 unre=
liable 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 tha=
n 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 lov=
e their usability. Install it and immediately I can send you $0.01. Yet, sc=
aling 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 in=
dependent sidechains. Decentralized Blockchains do scale decently up to a c=
ouple Million UTXOs. So a couple thousand Sidechains is probably sufficient=
 for a global medium of exchange. Cross-chain communication without requiri=
ng cross-chain validation is possible via atomic swaps and through Bitcoin'=
s LN. That scales because it separates chain-validators from swap-validator=
s.
>         Bitcoin's LN acts as the central settlement layer for efficient c=
ross-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. B=
ut sidechains can be trustless. Also a generic protocol provides flexibilit=
y for sidechain innovations with arbitrary digital assets and consensus rul=
es.


Which is why I brought up multiparticipant offchain updateable cryptocurren=
cy systems.
The "channel factories" concepts does what you are looking for, except with=
 better trust-minimization than sidechains can achieve.
Just replace "sidechain" with either Decker-Wattenhofer or Decker-Russell-O=
suntokun constructions.
You can even use the Somsen "statechain" mechanism, which rides a Decker-Wa=
ttenhofer/Decker-Russell-Osuntokun construction, though its trust-minimizat=
ion is only very very slightly better than federated sidechains.

It is helpful to remember that Poon-Dryja, Decker-Wattenhofer, Decker-Russe=
ll-Osuntokun, and all other future such constructions, can host any contrac=
t that its lower layer can support.
So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can host =
HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs.
Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin blockchai=
n, you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bitco=
in blockchain can host Poon-Dryja channels.
This central insight leads one to conclude that anything you can put onchai=
n, you an generally also put offchain, so why use a chain at all except as =
an ultimate anchor to reality?
Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits the=
 practical number of updates due to its use of decrementing relative timelo=
cks: so you put the payment layer in a bunch of Poon-Dryja channels which s=
upport tons of updates each but only two participants per channel, and crea=
te a layer that supports changes to the channel topology (where changes to =
the channel connectivity are expected to be much rarer than payments) and i=
s multiparticipant so you can *actually* scale.

Instead of using sidechains, just use channel factories.
You do not need to broadcast the entire internal ledgers of those services,=
 only their customers need to know those internal ledgers, and sign off on =
the updates of those ledgers.

Regards,
ZmnSCPxj