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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id F350CC077D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 02:59:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id DC82C8788B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 02:59:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Q6R+EUETSVEn
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 02:59:35 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by hemlock.osuosl.org (Postfix) with ESMTPS id B835C87852
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jan 2020 02:59:34 +0000 (UTC)
Date: Tue, 14 Jan 2020 02:59:25 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1578970772;
bh=/yz4lazinKP3mWobRHmX+XUOcFaB6aC11jVAABncpXU=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=vB1TfQXh949G5IAUsVW4tEaBLBPvkOLfiMM4zEhiAS2oZsM1FyyyCew8oygEX+7Mw
EAM+hnDjHXPfOp2onsQY2qImadMAqmBQFTp5fmyFN+Wvihd0HhOUzRaBildslYUHj5
KoNRTCwIws2spRVpX0yJuAo+pGZMz3bx56Nuk3uM=
To: Robin Linus <robinlinus@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <MAgdbCHb2isOrbTArpYEo9fEdUNI7qTvO3lzU1V5XrBZOR6u8R0YTRV8f5oCUpUGwWjmaWuYqhlowvPEk5GLnliAbETgA--LLp_pZ1LuMXE=@protonmail.com>
In-Reply-To: <2NvYkCEanXxFZvWPT3SJ-8whLGsVQYH_QbAHjPqLZIpeCO9E_mL7cCWTg6Qe4Af8gSMMeizbQQh3pZ-QW91xHDQOfZZUFdoacNOjzEEg85Y=@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>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 02:59:37 -0000
Good morning Robin,
> > because all users must process all transactions within the blockchain
>
> Reality shows, that's wrong. Bitcoin's security doesn't require verificat=
ion to scale quadratically with users. Since the whitepaper, Satoshi was ex=
plicit about that phenomena. We can discuss nuances, yet it's overall plaus=
ible and empirically it's true: Only a tiny minority of users ever verifies=
the blockchain, still bitcoin works perfectly well. An honest economic maj=
ority is sufficient.
>
> Yes, if you can, run your own node. Let's lower the barriers and let's he=
lp 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 decentrali=
zed security.
>
> But let's face it: most people on this planet will never run a bitcoin fu=
ll 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 becaus=
e 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 r=
egular users on unreliable phones.
>
> Any payment channel which requires you to be always online excludes 99% o=
f 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 no=
t 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 si=
nce the beginning.
> But why 1000 trusted Excel tables if we can have 1000 trustless sidechain=
s?
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 it=
s 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 ru=
nning is spread out among many persons who are willing to keep Bitcoin aliv=
e.
The existence of such actors cannot be assured, but it seems to me that fra=
gmenting the entire community of such limited number of actors would not gi=
ve good risk-sharing within a sidechain.
Regards,
ZmnSCPxj
|
