path: root/90/24b014f856d58b664207a1ffbb7ccdffdf593a

Return-Path: <robinlinus@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C48E2C077D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jan 2020 01:43:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id AB250875B3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jan 2020 01:43:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zYpituVcgxN1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jan 2020 01:43:18 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
 [185.70.40.135])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 82B8C85E3A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Jan 2020 01:43:18 +0000 (UTC)
Date: Wed, 15 Jan 2020 01:43:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=default; t=1579052595;
 bh=84GjKth7ZFklPs68+eXTDi/aLq9XhPcFtbPMWAcEw1c=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
 Feedback-ID:From;
 b=eu1aVT9hpqCGdue56XmKuIoqDN7EJg6Hbbs29sQhrZCVRzUcgtOn8aOA5bx53RDT8
 RVHFUwOml241IIycCVNooUvA08fXEe6pk1w1c6tCdkKbMOZD0vU6BzLzy/gf5acF2P
 HziMNf0YHFVhRJl8UWmK2ukI7NQAqqQxtrAFMIBQ=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: Robin Linus <robinlinus@protonmail.com>
Reply-To: Robin Linus <robinlinus@protonmail.com>
Message-ID: <9ojpE1QHVyo_xJXqJFREMWLfYkJDJYIRMHNJ_WUazaWeO02KOqPU6GOaimSv0RwzACi5L4xM8K6p1x5vQOtMGchPSU3-J_EVDLUa807dGmw=@protonmail.com>
In-Reply-To: <FMYpymM9ePfMzdSqBtwf5oRl4bL6XMmDkCrwWMqBW8CK-lz4d0zjpk4oDuU7lWa16wV3Tmtnjd4LTs8Oi8-BIz_ce1rp-jK8ot9Apeo48BA=@protonmail.com>
References: <kAPCabG_c_AiGFYny48dO7ZT-MUgINLLoiKdzElSN8IrRej9szT3t9s0FvAHihraSo0CftPwFjU_pxvKuu9SziIJFt2JZxO3rdpS3-CMKzg=@protonmail.com>
 <ILtIOT_2wq-ld0mk5kPev5mw8RQD6pgzSF_EPuY1PE-mdsy8eJqsCaSU-zIyNZw-4W4p5JtLJs5d451PnHvQly-3V1q225bKmdanMZVOmGE=@protonmail.com>
 <0RSAH-PjblJV6Q7TGosFHAEdc9QGauCQ_knCzMwcoGdW4Qt49ts-egDkIwM-X_f0RjsPMquwdnmB6spunH379ICEAJQgUH7R1SE8CuZs7pI=@protonmail.com>
 <6JaReZbjL3U0QrirtiCdgk107cNmQHiLbbJIDctf8uGUiqJOLvZwRLLPUQXAjzfAqRQBpaqtytcKhq1hvtSDwwaKGthwy40SWHDRnTpBkJA=@protonmail.com>
 <6pcznun9_VnOIV7D28YeCiWqSLtPnN7syJvgGVp_VIo_DAZyp2mDYZQxg6IT5dJagroU-TKgUUjLrJm12TlbhLCzwjftY6_OhIB3ej6o44E=@protonmail.com>
 <beLVDOWDR2iV7hnmLpR4bBal2QWxAYqayzw8r9CRc5afhyqZjGIQZQZEerwIIXcmRC9KFigFDFu5_CU4vxoeLFxhNrDGUaZy44_JOs3asmk=@protonmail.com>
 <FMYpymM9ePfMzdSqBtwf5oRl4bL6XMmDkCrwWMqBW8CK-lz4d0zjpk4oDuU7lWa16wV3Tmtnjd4LTs8Oi8-BIz_ce1rp-jK8ot9Apeo48BA=@protonmail.com>
Feedback-ID: 6FfHo99INKExF0tkDkemTyDa-LNBAaNSuYGo9F4rOzppmymRaL_liHzoQTtSnq1Ib2NLN4047Io_xKQzk5eD1w==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 15 Jan 2020 01:46:56 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Wed, 15 Jan 2020 01:43:21 -0000

Good morning everybody!

Thanks again for your detailed feedback.

Maybe you're right and my solution is just crap :) So back to the drafting =
table!

It seems to be a good idea to separate problem definition and solution. Her=
e I tried to nail down LN's usability issue:
https://github.com/coins/coins.github.io/blob/master/notes/lightning-networ=
k.md
Would be great to hear your thoughts on that. Do we generally agree that Bi=
tcoin has to work well on mobiles? Where do your opinions differ?

If you are open to sidechains in general, we are discussing mostly consensu=
s mechanisms.
The consensus mechanism of custodial LN services is some trusted server som=
ewhere, with a single hot key and no public auditability.
That's state of the art LN experience on mobile. And it's worse than fiat b=
anks.

Yes, Liquid's trusted federation is much better than such custodial service=
s. Still, how does it scale globally? Lots of trusted federations?
Probably, we all favor a more trust-minimized sidechain consensus mechanism=
.

Most likely, it is impossible to produce decentralized consensus without co=
nsuming an external resource.
Furthermore, decentralized consensus requires an honest majority. Thus, fra=
gmenting the consumption of the available resources over multiple chains we=
akens every chain proportionally. Therefore, whatever consensus mechanism w=
e choose, the number of sidechains should be as small as possible. By impli=
cation, sidechains have to be as large as possible.

The market simply has no capacity to secure thousands of chains, if they do=
n't have millions of users each.
Consensus resource consumption is a winner takes all market, until a sidech=
ain becomes so full, that a further chain becomes profitable. Secure and pr=
ofitable sidechains require strong network effects. Otherwise, there's a do=
wnwards spiral of no users which leads to no stakers and vice versa. Needle=
ss sidechains die off quickly.


Regarding proof-of-burn: In theory, you could build a pure proof-of-burn si=
dechain which is literally as secure as Bitcoin's consensus. If you burn ab=
out 12.5 BTC for every sidechain block, then the sidechain is exactly as co=
stly to produce as Bitcoins blockchain. So regardless of the practicality, =
the theoretical security argument of PoB is very sound, or am I missing som=
ething?

If it is, then can't we build some PoS / PoB construction to secure sidecha=
ins?


Regarding 2-way peg and "a new asset for every chain is bad". Let's look at=
 my real world bank account. There are no real dollars in it. No legal tend=
er.
It's just my bank's derivative of the Dollar, representing their promise to=
 give me my Dollars whenever I want.
Note that my bank's altcoin is not pegged 1:1 to the legal tender issued by=
 the central bank. In the background they're balancing their books.
All that is hidden from me as a customer. They know, I just want to facilit=
ate payments in USD. As a customer I do not care about their underlying fin=
ancial instruments. That's why I'd assume, that sidechain assets can be use=
d as an instrument of BTC value transfer, without a 1:1-peg to BTC.
The only thing that really matters, is liquidity for atomic swaps to pay LN=
 invoices denominated in BTC. That again, is a matter of network effects of=
 a sidechain.


Thanks again,
-Robin







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 Tuesday, January 14, 2020 4:26 PM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wr=
ote:

> As well I would like to point out that in order to receive funds, somethi=
ng has to be online to get the message that receives the data.
> In the blockchain layer this is diffused among all fullnodes.
>
> At the Lightning layer, your direct peer could hold off on failing an inc=
oming payment while you are offline.
> Instead, it could simply stall until the outgoing HTLC would reach its ti=
melock anyway.
> Then you can come online and then the peer can send the HTLC to you and y=
ou can claim it.
> This remains noncustodial as the direct peer cannot steal the funds from =
you.
> I believe there was some discussion regarding this on lightning-dev in th=
e past few months.
> However, it does require that the peer know that you are the final recipi=
ent (if not, it would be unable to fail the HTLC as quickly as possible), t=
hus a privacy leak.
>
> In any case some node has to be online in order for anyone to receive fun=
ds, whether onchain or not: it is simply that a widespread blcokchain is ve=
ry very likely to have some online node capable of storing the payment unti=
l you can come online to process it.
> What you propose splits up the fullnodes into many tiny sidechains, such =
that a sidechain may get stalled and you would be unable to receive a payme=
nt anyway while you are offline, because there are far fewer nodes per side=
chain in order for such mass sidechains to start beating the raw scaling Li=
ghtning brings.
>
> Regards,
> ZmnSCPxj
>
> > Hi Robin.
> > While your motivation seems reasonable, your solution is not. It is not=
 enough that a problem exists. Although the solution must be technically so=
und for the proposal to be interesting. So I agree it makes sense to consid=
er Bitcoin sidechains, not sure if with PoS consensus or other, but no one =
yet proposed a viable solution, other than Federation based sidechains. You=
r proposal explored a single specific PoS sidechain, which to me does not s=
ound interesting. Maybe you can improve it, maybe not.
> > I also disagree that it is okay if anyone can halt operation of a sidec=
hain with just tiny investment. For me that is critical security flaw of yo=
ur proposal. By enforcing stakers having to stake per chain you have actual=
ly lowered the cost for the attacker to attack each specific chain.
> > 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 Origina=
l Message =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 10:22 PM, Robin Linus robinlinus@protonmail=
.com wrote:
> >
> > > Hi Joachim,
> > >
> > > > > Regarding Reason #1:
> > > > > This proposal is less like Bitcoin vs. Altcoins and much more lik=
e Ethereum vs. ERC20 tokens, because the derivatives are not in competition=
 with BTC, but depend on it heavily. You support Bitcoin's growth by suppor=
ting such a sidechain.=C2=A0
> > > > > Also, they won't work as separate currencies. For endusers you ca=
n abstract away all underlying complexities such that they have to think on=
ly in BTC. Exchanges rates can be hidden in TX fees. The sidechain derivati=
ves would be nothing but a means of transfer. The unit of account is still =
BTC.
> > > >
> > > > I can't see any difference and advantage over doing the same with s=
ay Litecoin. All you need is to create a special wallet which offers atomic=
 swaps LTC-BTC and its unit of account displayed to user is going to be BTC=
. All you say will work perfectly with this special LTC wallet. Therefore y=
our idea is as good as any other altcoin. In your case, someone else should=
 indeed be able to create such a wallet in which the unit of account will b=
e the new token, thus emulating the current LTC wallets. So the only differ=
ence in Litecoin is that the special wallet with BTC as unit is going to be=
 created after the native one, while in your case it is vice versa.
> > > > I simply can't see why I'd call this construction of yours a Bitcoi=
n sidechain and any other altcoin not. So I'd call both altcoins.
> > >
> > > Let me try to explain where I am coming from: Whenever I want to onbo=
ard a not-so-techy friend to Bitcoin by sending him $5 worth of BTC, I don'=
t have many good options. Usually we end up using BlueWallet. It works grea=
t. Though it only works so well because it is fully custodial. That is how =
they solve all the tough LN problems like inbound-capacity of new users, wa=
tchtowers and channel backends. Their service is just an Excel table connec=
t to the LN. Unfortunately, that is the best UX we can currently offer to e=
ndusers. To me that's unsatisfying. Is that how we want to enter the emergi=
ng markets and on-board the next Billion users? I like that BlueWallet give=
s me the option to run my own LndHub for my friends. Still, does that scale=
 globally? More importantly, do we want that?
> > > Now let's think about the altcoins argument. We want to serve a billi=
on users. Blockchains do scale well to about a couple Million UTXOs, so we =
require a network of a couple thousand altcoins to serve our users.
> > > We know how to build a nice LN for all of our altcoins with a star-sh=
aped topology around Bitcoin as the central settlement layer. Atomic swaps =
FTW. We can abstract away their native currencies. We display to our users =
only BTC, hide the exchange rates in the TX fees and we're done. That is ac=
tually a scalability solution. So why don't we do that?
> > > The problem here is, that In the long term, the market of PoW blockch=
ains should be a winner-takes-all market, right? So all PoW chains but Bitc=
oin will eventually die because they're wasting lots of value on their ener=
gy. So actually we don't want a couple thousand altcoins wasting resources =
on pointlessly weak PoW chains. We want a single PoW chain which is as stro=
ng as possible.
> > > That's why I'd argue it makes sense to consider a bitcoin-backed PoS =
and build a LN of thousands of nameless altcoins.
> > > Regarding sidechain security: Burning BTC is almost equivalent to bur=
ning energy. You might argue that people won't burn BTC, but it is hard to =
argue against the strong theoretical security properties of proof-of-burn.
> > > Furthermore, even without burning BTC, using only proof-of-stake I ca=
n guarantee doublespending is impossible. There is a very low incentive to =
risk your BTC's time value. You can only halt a sidechain. And you can halt=
 the sidechain only for as long as you maintain the staking majority. Once =
you start an attack, you increase the incentive for others to increase thei=
r stake. Staking happens in bitcoin's blockchain, which you can't halt. Onc=
e the rational stakers regain 51% you've lost a year of time value of your =
BTC. Note that you can easily enforce stakers having to stake per chain. Th=
is guarantees attackers can use their BTC only to attack one chain per year=
.=C2=A0
> > > Thus, the security of such a bitcoin-based PoS is stronger then one m=
ight suspect.
> > > Thanks again,
> > >
> > > -   Robin
> > >
> > > > > Regarding Reason #2:
> > > > > In the "Limitations" section I discuss the cost of halting the ch=
ain:
> > > > > Time value of locked bitcoins might be too cheap to protect the c=
hain. We can introduce an additional cost and let validators burn bitcoins =
for every on-chain vote. This is much more robust because there is an ongoi=
ng cost for halting the system. Proof-of-burn has recently been formally an=
alysed [16]. The economic implications of burning significant amounts of Bi=
tcoin are questionable. A level of security comparable to Bitcoin requires =
the system=E2=80=99s BTC burn rate to be equal to Bitcoin=E2=80=99s infalti=
on rate.
> > > > > Also remember, time value of Bitcoins is indeed a value. Even wit=
hout a proof of burn, I'd consider such sidechains much more secure than th=
ose custodial lightning wallets which become more and more popular to circu=
mvent the usability hurdles of the LN.
> > > >
> > > > Comparison to other models is not relevant to my claim that such co=
nstruction is insecure for small sidechains. And for big sidechains the rea=
son #1 prefers any other altcoin. Even if you introduce proof of burn, the =
final attack cost is small for an attacker in absolute numbers, despite the=
 fact that in the relative numbers the cost is huge.
> > > >
> > > > > Thanks again,
> > > > >
> > > > > -   Robin
> > > > >
> > > > > 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 Message =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 7:06 PM, Joachim Str=C3=B6mbergson jo=
achimstr@protonmail.com wrote:
> > > > >
> > > > > > While I haven't rejected sidechains entirely yet, this particul=
ar proposal seems uninteresting, especially for two reasons.
> > > > > > One =E2=80=93 it introduces a new token for each sidechain and =
suggests atomic swaps to be used for the exchange of the mainchain token wi=
th the sidechain token. Such a model seems nonsensical to me because there =
seems to be excessive number of blockchain projects that can be used simila=
rly just as the sidechain in this proposal. Pick almost any altcoin out the=
re and you can atomic swap it with Bitcoin. The fact that your sidechain is=
 somehow mathematically bound to Bitcoin seems arbitrary because at the end=
 you have a new token and a new issuance model. Therefore this is not exten=
ding Bitcoin economy, which is strictly limited by its convergence to zero =
inflation. This proposal is inflating the supply with a new token, which go=
es against what many people consider as a pillar of Bitcoin's value proposa=
l. I think if you implement this proposal, you are going not to be consider=
ed as a Bitcoin sidechain, but you will be, from certain point of view, ind=
istinguishable from any other altcoin. At the level of my current understan=
ding, the only interesting sidechain model is the [theoretical] one with a =
two way peg with Bitcoin, preserving the issuance policy of Bitcoin.
> > > > > > Two =E2=80=93 the security of the proposed system seems to be v=
ery fragile, unless I have missed something. When I think about sidechains,=
 I expect that it should be possible to create a niche chain which is used =
by few participants while the security of the chain is somehow guaranteed f=
rom its bind to the mainchain. If this was not the case, such a niche sidec=
hain could easily be attacked, even if just stalled/censored for a long per=
iod time, with just a small [absolute] investment from an attacker, althoug=
h this investment might be large if taken relatively to the utility of this=
 niche sidechain. So if we speak concretely about your proposal, you assume=
 honest majority of validators. But in your system the validators come from=
 locking of stake on Bitcoin chain by nodes that are interested in a partic=
ular sidechain. If you put this model on a niche chain where only few parti=
cipants are interested in it, it's trivial for an attacker to be stronger [=
have more Bitcoin to lock] than all legitimate users together. You should o=
nly use honest majority assumption where the scope is global, where it is v=
ery hard and very expensive to obtain majority.
> > > > > > 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 Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90=E2=80=90
> > > > > > On Sunday, January 12, 2020 6:54 PM, Robin Linus via bitcoin-de=
v bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > > I've been working on a sidechain protocol with no trusted thi=
rd party. You can find thewhitepaper here.
> > > > > > > Abstract.Coins is a Bitcoin extension designed for payments a=
t scale.=C2=A0We propose an efficient solution to the double-spending probl=
em using a bitcoin-backed proof-of-stake.=C2=A0 Validators vote on sidechai=
n blocks with one-time signatures, forming a record that cannot be changed =
without destroying their collateral. Every user can become a validator by l=
ocking bitcoins.=C2=A0One-time signatures guarantee that validators loose t=
heir=C2=A0stake=C2=A0for=C2=A0publishing=C2=A0conflicting=C2=A0histories. C=
heckpoints=C2=A0can=C2=A0be=C2=A0additionally secured with a bitcoin-backed=
 proof-of-burn.=C2=A0Assuming a rational majority of validators, the sidech=
ain provides safety and liveness. The sidechain=E2=80=99s footprint within =
bitcoin=E2=80=99s blockchain is minimal.=C2=A0The protocol is a generic con=
sensus mechanism allowing for arbitrary sidechain assets. Spawning multiple=
, independent instances scales horizontally.
> > > > > > > Feedback is highly appreciated!
> > > > > > > Thank you
> > > > > > >
> > > > > > > -   Robin
> > > > > > >
> > > > > > > PS:Here on Github you can find further research on scalabilit=
y and usability.