path: root/ea/58062259e1567ba4d3fe49b71f59b3fb6be7a2

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