path: root/03/21b08f0bd409f3ac2d68427671c7bcee82b159

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 79D2DC077D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jan 2020 15:26:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 7598785DF8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jan 2020 15:26:30 +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 MYSMi-66EdlK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jan 2020 15:26:25 +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 fraxinus.osuosl.org (Postfix) with ESMTPS id 5B18B85DD8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jan 2020 15:26:25 +0000 (UTC)
Date: Tue, 14 Jan 2020 15:26:18 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=default; t=1579015582;
 bh=SjJLrr7UyUdnhY4BpI1MwoV1wqfymH8Y5ArjtMXmn1o=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
 Feedback-ID:From;
 b=g4OqR5W4XZXYgAafcV+lBJP++ibD5Ag2lbzynxU+9a7utCtO0D4Fz/f7a0tBfyLc4
 U3cRiA8Jf5ik2DD+xLDskif1C7EvkCaW9F0CcjxZT1N4gfmZ/lah55CvFnE5bGyKsS
 5aP2vc0HkrCf4buhhXuqGorEZiC6GFyhszfqn+gE=
To: =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= <joachimstr@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <FMYpymM9ePfMzdSqBtwf5oRl4bL6XMmDkCrwWMqBW8CK-lz4d0zjpk4oDuU7lWa16wV3Tmtnjd4LTs8Oi8-BIz_ce1rp-jK8ot9Apeo48BA=@protonmail.com>
In-Reply-To: <beLVDOWDR2iV7hnmLpR4bBal2QWxAYqayzw8r9CRc5afhyqZjGIQZQZEerwIIXcmRC9KFigFDFu5_CU4vxoeLFxhNrDGUaZy44_JOs3asmk=@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>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==: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
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: Tue, 14 Jan 2020 15:26:30 -0000

As well I would like to point out that in order to receive funds, *somethin=
g* 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 incom=
ing payment while you are offline.
Instead, it could simply stall until the outgoing HTLC would reach its time=
lock anyway.
Then you can come online and then the peer can send the HTLC to you and you=
 can claim it.
This remains noncustodial as the direct peer cannot steal the funds from yo=
u.
I believe there was some discussion regarding this on lightning-dev in the =
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 th=
at a sidechain may get stalled and you would be unable to receive a payment=
 anyway while you are offline, because there are far fewer nodes per sidech=
ain in order for such mass sidechains to start beating the raw scaling Ligh=
tning brings.

Regards,
ZmnSCPxj

> Hi Robin.
>
> While your motivation seems reasonable, your solution is not. It is not e=
nough that a problem exists. Although the solution must be technically soun=
d for the proposal to be interesting. So I agree it makes sense to consider=
 Bitcoin sidechains, not sure if with PoS consensus or other, but no one ye=
t proposed a viable solution, other than Federation based sidechains. Your =
proposal explored a single specific PoS sidechain, which to me does not sou=
nd interesting. Maybe you can improve it, maybe not.
>
> I also disagree that it is okay if anyone can halt operation of a sidecha=
in with just tiny investment. For me that is critical security flaw of your=
 proposal. By enforcing stakers having to stake per chain you have actually=
 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 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 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 like =
Ethereum vs. ERC20 tokens, because the derivatives are not in competition w=
ith BTC, but depend on it heavily. You support Bitcoin's growth by supporti=
ng such a sidechain.=C2=A0
> > > > Also, they won't work as separate currencies. For endusers you can =
abstract away all underlying complexities such that they have to think only=
 in BTC. Exchanges rates can be hidden in TX fees. The sidechain derivative=
s would be nothing but a means of transfer. The unit of account is still BT=
C.=C2=A0
> > >
> > > I can't see any difference and advantage over doing the same with say=
 Litecoin. All you need is to create a special wallet which offers atomic s=
waps 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 you=
r idea is as good as any other altcoin. In your case, someone else should i=
ndeed be able to create such a wallet in which the unit of account will be =
the new token, thus emulating the current LTC wallets. So the only differen=
ce in Litecoin is that the special wallet with BTC as unit is going to be c=
reated 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 Bitcoin =
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 onboar=
d 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 great.=
 Though it only works so well because it is fully custodial. That is how th=
ey solve all the tough LN problems like inbound-capacity of new users, watc=
htowers and channel backends. Their service is just an Excel table connect =
to the LN. Unfortunately, that is the best UX we can currently offer to end=
users. To me that's unsatisfying. Is that how we want to enter the emerging=
 markets and on-board the next Billion users? I like that BlueWallet gives =
me the option to run my own LndHub for my friends. Still, does that scale g=
lobally? More importantly, do we want that?
> >
> > Now let's think about the altcoins argument. We want to serve a billion=
 users. Blockchains do scale well to about a couple Million UTXOs, so we re=
quire 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-shap=
ed topology around Bitcoin as the central settlement layer. Atomic swaps FT=
W. We can abstract away their native currencies. We display to our users on=
ly BTC, hide the exchange rates in the TX fees and we're done. That is actu=
ally a scalability solution. So why don't we do that?
> > The problem here is, that In the long term, the market of PoW blockchai=
ns should be a winner-takes-all market, right? So all PoW chains but Bitcoi=
n will eventually die because they're wasting lots of value on their energy=
. 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 strong=
 as possible.
> >
> > That's why I'd argue it makes sense to consider a bitcoin-backed PoS an=
d build a LN of thousands of nameless altcoins.
> >
> > Regarding sidechain security: Burning BTC is almost equivalent to burni=
ng energy. You might argue that people won't burn BTC, but it is hard to ar=
gue against the strong theoretical security properties of proof-of-burn.
> >
> > Furthermore, even without burning BTC, using only proof-of-stake I can =
guarantee doublespending is impossible. There is a very low incentive to ri=
sk your BTC's time value. You can only halt a sidechain. And you can halt t=
he sidechain only for as long as you maintain the staking majority. Once yo=
u start an attack, you increase the incentive for others to increase their =
stake. Staking happens in bitcoin's blockchain, which you can't halt. Once =
the rational stakers regain 51% you've lost a year of time value of your BT=
C. Note that you can easily enforce stakers having to stake per chain. This=
 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 mig=
ht suspect.
> >
> > Thanks again,
> > - Robin
> >
> > > > Regarding Reason #2:
> > > > In the "Limitations" section I discuss the cost of halting the chai=
n:
> > > >
> > > > Time value of locked bitcoins might be too cheap to protect the cha=
in. We can introduce an additional cost and let validators burn bitcoins fo=
r every on-chain vote. This is much more robust because there is an ongoing=
 cost for halting the system. Proof-of-burn has recently been formally anal=
ysed [16]. The economic implications of burning significant amounts of Bitc=
oin are questionable. A level of security comparable to Bitcoin requires th=
e system=E2=80=99s BTC burn rate to be equal to Bitcoin=E2=80=99s infaltion=
 rate.
> > > >
> > > > Also remember, time value of Bitcoins is indeed a value. Even witho=
ut a proof of burn, I'd consider such sidechains much more secure than thos=
e custodial lightning wallets which become more and more popular to circumv=
ent the usability hurdles of the LN.
> > >
> > > Comparison to other models is not relevant to my claim that such cons=
truction is insecure for small sidechains. And for big sidechains the reaso=
n #1 prefers any other altcoin. Even if you introduce proof of burn, the fi=
nal attack cost is small for an attacker in absolute numbers, despite the f=
act that in the relative numbers the cost is huge.
> > >
> > > > Thanks again,=C2=A0
> > > > - 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 Ori=
ginal 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 <joa=
chimstr@protonmail.com> wrote:
> > > >
> > > > > While I haven't rejected sidechains entirely yet, this particular=
 proposal seems uninteresting, especially for two reasons.
> > > > >
> > > > > One =E2=80=93 it introduces a new token for each sidechain and su=
ggests atomic swaps to be used for the exchange of the mainchain token with=
 the sidechain token. Such a model seems nonsensical to me because there se=
ems to be excessive number of blockchain projects that can be used similarl=
y just as the sidechain in this proposal. Pick almost any altcoin out there=
 and you can atomic swap it with Bitcoin. The fact that your sidechain is s=
omehow mathematically bound to Bitcoin seems arbitrary because at the end y=
ou have a new token and a new issuance model. Therefore this is not extendi=
ng Bitcoin economy, which is strictly limited by its convergence to zero in=
flation. This proposal is inflating the supply with a new token, which goes=
 against what many people consider as a pillar of Bitcoin's value proposal.=
 I think if you implement this proposal, you are going not to be considered=
 as a Bitcoin sidechain, but you will be, from certain point of view, indis=
tinguishable from any other altcoin. At the level of my current understandi=
ng, the only interesting sidechain model is the [theoretical] one with a tw=
o way peg with Bitcoin, preserving the issuance policy of Bitcoin.
> > > > >
> > > > > Two =E2=80=93 the security of the proposed system seems to be ver=
y 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 fro=
m its bind to the mainchain. If this was not the case, such a niche sidecha=
in could easily be attacked, even if just stalled/censored for a long perio=
d time, with just a small [absolute] investment from an attacker, although =
this investment might be large if taken relatively to the utility of this n=
iche sidechain. So if we speak concretely about your proposal, you assume h=
onest majority of validators. But in your system the validators come from l=
ocking of stake on Bitcoin chain by nodes that are interested in a particul=
ar sidechain. If you put this model on a niche chain where only few partici=
pants are interested in it, it's trivial for an attacker to be stronger [ha=
ve more Bitcoin to lock] than all legitimate users together. You should onl=
y use honest majority assumption where the scope is global, where it is ver=
y 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-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I've been working on a sidechain protocol with no trusted third=
 party. You can find thewhitepaper here.
> > > > > >
> > > > > > Abstract.Coins is a Bitcoin extension designed for payments at =
scale.=C2=A0We propose an efficient solution to the double-spending problem=
 using a bitcoin-backed proof-of-stake.=C2=A0 Validators vote on sidechain =
blocks with one-time signatures, forming a record that cannot be changed wi=
thout destroying their collateral. Every user can become a validator by loc=
king bitcoins.=C2=A0One-time signatures guarantee that validators loose the=
ir=C2=A0stake=C2=A0for=C2=A0publishing=C2=A0conflicting=C2=A0histories. Che=
ckpoints=C2=A0can=C2=A0be=C2=A0additionally secured with a bitcoin-backed p=
roof-of-burn.=C2=A0Assuming a rational majority of validators, the sidechai=
n provides safety and liveness. The sidechain=E2=80=99s footprint within bi=
tcoin=E2=80=99s blockchain is minimal.=C2=A0The protocol is a generic conse=
nsus 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 scalability =
and usability.