1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
Return-Path: <robinlinus@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3F43DC077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 04:13:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 268D0836A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 04:13:05 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id CflZS4kXUPlz
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 04:13:03 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by whitealder.osuosl.org (Postfix) with ESMTPS id C0671810FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 04:13:02 +0000 (UTC)
Date: Tue, 14 Jan 2020 04:12:56 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1578975180;
bh=D2rno52jwhl0d43ql5itmpeXwOfu1+Mrl8MdSTOQuio=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=QJlQBSoG6mv9yz4G6frkF+KT4b7eUZv0P64w3obm5lUqlLvzNCsWG9wLGFSHtsPgc
b5slkycUyQhzE/05B6+uKES4W/EIazcTlVc8XKnaKsNfA4FtqkYQjcN3IHP1dqgE+Y
DuG7wXUUj4JNwG9XsP3e4ks52okDwoUcaYVsSk0U=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: Robin Linus <robinlinus@protonmail.com>
Reply-To: Robin Linus <robinlinus@protonmail.com>
Message-ID: <9hNzMroHNW8QOHQ9LekmLwudZnfcAz6xloMM3NRKrT8c52uI6-vztXxHQqyOkxsK2kwNmn61EvhBabZIpsnHW7QNGV1mRJtZ2Zx-UFSfx68=@protonmail.com>
In-Reply-To: <MAgdbCHb2isOrbTArpYEo9fEdUNI7qTvO3lzU1V5XrBZOR6u8R0YTRV8f5oCUpUGwWjmaWuYqhlowvPEk5GLnliAbETgA--LLp_pZ1LuMXE=@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>
<-XqpIGL2s4yhkiWLsuqhvfpQKm1iRdTZHoTy83d_rKW9bY0Qhz5WHxcET5JSzEMxQUXiq5e-VmDqgp2zZ8locphCSjnztSB_yNV_esq111s=@protonmail.com>
<2NvYkCEanXxFZvWPT3SJ-8whLGsVQYH_QbAHjPqLZIpeCO9E_mL7cCWTg6Qe4Af8gSMMeizbQQh3pZ-QW91xHDQOfZZUFdoacNOjzEEg85Y=@protonmail.com>
<MAgdbCHb2isOrbTArpYEo9fEdUNI7qTvO3lzU1V5XrBZOR6u8R0YTRV8f5oCUpUGwWjmaWuYqhlowvPEk5GLnliAbETgA--LLp_pZ1LuMXE=@protonmail.com>
Feedback-ID: 6FfHo99INKExF0tkDkemTyDa-LNBAaNSuYGo9F4rOzppmymRaL_liHzoQTtSnq1Ib2NLN4047Io_xKQzk5eD1w==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 14 Jan 2020 06:05:25 +0000
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: Tue, 14 Jan 2020 04:13:05 -0000
Good morning ZmnSCPxj,
> > > because all users must process all transactions within the blockchain
> >
> > Reality shows, that's wrong. Bitcoin's security doesn't require verific=
ation to scale quadratically with users. Since the whitepaper, Satoshi was =
explicit about that phenomena. We can discuss nuances, yet it's overall pla=
usible and empirically it's true: Only a tiny minority of users ever verifi=
es the blockchain, still bitcoin works perfectly well. An honest economic m=
ajority 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 decentra=
lized 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 storag=
e just like any other blockchain. However, security is strictly better beca=
use double-spends are impossible. A single honest validating user guarantee=
s that attackers cannot do more harm than halting a sidechain. Thus, enduse=
rs won't have to validate all of each others' transactions at all.
> > For most endusers such sidechains' security is strictly superior to tod=
ay'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 hi=
gh 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 custodia=
l solutions.
> > Excel tables connected to the LN. The LN is awesome as a settlement lay=
er. 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 sidecha=
ins?
>
> First:
>
> > A single honest validating user guarantees that attackers cannot do mor=
e 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 sidechai=
n.
> Thus it is not a trustless solution, but a tr\*sted one.
> Replacing 1000 tr\*sted Excel tables with 1000 tr\*sted blockchains is th=
e same class of error as replacing the banking system with centralized larg=
e-scale blockchains: you gain the drawbacks of blockchains without gaining =
its benefits.
Agreed. Still, let's discuss a solution that meets the requirements of bill=
ions of average users with unreliable mobile devices.
Endusers payment experience should be insanely simple.
The LN currently offers regular users mostly custodial services. Is there a=
foreseeable roadmap to meet endusers' simplicity requirements with non-cus=
todial constructions?
Bitcoin-backed PoS sidechains are strictly superior to custodial hubs. They=
provide all hub features such as being able to pay merchants in BTC, plus =
many clear advantages such as better security including public auditability=
and decentralized data storage. And they do not require any consensus chan=
ges.
> The security, integrity, and censorship-resistance of Bitcoin is dependen=
t on there existing some sophisticated actors ("persons") who are willing t=
o 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 al=
ive.
> The existence of such actors cannot be assured, but it seems to me that f=
ragmenting the entire community of such limited number of actors would not =
give good risk-sharing within a sidechain.
Indeed, a highly fragmented market would be inefficient and insecure. Howev=
er, I'd assume a free market of sidechains is intelligent enough to use its=
resources efficiently.
Thanks again for your detailed feedback,
-Robin
|
