diff options
| author | Robin Linus <robinlinus@protonmail.com> | 2020-01-15 01:43:06 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-01-15 01:43:21 +0000 |
| commit | 3f6b0dfe2d707d91b3c695ce82f8b568a938613c (patch) | |
| tree | b188ec0372206392c65d2753bc7bd5d7076791b1 | |
| parent | 75d529eada35371adb4e53911183d7a3615e2d8b (diff) | |
| download | pi-bitcoindev-3f6b0dfe2d707d91b3c695ce82f8b568a938613c.tar.gz pi-bitcoindev-3f6b0dfe2d707d91b3c695ce82f8b568a938613c.zip | |
Re: [bitcoin-dev] Coins: A trustless sidechain protocol
| -rw-r--r-- | 90/24b014f856d58b664207a1ffbb7ccdffdf593a | 369 |
1 files changed, 369 insertions, 0 deletions
diff --git a/90/24b014f856d58b664207a1ffbb7ccdffdf593a b/90/24b014f856d58b664207a1ffbb7ccdffdf593a new file mode 100644 index 000000000..a34989e64 --- /dev/null +++ b/90/24b014f856d58b664207a1ffbb7ccdffdf593a @@ -0,0 +1,369 @@ +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. + + + |