From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ZmnSCPxj@protonmail.com> Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0813FC077D for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 15 Jan 2020 05:46:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id E639D203CC for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 15 Jan 2020 05:46:15 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxfMMMt0emlN for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 15 Jan 2020 05:46:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by silver.osuosl.org (Postfix) with ESMTPS id EA0B0203B9 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 15 Jan 2020 05:46:12 +0000 (UTC) Date: Wed, 15 Jan 2020 05:46:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1579067170; bh=sR1448qsM5/EUg0quzJivKbriEmyGuO2m27wobUzmw4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=ftuWuvPZRpHI1W75661KTcwAA0yq7h2zZVsqWFLSFzEfd4M6hyzphpkeLT3MOGdd7 YifjSdR9tULiYAEhLAdZn1P06sGKiyrSwYOqmyAF7wCcIUpDI5Lug3HHR7u64JxaT2 VU8kWqN2k7Y4QXxSGfRv7IE/lvPZtHtlZeByPVIA= To: Robin Linus <robinlinus@protonmail.com> From: ZmnSCPxj <ZmnSCPxj@protonmail.com> Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> Message-ID: <tAwpxfAGBzayt7ftFikSTt5eIvEdzxJ29sDrMvuLQ5RSxnIn8JuND6TSYBymM5UybwG1ieS9y3dAJntz-KsZjzfs1x49CVD4CoZS7QaLkZU=@protonmail.com> In-Reply-To: <9ojpE1QHVyo_xJXqJFREMWLfYkJDJYIRMHNJ_WUazaWeO02KOqPU6GOaimSv0RwzACi5L4xM8K6p1x5vQOtMGchPSU3-J_EVDLUa807dGmw=@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> <9ojpE1QHVyo_xJXqJFREMWLfYkJDJYIRMHNJ_WUazaWeO02KOqPU6GOaimSv0RwzACi5L4xM8K6p1x5vQOtMGchPSU3-J_EVDLUa807dGmw=@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 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 05:46:16 -0000 Good morning Robin, > Good morning everybody! > > Thanks again for your detailed feedback. > > Maybe you're right and my solution is just crap :) So back to the draftin= g table! > > It seems to be a good idea to separate problem definition and solution. H= ere I tried to nail down LN's usability issue: > https://github.com/coins/coins.github.io/blob/master/notes/lightning-netw= ork.md > Would be great to hear your thoughts on that. Do we generally agree that = Bitcoin has to work well on mobiles? Where do your opinions differ? > > If you are open to sidechains in general, we are discussing mostly consen= sus mechanisms. > The consensus mechanism of custodial LN services is some trusted server s= omewhere, 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= banks. > > Yes, Liquid's trusted federation is much better than such custodial servi= ces. Still, how does it scale globally? Lots of trusted federations? > Probably, we all favor a more trust-minimized sidechain consensus mechani= sm. > > Most likely, it is impossible to produce decentralized consensus without = consuming an external resource. > Furthermore, decentralized consensus requires an honest majority. Thus, f= ragmenting the consumption of the available resources over multiple chains = weakens every chain proportionally. Therefore, whatever consensus mechanism= we choose, the number of sidechains should be as small as possible. By imp= lication, sidechains have to be as large as possible. > > The market simply has no capacity to secure thousands of chains, if they = don't have millions of users each. > Consensus resource consumption is a winner takes all market, until a side= chain becomes so full, that a further chain becomes profitable. Secure and = profitable sidechains require strong network effects. Otherwise, there's a = downwards spiral of no users which leads to no stakers and vice versa. Need= less sidechains die off quickly. Again, please refer to the previous Fermi estimate: blockchains have bad sc= aling precisely because every fullnode must know every transaction. With blockchains, anything that is not a fullnode is trusting something, an= d the issue of custodiality is always and has always been an issue of trust= . > > Regarding proof-of-burn: In theory, you could build a pure proof-of-burn = sidechain which is literally as secure as Bitcoin's consensus. If you burn = about 12.5 BTC for every sidechain block, then the sidechain is exactly as = costly to produce as Bitcoins blockchain. So regardless of the practicality= , the theoretical security argument of PoB is very sound, or am I missing s= omething? Locking coins is equivalent to burning them, as you are "burning" the oppor= tunity to use those coins elsewhere, e.g. in a JoinMarket maker or Lightnin= g forwarding node. Proof of locked coins is therefore indistinguishable from proof-of-burn in = this sense, and your original proposal is proof-of-locked-coins. Burning coins is effectively a donation to all HODLers, while locking coins= is effectively a donation to all JoinMarket makers and Lightning forwardin= g nodes (i.e. HODLers too). Something I have been playing with mentally would be a unidirectional peg i= n a sidechain. Burn funds in the mainchain and build a block with equivalent amount in the= coinbase of a sidechain. But I stopped working on sidechains due to the aforementioned lack of scali= ng they produce: sidechains are for features, and federated sidechains are = fine for new features. > > If it is, then can't we build some PoS / PoB construction to secure sidec= hains? > > 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 te= nder. > 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. .... The "balancing their books" **is** the peg. Consider that for example that a sidechain may have 21 million bitcoins ins= tantiated in it, but locked. In order to unlock *part* of that supply, you have to provably lock funds i= n the mainchain. This "moves" coins from mainchain to sidechain, but in reality there are s= till 21 million maincoins and 21 million separate sidecoins. What matters is that there are only 21 million ***user-controllable*** coin= s in total, some in the mainchain and some in the sidechain. That is enough for this to be a peg. Thus, everything the bank does to "balance their books" is in fact a peg to= the central-bank issued currency. > All that is hidden from me as a customer. They know, I just want to facil= itate payments in USD. As a customer I do not care about their underlying f= inancial instruments. That's why I'd assume, that sidechain assets can be u= sed 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. Why would accept a sidecoin with degraded security and accepted by fewer pe= ople if it is not pegged to BTC? That immediately kills any network effects you are targeting. -- In any case, a project I have been playing with (which I am not pursuing in= seriousness and which I will not seriously support, because LN > sidechain= s) is to combine the mainchain-staking with https://lists.linuxfoundation.o= rg/pipermail/bitcoin-dev/2019-January/016611.html Basically, on the mainchain, the sidechain is represented by single UTXO th= at contains all the funds in the sidechain. That UTXO would then have the same SCRIPT as described in the above linked = post. Mainchain coin owners that want to be included in the staker set can put th= eir staked amount into a UTXO. The sidechain stakers then confirm the addition of this staker to the stake= r set by spending the sidechain single UTXO and the entering staker, puttin= g the funds into a new sidechain single UTXO that now includes the entering= staker in the signing set. Sidechain stakers can also redeem their stake back by requesting the staker= set, so that the sidechain single UTXO is consumed and spent into a new si= dechain single UTXO that removes the leaving staker in the signing set, plu= s a second UTXO containing the money that the leaving sidechain staker is r= eclaiming from stake. Withdraws and deposits into the sidechain use a similar mechanism, except t= he depositor does not get its pubkey added to the signer set, but its funds= are instantiated into the sidechain (the stakers do not have their funds i= nstantiated into the sidechain: the mainchain staked funds and the sidechai= n "live" funds are thus separated, even though on the mainchain they are co= mbined within the sidechain single UTXO). Like all federated sidechains this assumes a federation can be formed that = can be trusted to not just spend the entire sidechain single UTXO on other = funds. In particular, if the federation is taken over, it can deny the entry of ne= w stakers that would want to evict them. Thus the security is significantly lower. (proof-of-work allows existing miners to be evicted, at cost, by deploying = more hashpower than the existing miners have: this is central to censorship= -resistance on the main blockchain layer) The stakers that sign on the sidechain single UTXO that appears on the main= chain need not be the same set that determines consensus on the sidechain. In terms of the Liquid blockchain, the signers on the sidechain single UTXO= are the watchmen (who ensure the peg is correct), and need not be the same= set as the blocksigners (who advance the sidechain state by authorizing va= lid blocks). Regards, ZmnSCPxj