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

[Emin Gün Sirer via bitcoin-dev]

Hi everyone,

Thanks to everyone for a very friendly and scientifically-oriented
discussion. We have collated all the issues that have been raised related
to NG, and placed them in context, here:
http://hackingdistributed.com/2015/11/09/bitcoin-ng-followup/

Overall, NG has a unique insight: turning the block creation process upside
down can provide many benefits. Most notably, throughput can go as high as
the network will allow, providing scalability benefits that increase as the
network improves. There are many other side benefits, including fast
confirmations that are stronger than 0-conf in Core, and come much more
quickly than Core's 1-confirmations. And there are ancillary benefits as
well, such as resilience to fluctuations in mining power, and healthier
incentives for participants to ferry transactions. We believe that a fresh
new permission-less blockchain protocol, designed today, would end up
looking more like NG than Core. Of course, if NG could possibly be layered
on top of Bitcoin, that would be the ultimate combination.

Many thanks for an interesting discussion, and as always, we're happy to
hear constructive suggestions and feedback,
- egs


On Wed, Oct 14, 2015 at 2:02 PM, Emin Gün Sirer 
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.
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Ittay via bitcoin-dev]

On Tue, Oct 27, 2015 at 10:08 PM, Matt Corallo 
wrote:

> Oops, just realized I never responded to this...
>
> On 10/15/15 15:09, Ittay wrote:
> > Thanks, Matt. Response inline.
> >
> > On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo  > > wrote:
> >
> > That conversation missed a second issue. Namely that there is no way
> > to punish people if there is a double spend in a micro block that
> > happens in key block which reorg'd away the first transaction. eg
> > one miner mines a transaction in a micro block, another miner
> > (either by not having seen the first yet, or being malicious -
> > potentially the same miner) mines a key block which reorgs away the
> > first micro block and then, in their first micro block, mines a
> > double spend. This can happen at any time, so you end up having to
> > fall back to regular full blocks for confirmation times :(.
> >
> >
> > If NG is to be used efficiently, microblocks are going to be very
> > frequent, and so such forks should occur at almost every key-block
> > publication. Short reorgs as you described are the norm. A user should
> > wait before accepting a transaction to make sure there was no key-block
> > she missed. The wait time is chosen according to the network propagation
> > delay (+as much slack as the user feels necessary). This is similar to
> > the situation in Bitcoin when you receive a block. To be confident that
> > you have one confirmation you should wait for the propagation time of
> > the network to make sure there is no branch you missed.
>
> I think you're overstating how short the wait times can be. They need to
> be much longer than the network propagation delay.
>
> > As for the malicious case: the attacker has to win the key-block, have
> > the to-be-inverted transaction in the previous epoch, and withhold his
> > key-block for a while. That being said, indeed our fraud proof scheme
> > doesn't catch such an event, as it is indistinguishable from benign
> > behavior.
>
> The attacker does not need to withold their keyblock at all. All the
> attacker does is, for every transaction they ever send, after it is
> included in a microblock, set their hashpower to start mining a keyblock
> immediately prior to this microblock. When they find a keyblock, they
> immediately announce it and start creating microblocks, the first of
> which double-spends the previous transaction. If they dont win the key
> block, oh well, their payment went through normally and they couldn't
> double-spend.
>
> In chatting with Glenn about this, we roughly agreed that the
> confirmation time for microblocks possibly doesn't need to be a full
> key-block, but it needs to be a reasonable period after which such an
> attacker would lose more in fees than the value of their double-spend
> (ie because the key-block afterwards gets 20% more in fees than the
> key-block before hand). In any case, the game theory here starts to get
> rather complicated and it doesn't make me want to suggest accepting
> microblocks as confirmations is safe.
>

Yes, an attacker can continuously try to do this, losing all (and only)
fees.
They will succeed every time they mine a block after the to-be-double-spent
transaction is placed by the current leader. So a microblock + delay is
stronger
than a zero-confirmation transaction, but not as strong as a first-block
confirmation.

A game theory analysis is indeed difficult here, mainly since the
assumptions
are not entirely clear. We are working towards this, starting with
formalizing
the attacker's incentive structure.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[odinn via bitcoin-dev]

-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 

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

[Ittay via bitcoin-dev]

On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop  wrote:

> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
>  wrote:
> > while the whitepaper has all the nitty gritty details:
> >  http://arxiv.org/abs/1510.02037
>
> Taking reward compensation back by fraud proofs is not enough to fix
> the problems associated with double spending (such as, everyone has to
> wait for the "real" confirmations instead of the "possibly
> double-spend" confirmations). Some of this was discussed in -wizards
> recently:
> http://gnusha.org/bitcoin-wizards/2015-09-19.log


Fraud proof removes all the attacker's revenue. It's like the attacker
sacrifices an entire block for double spending in the current system. I
think Luke-Jr got it right at that discussion.

Best,
Ittay
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Ittay via bitcoin-dev]

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

That's an interesting point, but such an attack is difficult to pull off.
Miners
often run multiple well connected nodes, allowing them to propagate their
generated blocks from multiple vantage points.

Best,
Ittay


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

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

[Matt Corallo via bitcoin-dev]

That conversation missed a second issue. Namely that there is no way to punish 
people if there is a double spend in a micro block that happens in key block 
which reorg'd away the first transaction. eg one miner mines a transaction in a 
micro block, another miner (either by not having seen the first yet, or being 
malicious - potentially the same miner) mines a key block which reorgs away the 
first micro block and then, in their first micro block, mines a double spend. 
This can happen at any time, so you end up having to fall back to regular full 
blocks for confirmation times :(.

Also, Greg Slepak brought up a good point on twitter at 
https://twitter.com/taoeffect/status/654358023138209792. Noting that this model 
means users could no longer pick transactions in a mining pool which was set up 
in such a way (it could be tweaked to do so with separate rewards and pubkeys, 
but now the user can commit fraud at a much lower cost - their own pool reward, 
not the block's total reward).

On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev 
 wrote:
>On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop 
>wrote:
>
>> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
>>  wrote:
>> > while the whitepaper has all the nitty gritty details:
>> >  http://arxiv.org/abs/1510.02037
>>
>> Taking reward compensation back by fraud proofs is not enough to fix
>> the problems associated with double spending (such as, everyone has
>to
>> wait for the "real" confirmations instead of the "possibly
>> double-spend" confirmations). Some of this was discussed in -wizards
>> recently:
>> http://gnusha.org/bitcoin-wizards/2015-09-19.log
>
>
>Fraud proof removes all the attacker's revenue. It's like the attacker
>sacrifices an entire block for double spending in the current system. I
>think Luke-Jr got it right at that discussion.
>
>Best,
>Ittay
>
>
>
>
>___
>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

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

[odinn via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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