From mboxrd@z Thu Jan 1 00:00:00 1970 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.