From: Robin Linus <robinlinus@protonmail•com>
To: "Joachim Strömbergson" <joachimstr@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Coins: A trustless sidechain protocol
Date: Mon, 13 Jan 2020 19:47:23 +0000 [thread overview]
Message-ID: <0RSAH-PjblJV6Q7TGosFHAEdc9QGauCQ_knCzMwcoGdW4Qt49ts-egDkIwM-X_f0RjsPMquwdnmB6spunH379ICEAJQgUH7R1SE8CuZs7pI=@protonmail.com> (raw)
In-Reply-To: <ILtIOT_2wq-ld0mk5kPev5mw8RQD6pgzSF_EPuY1PE-mdsy8eJqsCaSU-zIyNZw-4W4p5JtLJs5d451PnHvQly-3V1q225bKmdanMZVOmGE=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 5634 bytes --]
Hi Joachim,
Thank you for your detailed feedback!
Regarding Reason #1:
This proposal is less like Bitcoin vs. Altcoins and much more like Ethereum vs. ERC20 tokens, because the derivatives are not in competition with BTC, but depend on it heavily. You support Bitcoin's growth by supporting such a sidechain.
Also, they won't work as separate currencies. For endusers you can abstract away all underlying complexities such that they have to think only in BTC. Exchanges rates can be hidden in TX fees. The sidechain derivatives would be nothing but a means of transfer. The unit of account is still BTC.
Regarding Reason #2:
In the "Limitations" section I discuss the cost of halting the chain:
Time value of locked bitcoins might be too cheap to protect the chain. 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 ongoing cost for halting the system. Proof-of-burn has recently been formally analysed [16]. The economic implications of burning significant amounts of Bitcoin are questionable. A level of security comparable to Bitcoin requires the system’s BTC burn rate to be equal to Bitcoin’s infaltion rate.
Also remember, time value of Bitcoins is indeed a value. Even without a proof of burn, I'd consider such sidechains much more secure than those custodial lightning wallets which become more and more popular to circumvent the usability hurdles of the LN.
Thanks again,
- Robin
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 13, 2020 7:06 PM, Joachim Strömbergson <joachimstr@protonmail•com> wrote:
> While I haven't rejected sidechains entirely yet, this particular proposal seems uninteresting, especially for two reasons.
>
> One – it introduces a new token for each sidechain and suggests atomic swaps to be used for the exchange of the mainchain token with the sidechain token. Such a model seems nonsensical to me because there seems to be excessive number of blockchain projects that can be used similarly just as the sidechain in this proposal. Pick almost any altcoin out there 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 extending Bitcoin economy, which is strictly limited by its convergence to zero inflation. This proposal is inflating the supply with a new token, which goes against what many people consider as a pillar of Bitcoin's value proposal. I think if you implement this proposal, you are going not to be considered as a Bitcoin sidechain, but you will be, from certain point of view, indistinguishable from any other altcoin. At the level of my current understanding, the only interesting sidechain model is the [theoretical] one with a two way peg with Bitcoin, preserving the issuance policy of Bitcoin.
>
> Two – the security of the proposed system seems to be very 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 from its bind to the mainchain. If this was not the case, such a niche sidechain could easily be attacked, even if just stalled/censored for a long period time, with just a small [absolute] investment from an attacker, although 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 particular sidechain. If you put this model on a niche chain where only few participants 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 only use honest majority assumption where the scope is global, where it is very hard and very expensive to obtain majority.
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Sunday, January 12, 2020 6:54 PM, Robin Linus via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> I've been working on a sidechain protocol with no trusted third party. You can find the [whitepaper here](http://coins.github.io/coins.pdf).
>>
>> Abstract. Coins is a Bitcoin extension designed for payments at scale. We propose an efficient solution to the double-spending problem using a bitcoin-backed proof-of-stake. Validators vote on sidechain blocks with one-time signatures, forming a record that cannot be changed without destroying their collateral. Every user can become a validator by locking bitcoins. One-time signatures guarantee that validators loose their stake for publishing conflicting histories. Checkpoints can be additionally secured with a bitcoin-backed proof-of-burn. Assuming a rational majority of validators, the sidechain provides safety and liveness. The sidechain’s footprint within bitcoin’s blockchain is minimal. The protocol is a generic consensus 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 scalability and usability](https://github.com/coins/coins.github.io).
[-- Attachment #2: Type: text/html, Size: 11146 bytes --]
next prev parent reply other threads:[~2020-01-13 19:47 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 [this message]
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
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='0RSAH-PjblJV6Q7TGosFHAEdc9QGauCQ_knCzMwcoGdW4Qt49ts-egDkIwM-X_f0RjsPMquwdnmB6spunH379ICEAJQgUH7R1SE8CuZs7pI=@protonmail.com' \
--to=robinlinus@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=joachimstr@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