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
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <akaramaoun@gmail.com>) id 1Z4YgL-0002KQ-2y
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 18:00:25 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.182 as permitted sender)
client-ip=209.85.213.182; envelope-from=akaramaoun@gmail.com;
helo=mail-ig0-f182.google.com;
Received: from mail-ig0-f182.google.com ([209.85.213.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z4YgJ-0004bb-9C
for bitcoin-development@lists.sourceforge.net;
Mon, 15 Jun 2015 18:00:25 +0000
Received: by igblz2 with SMTP id lz2so56301176igb.1
for <bitcoin-development@lists.sourceforge.net>;
Mon, 15 Jun 2015 11:00:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.132.33 with SMTP id or1mr22730574igb.31.1434391217984;
Mon, 15 Jun 2015 11:00:17 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.64.20.229 with HTTP; Mon, 15 Jun 2015 11:00:17 -0700 (PDT)
In-Reply-To: <CANEZrP1D0AN_iRobD2RYXHCCWhU7Vk6yZ35+ytsQ0zonSCG_HQ@mail.gmail.com>
References: <CAL8tG==LG=xC_DzOaghbGGKab4=UVpGLQV7781pU4wg+WnFdMg@mail.gmail.com>
<CAPg+sBjqQ66f1Rmhi9HOBYP5BDjBHvTNPpUN-y3o-KX8dXBMhg@mail.gmail.com>
<557D2571.601@gmail.com>
<CAL8tG=kEv9AfQM+1Rv+tqBujFEjCp+BsjQ-1s7eJC-usogFFqw@mail.gmail.com>
<CAPg+sBjrSed4r+8-d2RGBVhbzaXxX+o=qqw2u-2jpF2RUqmEmA@mail.gmail.com>
<CANEZrP1D0AN_iRobD2RYXHCCWhU7Vk6yZ35+ytsQ0zonSCG_HQ@mail.gmail.com>
Date: Mon, 15 Jun 2015 18:00:17 +0000
X-Google-Sender-Auth: _0oag2jWAH5voaBhzh94Hk7ssWA
Message-ID: <CAL8tG=k90nzt9w99QjSx5R=+LeBxkfVvcEvcNAyVkJHkaQZAgg@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7b1636e10470d40518923be6
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(akaramaoun[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z4YgJ-0004bb-9C
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Scaling Bitcoin with Subchains
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 18:00:25 -0000
--047d7b1636e10470d40518923be6
Content-Type: text/plain; charset=UTF-8
Pieter: I kind of see your point (but I think you're missing some key
points). You mean just download all the headers and then just verify the
transactions you filter out by using their corresponding merkle trees,
right? But still, I don't think that would scale as well as with the tree
structure I propose. Because, firstly, you don't really need the headers of
the sibling chains. You just need the headers of the parent chains since
the parent verifies all the siblings. All you really need in a typical
(non-mining) situation is the headers or full blocks in one path going down
the tree starting from the root chain. So that means O(log n) needs to be
stored (headers or blocks) (n the number of transaction on the network).
With big blocks, you still need O(n) headers. I know headers are small, but
still they take up space and verification time. Also, since you are storing
the full blocks on the chains you want, you are validating the headers of
those blocks and you are sure that you are seeing all transactions on those
blocks. And if certain addresses must stay on those blocks, you will know
that you are catching all of the transactions corresponding to those
blocks. If you just filter out based on addresses or other criteria, you
can be denied some of those transactions by full nodes, and you may not
know about it. Say for example, your government representative publishes on
of his public addresses that is used for paying for expenses. Then with my
system, you can be sure to catch every transaction being spent from that
address (or UTXO or whatever you want to call it). If you just filter on
any transaction that includes that address, you may not catch all of those
transactions. Same with incoming funds.
There are also advantages for mining decentralization as I have explained
in my previous posts. So still not sure you are right here...
Thanks
On Mon, Jun 15, 2015 at 5:18 PM, Mike Hearn <mike@plan99.net> wrote:
> It's simple: either you care about validation, and you must validate
>> everything, or you don't, and you don't validate anything.
>>
> Pedantically: you could validate a random subset of all scripts, to give
> yourself probabilistic verification rather than full vs SPV. If enough
> people do it with a large enough subset the probability of a problem being
> detected goes up a lot. You still pay the cost of the database updates.
>
> But your main point is of course completely right, that side chains are
> not a way to scale up.
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
--047d7b1636e10470d40518923be6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Pieter: I kind of see your point (but I think you're m=
issing some key points). You mean just download all the headers and then ju=
st verify the transactions you filter out by using their corresponding merk=
le trees, right? But still, I don't think that would scale as well as w=
ith the tree structure I propose. Because, firstly, you don't really ne=
ed the headers of the sibling chains. You just need the headers of the pare=
nt chains since the parent verifies all the siblings. All you really need i=
n a typical (non-mining) situation is the headers or full blocks in one pat=
h going down the tree starting from the root chain. So that means O(log n) =
needs to be stored (headers or blocks) (n the number of transaction on the =
network). With big blocks, you still need O(n) headers. I know headers are =
small, but still they take up space and verification time. Also, since you =
are storing the full blocks on the chains you want, you are validating the =
headers of those blocks and you are sure that you are seeing all transactio=
ns on those blocks. And if certain addresses must stay on those blocks, you=
will know that you are catching all of the transactions corresponding to t=
hose blocks. If you just filter out based on addresses or other criteria, y=
ou can be denied some of those transactions by full nodes, and you may not =
know about it. Say for example, your government representative publishes on=
of his public addresses that is used for paying for expenses. Then with my=
system, you can be sure to catch every transaction being spent from that a=
ddress (or UTXO or whatever you want to call it). If you just filter on any=
transaction that includes that address, you may not catch all of those tra=
nsactions. Same with incoming funds.<br><br>There are also advantages for m=
ining decentralization as I have explained in my previous posts. So still n=
ot sure you are right here...<br><br>Thanks<br></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Mon, Jun 15, 2015 at 5:18 PM, Mike H=
earn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_bl=
ank">mike@plan99.net</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><s=
pan class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">It's simpl=
e: either you care about validation, and you must validate everything, or y=
ou don't, and you don't validate anything.</p></blockquote></span><=
div>Pedantically: you could validate a random subset of all scripts, to giv=
e yourself probabilistic verification rather than full vs SPV. If enough pe=
ople do it with a large enough subset the probability of a problem being de=
tected goes up a lot. You still pay the cost of the database updates.</div>=
<div><br></div><div>But your main point is of course completely right, that=
side chains are not a way to scale up.=C2=A0<br></div></div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</div>
</div>
--047d7b1636e10470d40518923be6--
|
