From: Robin Linus <robinlinus@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@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 01:43:06 +0000 [thread overview]
Message-ID: <9ojpE1QHVyo_xJXqJFREMWLfYkJDJYIRMHNJ_WUazaWeO02KOqPU6GOaimSv0RwzACi5L4xM8K6p1x5vQOtMGchPSU3-J_EVDLUa807dGmw=@protonmail.com> (raw)
In-Reply-To: <FMYpymM9ePfMzdSqBtwf5oRl4bL6XMmDkCrwWMqBW8CK-lz4d0zjpk4oDuU7lWa16wV3Tmtnjd4LTs8Oi8-BIz_ce1rp-jK8ot9Apeo48BA=@protonmail.com>
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.
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?
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.
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.
Thanks again,
-Robin
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 14, 2020 4:26 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
> As well I would like to point out that in order to receive funds, something 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 incoming payment while you are offline.
> Instead, it could simply stall until the outgoing HTLC would reach its timelock anyway.
> Then you can come online and then the peer can send the HTLC to you and you 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 the past few months.
> However, it does require that the peer know that you are the final recipient (if not, it would be unable to fail the HTLC as quickly as possible), thus a privacy leak.
>
> In any case some node has to be online in order for anyone to receive funds, whether onchain or not: it is simply that a widespread blcokchain is very very likely to have some online node capable of storing the payment until 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 payment anyway while you are offline, because there are far fewer nodes per sidechain in order for such mass sidechains to start beating the raw scaling Lightning 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 sound for the proposal to be interesting. So I agree it makes sense to consider Bitcoin sidechains, not sure if with PoS consensus or other, but no one yet proposed a viable solution, other than Federation based sidechains. Your proposal explored a single specific PoS sidechain, which to me does not sound interesting. Maybe you can improve it, maybe not.
> > I also disagree that it is okay if anyone can halt operation of a sidechain with just tiny investment. For me that is critical security flaw of your proposal. By enforcing stakers having to stake per chain you have actually lowered the cost for the attacker to attack each specific chain.
> > Sent with ProtonMail Secure Email.
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > 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 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.
> > > >
> > > > I can't see any difference and advantage over doing the same with say 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 your 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 be the new token, thus emulating the current LTC wallets. So the only difference 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 Bitcoin 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 onboard 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 great. 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, watchtowers and channel backends. Their service is just an Excel table connect to the LN. Unfortunately, that is the best UX we can currently offer to endusers. To me that's unsatisfying. Is that how we want to enter the emerging markets and on-board the next Billion users? I like that BlueWallet gives 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 billion 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-shaped 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 actually a scalability solution. So why don't we do that?
> > > The problem here is, that In the long term, the market of PoW blockchains should be a winner-takes-all market, right? So all PoW chains but Bitcoin will eventually die because they're wasting lots of value on their energy. 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 strong 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 burning 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 can 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 their stake. Staking happens in bitcoin's blockchain, which you can't halt. Once 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. This guarantees attackers can use their BTC only to attack one chain per year.
> > > Thus, the security of such a bitcoin-based PoS is stronger then one might suspect.
> > > Thanks again,
> > >
> > > - Robin
> > >
> > > > > 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.
> > > >
> > > > Comparison to other models is not relevant to my claim that such construction is insecure for small sidechains. And for big sidechains the reason #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.
> > > > > ‐‐‐‐‐‐‐ 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 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 thewhitepaper here.
> > > > > > > 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.
next prev parent reply other threads:[~2020-01-15 1:43 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 [this message]
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='9ojpE1QHVyo_xJXqJFREMWLfYkJDJYIRMHNJ_WUazaWeO02KOqPU6GOaimSv0RwzACi5L4xM8K6p1x5vQOtMGchPSU3-J_EVDLUa807dGmw=@protonmail.com' \
--to=robinlinus@protonmail$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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