Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 036AE26C for ; 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 ; 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 References: <20151014182055.GC23875@mcelrath.org> <561ED55F.2000506@riseup.net> <561F6852.8060001@riseup.net> From: odinn Message-ID: <561FF3DF.6010008@riseup.net> Date: Thu, 15 Oct 2015 18:43:43 +0000 MIME-Version: 1.0 In-Reply-To: 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 , Bob McElrath 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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 >>>> 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 >>>>>>> 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-----