From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Robin Linus <robinlinus@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol
Date: Wed, 15 Jan 2020 05:46:04 +0000 [thread overview]
Message-ID: <tAwpxfAGBzayt7ftFikSTt5eIvEdzxJ29sDrMvuLQ5RSxnIn8JuND6TSYBymM5UybwG1ieS9y3dAJntz-KsZjzfs1x49CVD4CoZS7QaLkZU=@protonmail.com> (raw)
In-Reply-To: <9ojpE1QHVyo_xJXqJFREMWLfYkJDJYIRMHNJ_WUazaWeO02KOqPU6GOaimSv0RwzACi5L4xM8K6p1x5vQOtMGchPSU3-J_EVDLUa807dGmw=@protonmail.com>
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 drafting table!
>
> It seems to be a good idea to separate problem definition and solution. Here I tried to nail down LN's usability issue:
> https://github.com/coins/coins.github.io/blob/master/notes/lightning-network.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 consensus mechanisms.
> The consensus mechanism of custodial LN services is some trusted server somewhere, 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 services. 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 consuming an external resource.
> Furthermore, decentralized consensus requires an honest majority. Thus, fragmenting 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 implication, 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 sidechain 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. Needless sidechains die off quickly.
Again, please refer to the previous Fermi estimate: blockchains have bad scaling precisely because every fullnode must know every transaction.
With blockchains, anything that is not a fullnode is trusting something, and 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 something?
Locking coins is equivalent to burning them, as you are "burning" the opportunity to use those coins elsewhere, e.g. in a JoinMarket maker or Lightning 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 forwarding nodes (i.e. HODLers too).
Something I have been playing with mentally would be a unidirectional peg in 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 scaling 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 sidechains?
>
> 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 tender.
> 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 instantiated in it, but locked.
In order to unlock *part* of that supply, you have to provably lock funds in the mainchain.
This "moves" coins from mainchain to sidechain, but in reality there are still 21 million maincoins and 21 million separate sidecoins.
What matters is that there are only 21 million ***user-controllable*** coins 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 facilitate payments in USD. As a customer I do not care about their underlying financial instruments. That's why I'd assume, that sidechain assets can be used 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 people 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 > sidechains) is to combine the mainchain-staking with https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-January/016611.html
Basically, on the mainchain, the sidechain is represented by single UTXO that 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 their staked amount into a UTXO.
The sidechain stakers then confirm the addition of this staker to the staker set by spending the sidechain single UTXO and the entering staker, putting 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 sidechain single UTXO that removes the leaving staker in the signing set, plus a second UTXO containing the money that the leaving sidechain staker is reclaiming from stake.
Withdraws and deposits into the sidechain use a similar mechanism, except the 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 instantiated into the sidechain: the mainchain staked funds and the sidechain "live" funds are thus separated, even though on the mainchain they are combined 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 new 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 mainchain 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 valid blocks).
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-01-15 5:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-12 18:54 Robin Linus
2020-01-13 0:21 ` ZmnSCPxj
2020-01-13 2:02 ` Robin Linus
2020-01-13 2:33 ` ZmnSCPxj
2020-01-13 17:34 ` Joachim Strömbergson
2020-01-13 22:05 ` Jeremy
2020-01-16 1:21 ` Angel Leon
2020-01-13 18:06 ` Joachim Strömbergson
2020-01-13 19:47 ` Robin Linus
2020-01-13 20:49 ` Joachim Strömbergson
2020-01-13 22:22 ` Robin Linus
2020-01-14 0:53 ` ZmnSCPxj
2020-01-14 2:19 ` Robin Linus
2020-01-14 2:59 ` ZmnSCPxj
2020-01-14 4:12 ` Robin Linus
2020-01-14 15:06 ` Joachim Strömbergson
2020-01-14 15:26 ` ZmnSCPxj
2020-01-15 1:43 ` Robin Linus
2020-01-15 5:46 ` ZmnSCPxj [this message]
2020-01-17 4:17 ` Robin Linus
2020-01-17 13:54 ` ZmnSCPxj
2020-01-18 8:21 ` Robin Linus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='tAwpxfAGBzayt7ftFikSTt5eIvEdzxJ29sDrMvuLQ5RSxnIn8JuND6TSYBymM5UybwG1ieS9y3dAJntz-KsZjzfs1x49CVD4CoZS7QaLkZU=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=robinlinus@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox