summaryrefslogtreecommitdiff
path: root/7f/18e0f7438c9930f8cac5c48180a11ad994e7dc
blob: 78cfbd480da096db28764ff85fde84779f12ffda (plain)
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
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 036AE26C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 18:43:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F0924E0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 18:43:52 +0000 (UTC)
Received: from piha.riseup.net (unknown [10.0.1.162])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "*.riseup.net",
	Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
	by mx1.riseup.net (Postfix) with ESMTPS id 8BACCC26D9;
	Thu, 15 Oct 2015 11:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
	t=1444934632; bh=kouBufc8324WsME2FA5T7B0kdzZQ7lwSeNGLztz6zzs=;
	h=Subject:To:References:Cc:From:Date:In-Reply-To:From;
	b=EjbYx4Uh4YL8NDvkNKJbP9j0bBJLsUAgkRQUFq7yJVzPns7e8hFJdMiZ9/wTB4/XD
	Z2b7OwFsikzExemzz499vZh3y2jNonQPLsietd9Re218STHwqmpY2CGoK/zE5jbSrL
	vInWcxvzzoCRuKf9ICj3r8Nliwkf82cOjEtMzDmg=
Received: from [127.0.0.1] (localhost [127.0.0.1])
	(Authenticated sender: odinn.cyberguerrilla)
	with ESMTPSA id 400A1141751
To: Ittay <ittay.eyal@cornell.edu>
References: <CAPkFh0viwmkUvjo4Qj50TNnkA5kG3z-3dLGExjkmDacE4E49Ow@mail.gmail.com>
	<20151014182055.GC23875@mcelrath.org>
	<CAPkFh0uQjTijLdG=eicaotKYvPEcKqNZhqC5BmY45pYcRyhALQ@mail.gmail.com>
	<561ED55F.2000506@riseup.net>
	<E68FE559-87CF-4146-9586-0C4B2CDEBF7A@mattcorallo.com>
	<561F6852.8060001@riseup.net>
	<CABT1wWnH8TeMkwwrjqvgOWYbYtLE-CneDwNpf7Py06_EvhOJRQ@mail.gmail.com>
From: odinn <odinn.cyberguerrilla@riseup.net>
Message-ID: <561FF3DF.6010008@riseup.net>
Date: Thu, 15 Oct 2015 18:43:43 +0000
MIME-Version: 1.0
In-Reply-To: <CABT1wWnH8TeMkwwrjqvgOWYbYtLE-CneDwNpf7Py06_EvhOJRQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD,
	UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: odinn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Bob McElrath <bob@mcelrath.org>
Subject: Re: [bitcoin-dev] Bitcoin-NG whitepaper.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 15 Oct 2015 18:43:54 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello, and thanks for the reply.  I don't think you are missing
anything, I'll continue to observe this thread for further details and
developments on NG generally, security, & privacy.

Ittay:
> Hi Odinn,
> 
> I guess to answer we should separate pure-NG from the hypothetical
> overlay-NG that runs on top of Bitcoin. For pure NG one still has
> to set a transaction bandwidth limit due to bandwidth and storage
> limitations of the individual clients. This rate can be arbitrarily
> high with NG without compromising protocol security.
> 
> With overlay NG you cannot run above Bitcoin's bandwidth because
> all clients must agree on the ledger, so different clients cannot
> run at different rates. You could do two things: 1. Significantly
> reduce observed latency (time to first confirmation). Users get
> better confidence as more miners adopt NG. 2. Increase the
> bandwidth once everyone is on board.
> 
> As for privacy - I don't see why NG would change things. Such
> privacy schemes are only concerned with the transaction DAG. NG
> does not touch this structure. Am I missing something?
> 
> Thanks, Ittay
> 
> 
> On Thu, Oct 15, 2015 at 4:48 AM, odinn
> <odinn.cyberguerrilla@riseup.net> wrote:
> 
> So, there could not be, for example, a user decision to activate
> it? (versus not activate it)?  I'm wondering if something about
> this can be boiled down to allowing the user to make a choice on
> the matter (turn it on and off).  In Bitcoin-NG, the protocol as
> follows (as described in a general overview of it): every 10
> minutes, NG elects a 'leader,' who then vets future transactions as
> soon as they happen. NG approach supposedly can run as fast as the
> network will allow.
> 
> If this is the case, and if NG functions without major hiccup, 
> shouldn't a user (of Core, for example) be able to be given the
> option to choose between:
> 
> (a) being limited by the blocksize and block interval, or (b)
> running out as fast as the network will allow (NG)?
> 
> The other questions I had pertained to privacy.  How would this
> scheme affect users who would be trying to do things like stealth
> or confidential transactions?
> 
> Matt Corallo:
>>>> Huh? No... This is not a Bitcoin Core issue, it is a Bitcoin 
>>>> protocol one and should be discussed here, not on github. I
>>>> really appreciate Ittay and Emin's efforts in this space and
>>>> their willingness to work with the Bitcoin community on it!
>>>> It seems it still needs some tuning, but seems like if the
>>>> pool-mining issues were resolved it could make block relay
>>>> times irrelevant, at least.
>>>> 
>>>> Matt
>>>> 
>>>> On October 14, 2015 3:21:19 PM PDT, odinn via bitcoin-dev 
>>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: This
>>>> (Bitcoin-NG in concept) could be done as a (issue and pull
>>>> request process) to Bitcoin Core itself, amirite?  It seems
>>>> like it would provide an interesting issue to open and have
>>>> healthy discussion on both mailing list and github, adding
>>>> the caveat that it would be at the user's option.  Thus if
>>>> something like Bitcoin-NG did come to be it would be
>>>> something more like a feature that the user could activate /
>>>> deactivate from within Core.  I assume it would be default
>>>> off, but with the option to utilize.  Code would thus be 
>>>> available to others as well.  I am not saying yea or nay on
>>>> it, just that it seems like this could be done.
>>>> 
>>>> Some notes:
>>>> 
>>>> Once a node generates a key block it becomes the leader.  As
>>>> a leader, the node is allowed to generate  microblocks  at  a
>>>> set rate smaller  than  a  prede >ned  maximum.  A
>>>> microblock in Bitcoin-NG contains  ledger  entries  and  a
>>>> header.   The  header contains the  reference  to the
>>>> previous  block,  the  current GMT  time,  a cryptographic
>>>> hash  of  its  ledger  entries,  and a cryptographic
>>>> signature  of  the  header.   The  signature  uses the
>>>> private  key that  matches  the public key in the latest key 
>>>> block in the chain. For a microblock to be valid, all its
>>>> entries must be valid according to the specification of the
>>>> state machine, and the signature has to be valid.  However,
>>>> the microblocks, it is said, don't affect the weight of the
>>>> chain, because they do not contain proof of work.  It is
>>>> assumed by the authors of this model that this situation is
>>>> critical for maintaining incentives here.
>>>> 
>>>> The questions that then begin to emerge to me are how is
>>>> this information managed and protected?  The headers, thus
>>>> containing reference(s) to previous block(s), current GMT
>>>> time(s), cryptographic hash(es) of ledger entries, and
>>>> cryptographic signature(s) of the headers, so forth, and
>>>> other information.  Can the Bitcoin-NG scheme be designed or
>>>> implemented in a manner which supports Stealth sends,
>>>> Confidential Transactions, or similar privacy measures?  Or
>>>> is this something which cannot be answered at this time?
>>>> 
>>>> Emin Gün Sirer via bitcoin-dev:
>>>>>>>> So it seems to me that all I need to do is figure out
>>>>>>>> who the current
>>>>>>> leader is,
>>>>>>>> and DDoS him off the network to shut Bitcoin-NG
>>>>>>>> down.
>>>>>>> 
>>>>>>> Good point. If NG is layered on top of Bitcoin, we'd
>>>>>>> retain all of Bitcoin as is. This would confer all the
>>>>>>> benefits of Bitcoin's retrospective blocks, as well as
>>>>>>> add the ability to mint microblocks with low latency in
>>>>>>> between. And despite the phrase "the leader," the
>>>>>>> actual leader in NG is a key, not a specific node. That
>>>>>>> makes it possible to deter DDoS attacks by dynamically
>>>>>>> migrating where in the network the leader is operating
>>>>>>> in response to an attack. Finally, DDoS attacks against
>>>>>>> miners are already possible, but they seem rare, and I
>>>>>>> suspect it's at least partly because of the success of
>>>>>>> Matt Corallo's high speed bitcoin relay network.
>>>>>>> Similar defenses can apply here.
>>>>>>> 
>>>>>>> - egs
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath 
>>>>>>> <bob@mcelrath.org> wrote:
>>>>>>> 
>>>>>>>> So it seems to me that all I need to do is figure out
>>>>>>>> who the current leader is, and DDoS him off the
>>>>>>>> network to shut Bitcoin-NG down.
>>>>>>>> 
>>>>>>>> This is a significant advantage to bitcoin's
>>>>>>>> ex-post-facto blocks: no one knows where the next one
>>>>>>>> will come from. The only way to shut the network down
>>>>>>>> is to shut all nodes down.
>>>>>>>> 
>>>>>>>> Emin Gün Sirer via bitcoin-dev 
>>>>>>>> [bitcoin-dev@lists.linuxfoundation.org] wrote:
>>>>>>>>> Hi everyone,
>>>>>>>>> 
>>>>>>>>> We just released the whitepaper describing
>>>>>>>>> Bitcoin-NG, a new technique
>>>>>>>> for
>>>>>>>>> addressing some of the scalability challenges faced
>>>>>>>>> by Bitcoin.
>>>>>>>> Surprisingly,
>>>>>>>>> Bitcoin-NG can simultaneously increase throughput
>>>>>>>>> while reducing
>>>>>>>> latency, and
>>>>>>>>> do so without impacting Bitcoin's open architecture
>>>>>>>>> or changing its trust model. This post illustrates
>>>>>>>>> the core technique: 
>>>>>>>>> http://hackingdistributed.com/2015/10/14/bitcoin-ng/
>>>>>>>>>
>>>>>>>>> 
while the whitepaper has all the nitty gritty details:
>>>>>>>>> http://arxiv.org/abs/1510.02037
>>>>>>>>> 
>>>>>>>>> Fitting NG on top of the current Bitcoin blockchain
>>>>>>>>> is future work that
>>>>>>>> we
>>>>>>>>> think is quite possible. NG is compatible with
>>>>>>>>> both Bitcoin as is, as
>>>>>>>> well as
>>>>>>>>> Blockstream-like sidechains, and we currently are
>>>>>>>>> not planning to compete commercially with either
>>>>>>>>> technology -- we see NG as being complementary
>>>>>>>> to both
>>>>>>>>> efforts. This is pure science, published and shared
>>>>>>>>> with the community to advance the state of
>>>>>>>>> blockchains and to help them reach throughputs and
>>>>>>>>> latencies required of cutting edge fintech
>>>>>>>>> applications. Perhaps it can
>>>>>>>> be
>>>>>>>>> adopted, or perhaps it can provide the spark of 
>>>>>>>>> inspiration for someone
>>>>>>>> else to
>>>>>>>>> come up with even better solutions.
>>>>>>>>> 
>>>>>>>>> We would be delighted to hear your feedback. -
>>>>>>>>> Ittay Eyal and E. Gün Sirer.
>>>>>>>>> 
>>>>>>>>> !DSPAM:561e98cd301391127216946!
>>>>>>>> 
>>>>>>>>> _______________________________________________ 
>>>>>>>>> bitcoin-dev mailing list 
>>>>>>>>> bitcoin-dev@lists.linuxfoundation.org 
>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>
>>>>>>>>> 
!DSPAM:561e98cd301391127216946!
>>>>>>>> 
>>>>>>>> -- Cheers, Bob McElrath
>>>>>>>> 
>>>>>>>> "For every complex problem, there is a solution that
>>>>>>>> is simple, neat, and wrong." -- H. L. Mencken
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev@lists.linuxfoundation.org 
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>
>>>>
>>>>>>>
>>>>>
>>>>>>> 
_______________________________________________ bitcoin-dev
>>>>> mailing list bitcoin-dev@lists.linuxfoundation.org 
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>
>>>>> 
>> 
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWH/PfAAoJEGxwq/inSG8COLkH/3k/ZlUT2yWNYYmlN8SeU9HW
OqGW2akcHI1ObkUxW6Ljy9JCX2z34Py5c7BnpvBkiDRtAGC7bFpH1nHL5prCCxKS
Q2tjZIuu5stWkyz55fOKZ64SVASitOK7+eGhfmN+L04L+bc9BJU/ifQlU+eTH+35
cftjEFHuDClhy+P7zLPklBr62SZezPnr2kHxyV4pyGY132nKsYuB4gHAU6eI+ZeY
dFBliXXbHrQMGWH414pXz3WzpA20CNUYWpV4iJydJmU9EEM4UOaQ7YjIXBubbu6z
hDa0PYXiwvuM4VAnL7z29Q2FHbFMKmVPH01NffI6uhvpGMVZQ2cqwvhXhOS3aL8=
=4AiZ
-----END PGP SIGNATURE-----