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: Tue, 14 Jan 2020 02:59:25 +0000 [thread overview]
Message-ID: <MAgdbCHb2isOrbTArpYEo9fEdUNI7qTvO3lzU1V5XrBZOR6u8R0YTRV8f5oCUpUGwWjmaWuYqhlowvPEk5GLnliAbETgA--LLp_pZ1LuMXE=@protonmail.com> (raw)
In-Reply-To: <2NvYkCEanXxFZvWPT3SJ-8whLGsVQYH_QbAHjPqLZIpeCO9E_mL7cCWTg6Qe4Af8gSMMeizbQQh3pZ-QW91xHDQOfZZUFdoacNOjzEEg85Y=@protonmail.com>
Good morning Robin,
> > because all users must process all transactions within the blockchain
>
> Reality shows, that's wrong. Bitcoin's security doesn't require verification to scale quadratically with users. Since the whitepaper, Satoshi was explicit about that phenomena. We can discuss nuances, yet it's overall plausible and empirically it's true: Only a tiny minority of users ever verifies the blockchain, still bitcoin works perfectly well. An honest economic majority is sufficient.
>
> Yes, if you can, run your own node. Let's lower the barriers and let's help others to run their own nodes. Let's keep the blocks small and bitcoin's UTXOs set verifiable with consumer hardware. That's the core of decentralized security.
>
> But let's face it: most people on this planet will never run a bitcoin full node. And it is not required.
>
> Bitcoin-backed PoS-sidechains scale in terms of verification and storage just like any other blockchain. However, security is strictly better because double-spends are impossible. A single honest validating user guarantees that attackers cannot do more harm than halting a sidechain. Thus, endusers won't have to validate all of each others' transactions at all.
>
> For most endusers such sidechains' security is strictly superior to today's LN experience.
>
> Let's face it: The most popular LN apps are fully custodial.
> They have to be custodial because there is no way to make LN usable for regular users on unreliable phones.
>
> Any payment channel which requires you to be always online excludes 99% of the world's population.
> Any payment channel which potentially requires you to be able to pay high on-chain fees excludes most people, too. And on-chain fees keep rising.
>
> Thus, no matter what Channel Factory constructions we build, they will not match most people's requirements. We will keep falling back to custodial solutions.
> Excel tables connected to the LN. The LN is awesome as a settlement layer. In particular for anything like bitcoin banks that have been discussed since the beginning.
> But why 1000 trusted Excel tables if we can have 1000 trustless sidechains?
First:
> A single honest validating user guarantees that attackers cannot do more harm than halting a sidechain.
Is not compatible with:
> 1000 trustless sidechains
You are *tr\*sting* that there exists at least ***one*** ***honest*** user per sidechain.
Thus it is not a trustless solution, but a tr\*sted one.
Replacing 1000 tr\*sted Excel tables with 1000 tr\*sted blockchains is the same class of error as replacing the banking system with centralized large-scale blockchains: you gain the drawbacks of blockchains without gaining its benefits.
The security, integrity, and censorship-resistance of Bitcoin is dependent on there existing some sophisticated actors ("persons") who are willing to take on the risk of running fullnodes and providing hashpower.
This is the Risk-Sharing principle, by which the risk of keeping Bitcoin running is spread out among many persons who are willing to keep Bitcoin alive.
The existence of such actors cannot be assured, but it seems to me that fragmenting the entire community of such limited number of actors would not give good risk-sharing within a sidechain.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-01-14 2:59 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 [this message]
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='MAgdbCHb2isOrbTArpYEo9fEdUNI7qTvO3lzU1V5XrBZOR6u8R0YTRV8f5oCUpUGwWjmaWuYqhlowvPEk5GLnliAbETgA--LLp_pZ1LuMXE=@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