Date: Mon, 13 Jan 2020 17:34:17 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= <joachimstr@protonmail.com>
Reply-To: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= <joachimstr@protonmail.com>
Message-ID: <-8y3dnfO2vpyLPeOF5scfp0c5AZd9FF-_xkr1jL2iT1j02fSMJHix2YQupuOeBRF9v5icwGQbriKFXqd5B1AusZp0X7ENOvQ_q4OGCazueU=@protonmail.com>
In-Reply-To: <P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@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>
 <P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@protonmail.com>
Feedback-ID: rtGq1wInl4cYyZOA2iZwaHP-4FBFY67Qt3DcVBMZh8YR1tV-3hijnv7SxpdDwGlNdSPgHEykKLn6PcHDKa0D8A==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol
Precedence: list

> Instead of using sidechains, just use channel factories.

I am not familiar enough with the latest advancements in this field. Is it =
possible using LN/channel factories to achieve off-line-like participation =
user experience without previous registration with any kind of gateway prov=
ider? For example, can you go online, join the network [somehow instantly],=
 generate address/invoice and then put it somewhere for others to later use=
 it when you are off-line? Can you also participate while being off-line fo=
r very long periods of time without relying on third party providers to sec=
ure your channels? If not, is using sidechains really equally replaceable w=
ith LN/CF constructions?








Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Monday, January 13, 2020 2:33 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:

> 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 g=
et 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 un=
reliable cell phone connections and do not have any BTC yet.
> >         And the more popular Bitcoin becomes, the fewer people can affo=
rd LN channels. Even Eltoo requires your funds to be significantly higher t=
han Bitcoin's TX fees, right?
> >         Already today, more and more services like tippin.me, BlueWalle=
t, etc, provide custodial solutions.
> >         For small amounts, custody is an acceptable workaround. And I l=
ove 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 sufficie=
nt for a global medium of exchange. Cross-chain communication without requi=
ring cross-chain validation is possible via atomic swaps and through Bitcoi=
n's LN. That scales because it separates chain-validators from swap-validat=
ors.
> >         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 L=
N 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 flexibil=
ity for sidechain innovations with arbitrary digital assets and consensus r=
ules.
> >
>
> Which is why I brought up multiparticipant offchain updateable cryptocurr=
ency systems.
> The "channel factories" concepts does what you are looking for, except wi=
th better trust-minimization than sidechains can achieve.
> Just replace "sidechain" with either Decker-Wattenhofer or Decker-Russell=
-Osuntokun constructions.
> You can even use the Somsen "statechain" mechanism, which rides a Decker-=
Wattenhofer/Decker-Russell-Osuntokun construction, though its trust-minimiz=
ation is only very very slightly better than federated sidechains.
>
> It is helpful to remember that Poon-Dryja, Decker-Wattenhofer, Decker-Rus=
sell-Osuntokun, and all other future such constructions, can host any contr=
act that its lower layer can support.
> So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can hos=
t HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs.
> Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin blockch=
ain, you can host a Poon-Dryja inside the Decker-Wattenhofer, since the Bit=
coin blockchain can host Poon-Dryja channels.
> This central insight leads one to conclude that anything you can put onch=
ain, you an generally also put offchain, so why use a chain at all except a=
s an ultimate anchor to reality?
> Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits t=
he practical number of updates due to its use of decrementing relative time=
locks: so you put the payment layer in a bunch of Poon-Dryja channels which=
 support tons of updates each but only two participants per channel, and cr=
eate a layer that supports changes to the channel topology (where changes t=
o the channel connectivity are expected to be much rarer than payments) and=
 is 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 service=
s, only their customers need to know those internal ledgers, and sign off o=
n the updates of those ledgers.
>
> Regards,
> ZmnSCPxj
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev