path: root/78/e06436214037e023ca55c1dcfc324edf689fd4

Return-Path: <gubatron@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7AD8BC077D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Jan 2020 01:22:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 666BF85A37
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Jan 2020 01:22:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xZR7vAxTB68v
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Jan 2020 01:22:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com
 [209.85.166.42])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 8678884B6F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 16 Jan 2020 01:22:04 +0000 (UTC)
Received: by mail-io1-f42.google.com with SMTP id k24so19934210ioc.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jan 2020 17:22:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=Tmt/rH2VOVk8lzz3FL1n/HbgtF6EANDwF4P2I9DL8q0=;
 b=ACG46r4vlAi0S9gMqEc4NjvrJnWbh+FgMBdC6h9aT60IzU4flZPuW0kkUsfCc7RUK+
 Cr1ObZVfsio67uCjLsCFTx///lKJ6KtIpFTukzbFYlxAboSweiFWC4n4eURZYJn5nJgc
 96cXQPuoaUvsTbKQRB29OwhhHRFu0LvVwCb5JHkYBJEpzYHKm2WNEQNwGtooXPAc9IfZ
 JQm++irz4QJKRDowVxARsY6v9LA9ze4Ad0LmnpASVFdGxuWEllHjaFTbVAjH44mw5y1L
 LH0Ef7kReWdobng1CWyUpIfe12AgznEBc1gxjC/ubphGy83mnyvCNi8nvUZhlldPGKrT
 cLqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=Tmt/rH2VOVk8lzz3FL1n/HbgtF6EANDwF4P2I9DL8q0=;
 b=DSxCNfSy5qvwTsT5DvUOx+EoYgKmdJSItf0YXwT1AEIENjRH6Cy9LxCGQemXHftOxZ
 g68lybDGm5Z+UGNn/wLfDtnbN670VbxKoPYAsD0tU63htoGr/mDGMJ9W9YwbMllKKe6S
 z9+QoByqAwl46HHoJQBYTBTRDiwAurcS77EXiqjF4Vk8x7tDjb/pyKWjVvofse6I6eIk
 USTK+ckxTnjmqNp+es4+ZmwNg1Hs3hrQJnHdzXUVdKCFGquK2PzuNNA/A9T/HzIwzjIB
 Z6k+k3P2uFb/JRZYcRtxcOUmzTJxazAL76OTG/bbD+VA94JETnGrEZOvf23TNsWCU6pk
 UAVQ==
X-Gm-Message-State: APjAAAVrh+lsYS9E3zWdFM0Ll87DT3U2R6kTYm4GAgcS8/qHaN/aOOfJ
 dDtvnBw51g5aez9yy8EjRxAIlrNQ/ZzQ0ygDXr0=
X-Google-Smtp-Source: APXvYqyBEw7urItEV6Aqm63WktFVTykk70CC8+9ckrOsKH8v9nUqBb0VtKRXvQ0oOqvg9O+fHoPa2nuRrW2VynA2eXw=
X-Received: by 2002:a6b:1443:: with SMTP id 64mr23235635iou.116.1579137723691; 
 Wed, 15 Jan 2020 17:22:03 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <P-QnOpNsFdehy_F3FJgAr0lSJ2xtmT5cwRsEC8VfnIUrSgfNDkLNizm2L1TG65AhKM430tzJ9p33WBnSmJ92ZTKEoaKXCTQzVKrZkH9vtn4=@protonmail.com>
From: Angel Leon <gubatron@gmail.com>
Date: Wed, 15 Jan 2020 18:21:52 -0700
Message-ID: <CADZB0_ZcJawjSBBE9nHLcFrHoZofDt-8pw4Xx980zp8OCjN6CA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000127a31059c37a79c"
X-Mailman-Approved-At: Thu, 16 Jan 2020 01:28:23 +0000
Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2020 01:22:07 -0000

--000000000000127a31059c37a79c
Content-Type: text/plain; charset="UTF-8"

> 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.

That's right, all you need to broadcast is a small proof, a non-interactive
blockchain suffix proof
https://eprint.iacr.org/2017/963.pdf



On Sun, Jan 12, 2020 at 7:33 PM 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
> 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.
>
>
> Which is why I brought up multiparticipant offchain updateable
> cryptocurrency 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-Osuntokun constructions.
> You can even use the Somsen "statechain" mechanism, which rides a
> Decker-Wattenhofer/Decker-Russell-Osuntokun construction, though its
> trust-minimization is only very very slightly better than federated
> sidechains.
>
> It is helpful to remember that Poon-Dryja, Decker-Wattenhofer,
> Decker-Russell-Osuntokun, and all other future such constructions, can host
> any contract 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
> blockchain, you can host a Poon-Dryja inside the Decker-Wattenhofer, since
> the Bitcoin blockchain can host Poon-Dryja channels.
> This central insight leads one to conclude that anything you can put
> onchain, 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
> timelocks: 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 create a layer that supports changes to the channel topology (where
> changes to 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
> services, only their customers need to know those internal ledgers, and
> sign off on the updates of those ledgers.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000127a31059c37a79c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; Instead of using sidechains, just use channel factori=
es.<br>
&gt; You do not need to broadcast the entire internal ledgers of those=20
services, only their customers need to know those internal ledgers, and=20
sign off on the updates of those ledgers.<div><div dir=3D"ltr" class=3D"gma=
il_signature" data-smartmail=3D"gmail_signature"><br></div><div class=3D"gm=
ail_signature" data-smartmail=3D"gmail_signature">That&#39;s right, all you=
 need to broadcast is a small proof, a non-interactive blockchain suffix pr=
oof<br><a href=3D"https://eprint.iacr.org/2017/963.pdf">https://eprint.iacr=
.org/2017/963.pdf</a><br><br></div></div><br></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 12, 2020 at 7:33 P=
M ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Robin,<br>
<br>
<br>
&gt; Good morning ZmnSCPxj,<br>
&gt;<br>
&gt; Thank you for your detailed feedback! Two topics:<br>
&gt;<br>
&gt; Lightning vs Sidechains<br>
&gt;<br>
&gt; ------------------------<br>
&gt;<br>
&gt; Why an either-or-solution, if we can connect sidechains via the LN to =
get the best of both worlds?<br>
&gt;<br>
&gt; The LN works exceptionally great under the following conditions:<br>
&gt;<br>
&gt; -=C2=A0 =C2=A0you&#39;re always online<br>
&gt; -=C2=A0 =C2=A0you have BTC to manage your channels&#39; inbound-capaci=
ty<br>
&gt; -=C2=A0 =C2=A0you can afford BTC transactions<br>
&gt;=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0in your channel is much more than the=
 minimum on-chain TX fees<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The next Billion users do not fit tha=
t category. They are on unreliable cell phone connections and do not have a=
ny BTC yet.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0And the more popular Bitcoin becomes,=
 the fewer people can afford LN channels. Even Eltoo requires your funds to=
 be significantly higher than Bitcoin&#39;s TX fees, right?<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Already today, more and more services=
 like <a href=3D"http://tippin.me" rel=3D"noreferrer" target=3D"_blank">tip=
pin.me</a>, BlueWallet, etc, provide custodial solutions.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For small amounts, custody is an acce=
ptable 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&#39;d be back to trusting banks with their Exc=
el sheets.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So let&#39;s make their internal ledg=
ers public and trustless, via independent sidechains. Decentralized Blockch=
ains do scale decently up to a couple Million UTXOs. So a couple thousand S=
idechains is probably sufficient for a global medium of exchange. Cross-cha=
in communication without requiring cross-chain validation is possible via a=
tomic swaps and through Bitcoin&#39;s LN. That scales because it separates =
chain-validators from swap-validators.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bitcoin&#39;s LN acts as the central =
settlement layer for efficient cross-chain transactions between all sidecha=
ins.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So Endusers &quot;living&quot; in sid=
echains instead of directly in the LN has many advantages:<br>
&gt;<br>
&gt; -=C2=A0 =C2=A0no bitcoin blockspace required for on-boarding new users=
<br>
&gt; -=C2=A0 =C2=A0no need to lock funds to provide inbound-capacity<br>
&gt; -=C2=A0 =C2=A0no need to stay online or pay watch towers<br>
&gt; -=C2=A0 =C2=A0no need to store channel histories<br>
&gt; -=C2=A0 =C2=A0account balances can be much smaller than BTC TX fees<br=
>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0Those are the exact same reasons why BlueWallet bui=
lt their LndHub. But sidechains can be trustless. Also a generic protocol p=
rovides flexibility for sidechain innovations with arbitrary digital assets=
 and consensus rules.<br>
<br>
<br>
Which is why I brought up multiparticipant offchain updateable cryptocurren=
cy systems.<br>
The &quot;channel factories&quot; concepts does what you are looking for, e=
xcept with better trust-minimization than sidechains can achieve.<br>
Just replace &quot;sidechain&quot; with either Decker-Wattenhofer or Decker=
-Russell-Osuntokun constructions.<br>
You can even use the Somsen &quot;statechain&quot; mechanism, which rides a=
 Decker-Wattenhofer/Decker-Russell-Osuntokun construction, though its trust=
-minimization is only very very slightly better than federated sidechains.<=
br>
<br>
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.<br>
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.<b=
r>
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.<br>
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?<br>
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.<br>
<br>
Instead of using sidechains, just use channel factories.<br>
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.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000127a31059c37a79c--