diff options
| author | odinn <odinn.cyberguerrilla@riseup.net> | 2015-10-15 08:48:18 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-15 08:48:27 +0000 |
| commit | 7cd8303a0a21978369eaaad04551cc18b82f7d53 (patch) | |
| tree | c6ea71ff3834e96c45642ce109cd9e3b32910d56 | |
| parent | b8b03e39d40c835e978b764f1ce5eb79a9c45546 (diff) | |
| download | pi-bitcoindev-7cd8303a0a21978369eaaad04551cc18b82f7d53.tar.gz pi-bitcoindev-7cd8303a0a21978369eaaad04551cc18b82f7d53.zip | |
Re: [bitcoin-dev] Bitcoin-NG whitepaper.
| -rw-r--r-- | 17/2929910fe3ad04ee4c84e37f448ef79b2b02c2 | 265 |
1 files changed, 265 insertions, 0 deletions
diff --git a/17/2929910fe3ad04ee4c84e37f448ef79b2b02c2 b/17/2929910fe3ad04ee4c84e37f448ef79b2b02c2 new file mode 100644 index 000000000..56b10ba81 --- /dev/null +++ b/17/2929910fe3ad04ee4c84e37f448ef79b2b02c2 @@ -0,0 +1,265 @@ +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 86C759B + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 08:48:27 +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 C71E131 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 15 Oct 2015 08:48:23 +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 78CB4C2619; + Thu, 15 Oct 2015 01:48:23 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; + t=1444898903; bh=p/X4VfImcwxOm82j9rGhKKKcMxCE5NFDxkVgxkLgI/E=; + h=Subject:To:References:Cc:From:Date:In-Reply-To:From; + b=NuSF7UnL1wWO7QJi0NSw0UAvk+rwroyAhNqrVfcOmJGen7kz54O53uJwdGXWzQqBH + dt6K1IBWFDaRiLjp8D2PxhUT9wEk9p/TnQak+ziFBpIHUWApunL0qvehnjfj/8Tmym + o8zHsRtiIrmr3Hctr9qwy+JZyVAjHXn4Ey7kdxSs= +Received: from [127.0.0.1] (localhost [127.0.0.1]) + (Authenticated sender: odinn.cyberguerrilla) + with ESMTPSA id ACEF1141357 +To: Matt Corallo <lf-lists@mattcorallo.com>, + odinn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>, + =?UTF-8?Q?Emin_G=c3=bcn_Sirer?= <el33th4x0r@gmail.com>, + Bob McElrath <bob@mcelrath.org> +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> +From: odinn <odinn.cyberguerrilla@riseup.net> +X-Enigmail-Draft-Status: N1110 +Message-ID: <561F6852.8060001@riseup.net> +Date: Thu, 15 Oct 2015 08:48:18 +0000 +MIME-Version: 1.0 +In-Reply-To: <E68FE559-87CF-4146-9586-0C4B2CDEBF7A@mattcorallo.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: Ittay Eyal <ittay.eyal@cornell.edu> +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 08:48:27 -0000 + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA512 + +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----- + +iQEcBAEBCgAGBQJWH2hSAAoJEGxwq/inSG8CztwH/3kaBDCpci0WMjw9gEUybI+R +320i/cbPHHFO0eEJgWOK0mpYXYiEyoZULRjvHBjTNTS7wUVNmKsnmZDx1n9X9OCS +hQc9yoSZejoulA0f/Sys++N5ku9KPYN9EFnHpmgTtV7OW7aD8L66PCtiAOhNy7WD +T75eXjQvhWCCId1C3lvIzB6X1qTdK1gGMjNHzv49FP6RJDXa7RB7ceKrHwrXQ8J/ +kbQvwOjfmGbfDZb0tSvlNKT05s4CWW6TzsUdkg5QfMs16r6b1TAz55LLj7bonTNG +muFhywfBo0oLG0NbTTQTW0pmq9TF8iy8HV/4Z48Yu8bwrZ7UA1+Q7ghV3AFPHyE= +=x4Ek +-----END PGP SIGNATURE----- + |