Re: [bitcoin-dev] Bitcoin-NG whitepaper.

From: odinn <odinn.cyberguerrilla@riseup•net>
To: Ittay <ittay.eyal@cornell•edu>
Cc: odinn via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>,
	Bob McElrath <bob@mcelrath•org>
Subject: Re: [bitcoin-dev] Bitcoin-NG whitepaper.
Date: Thu, 15 Oct 2015 18:43:43 +0000	[thread overview]
Message-ID: <561FF3DF.6010008@riseup.net> (raw)
In-Reply-To: <CABT1wWnH8TeMkwwrjqvgOWYbYtLE-CneDwNpf7Py06_EvhOJRQ@mail.gmail.com>

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