[bitcoin-dev] Bitcoin-NG whitepaper.

[Emin Gün Sirer via bitcoin-dev]

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.

[Bryan Bishop via bitcoin-dev]

On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer

Post by Emin Gün Sirer via bitcoin-dev
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

For a system based entirely on fraud proofs and threat of fraud
proofs, see fidelity-bonded ledgers:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-February/002189.html
https://bitcointalk.org/index.php?topic=146307.0

- Bryan
http://heybryan.org/
1 512 203 0507

[Ittay via bitcoin-dev]

On Wed, Oct 14, 2015 at 1:02 PM, Emin GÃŒn Sirer

Post by Emin Gün Sirer via bitcoin-dev
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
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

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

Post by Ittay via bitcoin-dev

On Wed, Oct 14, 2015 at 1:02 PM, Emin GÃŒn Sirer

Post by Emin Gün Sirer via bitcoin-dev
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Ittay via bitcoin-dev]

Thanks, Matt. Response inline.

Post by 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 :(.

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.

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.

Post by Matt Corallo via bitcoin-dev
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).

Agreed x3: This is a good point, it is correct, and the tweak is dangerous.
Do you perceive this as a significant practical issue?

Post by Matt Corallo via bitcoin-dev
On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <

Post by Ittay via bitcoin-dev

On Wed, Oct 14, 2015 at 1:02 PM, Emin GÃŒn Sirer

Post by Emin Gün Sirer via bitcoin-dev
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Matt Corallo via bitcoin-dev]

Oops, just realized I never responded to this...

Post by Ittay via bitcoin-dev
Thanks, Matt. Response inline.
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.

Post by Ittay via bitcoin-dev
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.

Post by Ittay via bitcoin-dev
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).
Agreed x3: This is a good point, it is correct, and the tweak is dangerous.
Do you perceive this as a significant practical issue?

It is not a practical issue today because no one does it, but it is a
massive issue in that the splitting of pool rewards and transaction
selection is one of the few easy wins we have left in the fight against
mining centralization. Mining centralization today is absolutely awful,
and closing off our only big win would be tragic.

Post by Ittay via bitcoin-dev
On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev
On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer

Post by Emin Gün Sirer via bitcoin-dev
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Ittay via bitcoin-dev]

Post by Matt Corallo via bitcoin-dev
Oops, just realized I never responded to this...

Post by Ittay via bitcoin-dev
Thanks, Matt. Response inline.
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.

Post by Ittay via bitcoin-dev
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.

[Sergio Demian Lerner via bitcoin-dev]

I'm reading it.

First comment: since a Bitcoin block time is only greater than the median
of the last 11 blocks, a miner could choose the key block time in order to
generate about 400 miniblocks, instead of the average 60 blocks. Not very
bad, but should be taken into account.




On Wed, Oct 14, 2015 at 3:02 PM, Emin GÃŒn Sirer <

Post by Emin Gün Sirer via bitcoin-dev
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
http://hackingdistributed.com/2015/10/14/bitcoin-ng/
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Post by Emin Gün Sirer via bitcoin-dev
Hi everyone,
We just released the whitepaper describing Bitcoin-NG, a new technique

for

Post by Emin Gün Sirer via bitcoin-dev
addressing some of the scalability challenges faced by Bitcoin.

Surprisingly,

Post by Emin Gün Sirer via bitcoin-dev
Bitcoin-NG can simultaneously increase throughput while reducing

latency, and

Post by Emin Gün Sirer via bitcoin-dev
do so without impacting Bitcoin's open architecture or changing its trust
http://hackingdistributed.com/2015/10/14/bitcoin-ng/
http://arxiv.org/abs/1510.02037
Fitting NG on top of the current Bitcoin blockchain is future work that

we

Post by Emin Gün Sirer via bitcoin-dev
think is quite possible. NG is compatible with both Bitcoin as is, as

well as

Post by Emin Gün Sirer via bitcoin-dev
Blockstream-like sidechains, and we currently are not planning to compete
commercially with either technology -- we see NG as being complementary

to both

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Emin Gün Sirer via bitcoin-dev
adopted, or perhaps it can provide the spark of inspiration for someone

else to

Post by Emin Gün Sirer via bitcoin-dev
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
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

[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

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.

Post by Emin Gün Sirer via bitcoin-dev
Hi everyone,
We just released the whitepaper describing Bitcoin-NG, a new technique

for

Post by Emin Gün Sirer via bitcoin-dev
addressing some of the scalability challenges faced by Bitcoin.

Surprisingly,

Post by Emin Gün Sirer via bitcoin-dev
Bitcoin-NG can simultaneously increase throughput while reducing

latency, and

Post by Emin Gün Sirer via bitcoin-dev
do so without impacting Bitcoin's open architecture or changing its trust
http://hackingdistributed.com/2015/10/14/bitcoin-ng/
http://arxiv.org/abs/1510.02037
Fitting NG on top of the current Bitcoin blockchain is future work that

we

Post by Emin Gün Sirer via bitcoin-dev
think is quite possible. NG is compatible with both Bitcoin as is, as

well as

Post by Emin Gün Sirer via bitcoin-dev
Blockstream-like sidechains, and we currently are not planning to compete
commercially with either technology -- we see NG as being complementary

to both

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Emin Gün Sirer via bitcoin-dev
adopted, or perhaps it can provide the spark of inspiration for someone

else to

Post by Emin Gün Sirer via bitcoin-dev
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
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

[odinn via bitcoin-dev]

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?

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

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

Post by Emin Gün Sirer via bitcoin-dev
Hi everyone,
We just released the whitepaper describing Bitcoin-NG, a new
technique

for

Post by Emin Gün Sirer via bitcoin-dev
addressing some of the scalability challenges faced by
Bitcoin.

Surprisingly,

Post by Emin Gün Sirer via bitcoin-dev
Bitcoin-NG can simultaneously increase throughput while
reducing

latency, and

Post by Emin Gün Sirer via bitcoin-dev
do so without impacting Bitcoin's open architecture or changing
http://hackingdistributed.com/2015/10/14/bitcoin-ng/ while the
http://arxiv.org/abs/1510.02037
Fitting NG on top of the current Bitcoin blockchain is future work that

we

Post by Emin Gün Sirer via bitcoin-dev
think is quite possible. NG is compatible with both Bitcoin as is, as

well as

Post by Emin Gün Sirer via bitcoin-dev
Blockstream-like sidechains, and we currently are not planning
to compete commercially with either technology -- we see NG as
being complementary

to both

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Emin Gün Sirer via bitcoin-dev
adopted, or perhaps it can provide the spark of inspiration for someone

else to

Post by Emin Gün Sirer via bitcoin-dev
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
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
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

[Matt Corallo via bitcoin-dev]

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

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

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

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

Post by Emin Gün Sirer via bitcoin-dev
Hi everyone,
We just released the whitepaper describing Bitcoin-NG, a new technique

for

Post by Emin Gün Sirer via bitcoin-dev
addressing some of the scalability challenges faced by
Bitcoin.

Surprisingly,

Post by Emin Gün Sirer via bitcoin-dev
Bitcoin-NG can simultaneously increase throughput while
reducing

latency, and

Post by Emin Gün Sirer via bitcoin-dev
do so without impacting Bitcoin's open architecture or changing
http://hackingdistributed.com/2015/10/14/bitcoin-ng/ while the
http://arxiv.org/abs/1510.02037
Fitting NG on top of the current Bitcoin blockchain is future work that

we

Post by Emin Gün Sirer via bitcoin-dev
think is quite possible. NG is compatible with both Bitcoin as is, as

well as

Post by Emin Gün Sirer via bitcoin-dev
Blockstream-like sidechains, and we currently are not planning
to compete commercially with either technology -- we see NG as
being complementary

to both

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Emin Gün Sirer via bitcoin-dev
adopted, or perhaps it can provide the spark of inspiration for someone

else to

Post by Emin Gün Sirer via bitcoin-dev
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
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
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-----
iQEcBAEBCgAGBQJWHtVfAAoJEGxwq/inSG8C85kH/2T07oj/JM+bQcgy2kw9rtUa
XHkMNn86kVvtaniSKQ2j+SO9q8HkUI9Rv0Pz+qbX1CyAm6Z1FTCtDKornCnxx7FW
AJyZQSm5n40LUBIc3o2NBJvXKySTO2jpxluw0HAU8BQHSgFWwj1+vocqObDYxRCd
YDlhGd2ITmF55TlR+9seWqRyW+gABUoS+SaxM2yZaqWFlUGyOhYCJYpIo1nfWCZi
1F7/j0E92zu5kS5JJuRE91A4Si0LeTQPtPqXMeVm/UicdQB1a/aI0mzp6VRdm3Bo
gE79r1sKFFgpbQcz68OzPAL3RFTm1Q/C5jcqdy6cQjgp9em/v4uOCS3TKLWlVNQ=
=Einy
-----END PGP SIGNATURE-----
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[odinn via bitcoin-dev]

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?

Post by Matt Corallo via bitcoin-dev
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
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.
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?

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

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

Post by Emin Gün Sirer via bitcoin-dev
Hi everyone,
We just released the whitepaper describing Bitcoin-NG, a
new technique

for

Post by Emin Gün Sirer via bitcoin-dev
addressing some of the scalability challenges faced by
Bitcoin.

Surprisingly,

Post by Emin Gün Sirer via bitcoin-dev
Bitcoin-NG can simultaneously increase throughput while
reducing

latency, and

Post by Emin Gün Sirer via bitcoin-dev
do so without impacting Bitcoin's open architecture or
changing its trust model. This post illustrates the core
http://hackingdistributed.com/2015/10/14/bitcoin-ng/
http://arxiv.org/abs/1510.02037
Fitting NG on top of the current Bitcoin blockchain is
future work that

we

Post by Emin Gün Sirer via bitcoin-dev
think is quite possible. NG is compatible with both
Bitcoin as is, as

well as

Post by Emin Gün Sirer via bitcoin-dev
Blockstream-like sidechains, and we currently are not
planning to compete commercially with either technology
-- we see NG as being complementary

to both

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Emin Gün Sirer via bitcoin-dev
adopted, or perhaps it can provide the spark of
inspiration for someone

else to

Post by Emin Gün Sirer via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

!DSPAM:561e98cd301391127216946!

Post by Matt Corallo via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev

-- Cheers, Bob McElrath
"For every complex problem, there is a solution that is
simple, neat, and wrong." -- H. L. Mencken

_______________________________________________ bitcoin-dev
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________ bitcoin-dev
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

[Ittay via bitcoin-dev]

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

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

Post by Matt Corallo via bitcoin-dev
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
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.
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?

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

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

Post by Emin Gün Sirer via bitcoin-dev
Hi everyone,
We just released the whitepaper describing Bitcoin-NG, a new technique

for

Post by Emin Gün Sirer via bitcoin-dev
addressing some of the scalability challenges faced by
Bitcoin.

Surprisingly,

Post by Emin Gün Sirer via bitcoin-dev
Bitcoin-NG can simultaneously increase throughput while
reducing

latency, and

Post by Emin Gün Sirer via bitcoin-dev
do so without impacting Bitcoin's open architecture or
changing its trust model. This post illustrates the core
http://hackingdistributed.com/2015/10/14/bitcoin-ng/
http://arxiv.org/abs/1510.02037
Fitting NG on top of the current Bitcoin blockchain is
future work that

we

Post by Emin Gün Sirer via bitcoin-dev
think is quite possible. NG is compatible with both
Bitcoin as is, as

well as

Post by Emin Gün Sirer via bitcoin-dev
Blockstream-like sidechains, and we currently are not
planning to compete commercially with either technology
-- we see NG as being complementary

to both

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Emin Gün Sirer via bitcoin-dev
adopted, or perhaps it can provide the spark of
inspiration for someone

else to

Post by Emin Gün Sirer via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

!DSPAM:561e98cd301391127216946!

Post by Matt Corallo via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev

-- Cheers, Bob McElrath
"For every complex problem, there is a solution that is
simple, neat, and wrong." -- H. L. Mencken

_______________________________________________ bitcoin-dev
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________ bitcoin-dev
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-----

[odinn via bitcoin-dev]

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.

Post by Ittay via bitcoin-dev
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
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
(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?

Post by Matt Corallo via bitcoin-dev
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-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.
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?

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

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

Post by Emin Gün Sirer via bitcoin-dev
Hi everyone,
We just released the whitepaper describing
Bitcoin-NG, a new technique

for

Post by Emin Gün Sirer via bitcoin-dev
addressing some of the scalability challenges faced
by Bitcoin.

Surprisingly,

Post by Emin Gün Sirer via bitcoin-dev
Bitcoin-NG can simultaneously increase throughput
while reducing

latency, and

Post by Emin Gün Sirer via bitcoin-dev
do so without impacting Bitcoin's open architecture
or changing its trust model. This post illustrates
http://hackingdistributed.com/2015/10/14/bitcoin-ng/
http://arxiv.org/abs/1510.02037
Fitting NG on top of the current Bitcoin blockchain
is future work that

we

Post by Emin Gün Sirer via bitcoin-dev
think is quite possible. NG is compatible with
both Bitcoin as is, as

well as

Post by Emin Gün Sirer via bitcoin-dev
Blockstream-like sidechains, and we currently are
not planning to compete commercially with either
technology -- we see NG as being complementary

to both

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Emin Gün Sirer via bitcoin-dev
adopted, or perhaps it can provide the spark of
inspiration for someone

else to

Post by Emin Gün Sirer via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

!DSPAM:561e98cd301391127216946!

Post by Ittay via bitcoin-dev

Post by Matt Corallo via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev

-- Cheers, Bob McElrath
"For every complex problem, there is a solution that
is simple, neat, and wrong." -- H. L. Mencken

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________ bitcoin-dev

Post by Ittay via bitcoin-dev

Post by Matt Corallo via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev
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

[Bob McElrath 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.

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.

Post by Emin Gün Sirer via bitcoin-dev
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
     http://hackingdistributed.com/2015/10/14/bitcoin-ng/
     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
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

[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

Post by Emin Gün Sirer via bitcoin-dev
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
http://hackingdistributed.com/2015/10/14/bitcoin-ng/
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.