path: root/7f/18e0f7438c9930f8cac5c48180a11ad994e7dc

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-----