* [bitcoin-dev] Bitcoin-NG whitepaper.
@ 2015-10-14 18:02 Emin Gün Sirer
2015-10-14 18:12 ` Bryan Bishop
` (4 more replies)
0 siblings, 5 replies; 17+ messages in thread
From: Emin Gün Sirer @ 2015-10-14 18:02 UTC (permalink / raw)
To: bitcoin-dev; +Cc: Ittay Eyal
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1515 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-14 18:02 [bitcoin-dev] Bitcoin-NG whitepaper Emin Gün Sirer @ 2015-10-14 18:12 ` Bryan Bishop 2015-10-14 18:28 ` Ittay 2015-10-14 18:14 ` Sergio Demian Lerner ` (3 subsequent siblings) 4 siblings, 1 reply; 17+ messages in thread From: Bryan Bishop @ 2015-10-14 18:12 UTC (permalink / raw) To: Emin Gün Sirer, Bryan Bishop; +Cc: Bitcoin Dev, Ittay Eyal On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer <bitcoin-dev@lists•linuxfoundation.org> 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 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-14 18:12 ` Bryan Bishop @ 2015-10-14 18:28 ` Ittay 2015-10-14 18:57 ` Matt Corallo 0 siblings, 1 reply; 17+ messages in thread From: Ittay @ 2015-10-14 18:28 UTC (permalink / raw) To: Bryan Bishop; +Cc: Bitcoin Dev, Ittay Eyal [-- Attachment #1: Type: text/plain, Size: 841 bytes --] On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail•com> wrote: > On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer > <bitcoin-dev@lists•linuxfoundation.org> 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 [-- Attachment #2: Type: text/html, Size: 1555 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-14 18:28 ` Ittay @ 2015-10-14 18:57 ` Matt Corallo 2015-10-15 15:09 ` Ittay 0 siblings, 1 reply; 17+ messages in thread From: Matt Corallo @ 2015-10-14 18:57 UTC (permalink / raw) To: Ittay, Ittay via bitcoin-dev, Bryan Bishop; +Cc: Bitcoin Dev, Ittay Eyal [-- Attachment #1: Type: text/plain, Size: 2200 bytes --] 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 <bitcoin-dev@lists•linuxfoundation.org> wrote: >On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail•com> >wrote: > >> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer >> <bitcoin-dev@lists•linuxfoundation.org> 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 [-- Attachment #2: Type: text/html, Size: 3323 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-14 18:57 ` Matt Corallo @ 2015-10-15 15:09 ` Ittay 2015-10-28 2:08 ` Matt Corallo 0 siblings, 1 reply; 17+ messages in thread From: Ittay @ 2015-10-15 15:09 UTC (permalink / raw) To: Matt Corallo; +Cc: Ittay, Ittay via bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3427 bytes --] Thanks, Matt. Response inline. On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo <lf-lists@mattcorallo•com> 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. 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. > 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? > > On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> >> On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail•com> wrote: >> >>> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer >>> <bitcoin-dev@lists•linuxfoundation.org> 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 >> >> [-- Attachment #2: Type: text/html, Size: 5315 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-15 15:09 ` Ittay @ 2015-10-28 2:08 ` Matt Corallo 2015-11-06 20:48 ` Ittay 0 siblings, 1 reply; 17+ messages in thread From: Matt Corallo @ 2015-10-28 2:08 UTC (permalink / raw) To: Ittay; +Cc: Ittay via bitcoin-dev 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 <lf-lists@mattcorallo•com > <mailto:lf-lists@mattcorallo•com>> 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. > 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. > On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > > On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail•com > <mailto:kanzure@gmail•com>> wrote: > > On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> 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 > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-28 2:08 ` Matt Corallo @ 2015-11-06 20:48 ` Ittay 0 siblings, 0 replies; 17+ messages in thread From: Ittay @ 2015-11-06 20:48 UTC (permalink / raw) To: Matt Corallo; +Cc: Ittay, Ittay via bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3671 bytes --] On Tue, Oct 27, 2015 at 10:08 PM, Matt Corallo <lf-lists@mattcorallo•com> 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 <lf-lists@mattcorallo•com > > <mailto:lf-lists@mattcorallo•com>> 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. [-- Attachment #2: Type: text/html, Size: 5121 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-14 18:02 [bitcoin-dev] Bitcoin-NG whitepaper Emin Gün Sirer 2015-10-14 18:12 ` Bryan Bishop @ 2015-10-14 18:14 ` Sergio Demian Lerner [not found] ` <20151014182055.GC23875@mcelrath.org> ` (2 subsequent siblings) 4 siblings, 0 replies; 17+ messages in thread From: Sergio Demian Lerner @ 2015-10-14 18:14 UTC (permalink / raw) To: Emin Gün Sirer; +Cc: bitcoin-dev, Ittay Eyal [-- Attachment #1: Type: text/plain, Size: 1899 bytes --] 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 < 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. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2680 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <20151014182055.GC23875@mcelrath.org>]
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. [not found] ` <20151014182055.GC23875@mcelrath.org> @ 2015-10-14 18:38 ` Ittay 2015-10-14 18:39 ` Emin Gün Sirer 1 sibling, 0 replies; 17+ messages in thread From: Ittay @ 2015-10-14 18:38 UTC (permalink / raw) To: Bob McElrath; +Cc: bitcoin-dev, Ittay Eyal [-- Attachment #1: Type: text/plain, Size: 2554 bytes --] 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. > 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 > > [-- Attachment #2: Type: text/html, Size: 3701 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. [not found] ` <20151014182055.GC23875@mcelrath.org> 2015-10-14 18:38 ` Ittay @ 2015-10-14 18:39 ` Emin Gün Sirer 2015-10-14 22:21 ` odinn 1 sibling, 1 reply; 17+ messages in thread From: Emin Gün Sirer @ 2015-10-14 18:39 UTC (permalink / raw) To: Bob McElrath; +Cc: bitcoin-dev, Ittay Eyal [-- Attachment #1: Type: text/plain, Size: 3173 bytes --] >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 > > [-- Attachment #2: Type: text/html, Size: 4208 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-14 18:39 ` Emin Gün Sirer @ 2015-10-14 22:21 ` odinn 2015-10-15 1:59 ` Matt Corallo 0 siblings, 1 reply; 17+ messages in thread From: odinn @ 2015-10-14 22:21 UTC (permalink / raw) To: Emin Gün Sirer, Bob McElrath; +Cc: bitcoin-dev, Ittay Eyal -----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\fned 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 > - -- 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----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-14 22:21 ` odinn @ 2015-10-15 1:59 ` Matt Corallo 2015-10-15 8:48 ` odinn 0 siblings, 1 reply; 17+ messages in thread From: Matt Corallo @ 2015-10-15 1:59 UTC (permalink / raw) To: odinn, odinn via bitcoin-dev, Emin Gün Sirer, Bob McElrath Cc: bitcoin-dev, Ittay Eyal 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: >-----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\f>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 >> > >- -- >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 >bitcoin-dev@lists•linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-15 1:59 ` Matt Corallo @ 2015-10-15 8:48 ` odinn 2015-10-15 15:12 ` Ittay 0 siblings, 1 reply; 17+ messages in thread From: odinn @ 2015-10-15 8:48 UTC (permalink / raw) To: Matt Corallo, odinn via bitcoin-dev, Emin Gün Sirer, Bob McElrath Cc: Ittay Eyal -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So, there could not be, for example, a user decision to activate it? (versus not activate it)? I'm wondering if something about this can be boiled down to allowing the user to make a choice on the matter (turn it on and off). In Bitcoin-NG, the protocol as follows (as described in a general overview of it): every 10 minutes, NG elects a 'leader,' who then vets future transactions as soon as they happen. NG approach supposedly can run as fast as the network will allow. If this is the case, and if NG functions without major hiccup, shouldn't a user (of Core, for example) be able to be given the option to choose between: (a) being limited by the blocksize and block interval, or (b) running out as fast as the network will allow (NG)? The other questions I had pertained to privacy. How would this scheme affect users who would be trying to do things like stealth or confidential transactions? Matt Corallo: > Huh? No... This is not a Bitcoin Core issue, it is a Bitcoin > protocol one and should be discussed here, not on github. I really > appreciate Ittay and Emin's efforts in this space and their > willingness to work with the Bitcoin community on it! It seems it > still needs some tuning, but seems like if the pool-mining issues > were resolved it could make block relay times irrelevant, at > least. > > Matt > > On October 14, 2015 3:21:19 PM PDT, odinn via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: This (Bitcoin-NG in > concept) could be done as a (issue and pull request process) to > Bitcoin Core itself, amirite? It seems like it would provide an > interesting issue to open and have healthy discussion on both > mailing list and github, adding the caveat that it would be at the > user's option. Thus if something like Bitcoin-NG did come to be it > would be something more like a feature that the user could > activate / deactivate from within Core. I assume it would be > default off, but with the option to utilize. Code would thus be > available to others as well. I am not saying yea or nay on it, > just that it seems like this could be done. > > Some notes: > > Once a node generates a key block it becomes the leader. As a > leader, the node is allowed to generate microblocks at a set > rate smaller than a prede\f>ned maximum. A microblock in > Bitcoin-NG contains ledger entries and a header. The header > contains the reference to the previous block, the current > GMT time, a cryptographic hash of its ledger entries, and > a cryptographic signature of the header. The signature uses > the private key that matches the public key in the latest key > block in the chain. For a microblock to be valid, all its entries > must be valid according to the specification of the state machine, > and the signature has to be valid. However, the microblocks, it is > said, don't affect the weight of the chain, because they do not > contain proof of work. It is assumed by the authors of this model > that this situation is critical for maintaining incentives here. > > The questions that then begin to emerge to me are how is this > information managed and protected? The headers, thus containing > reference(s) to previous block(s), current GMT time(s), > cryptographic hash(es) of ledger entries, and cryptographic > signature(s) of the headers, so forth, and other information. Can > the Bitcoin-NG scheme be designed or implemented in a manner which > supports Stealth sends, Confidential Transactions, or similar > privacy measures? Or is this something which cannot be answered at > this time? > > Emin Gün Sirer via bitcoin-dev: >>>>> So it seems to me that all I need to do is figure out who >>>>> the current >>>> leader is, >>>>> and DDoS him off the network to shut Bitcoin-NG down. >>>> >>>> Good point. If NG is layered on top of Bitcoin, we'd retain >>>> all of Bitcoin as is. This would confer all the benefits of >>>> Bitcoin's retrospective blocks, as well as add the ability to >>>> mint microblocks with low latency in between. And despite the >>>> phrase "the leader," the actual leader in NG is a key, not a >>>> specific node. That makes it possible to deter DDoS attacks >>>> by dynamically migrating where in the network the leader is >>>> operating in response to an attack. Finally, DDoS attacks >>>> against miners are already possible, but they seem rare, and >>>> I suspect it's at least partly because of the success of Matt >>>> Corallo's high speed bitcoin relay network. Similar defenses >>>> can apply here. >>>> >>>> - egs >>>> >>>> >>>> >>>> On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath >>>> <bob@mcelrath•org> wrote: >>>> >>>>> So it seems to me that all I need to do is figure out who >>>>> the current leader is, and DDoS him off the network to >>>>> shut Bitcoin-NG down. >>>>> >>>>> This is a significant advantage to bitcoin's ex-post-facto >>>>> blocks: no one knows where the next one will come from. >>>>> The only way to shut the network down is to shut all nodes >>>>> down. >>>>> >>>>> Emin Gün Sirer via bitcoin-dev >>>>> [bitcoin-dev@lists•linuxfoundation.org] wrote: >>>>>> Hi everyone, >>>>>> >>>>>> We just released the whitepaper describing Bitcoin-NG, a >>>>>> new technique >>>>> for >>>>>> addressing some of the scalability challenges faced by >>>>>> Bitcoin. >>>>> Surprisingly, >>>>>> Bitcoin-NG can simultaneously increase throughput while >>>>>> reducing >>>>> latency, and >>>>>> do so without impacting Bitcoin's open architecture or >>>>>> changing its trust model. This post illustrates the core >>>>>> technique: >>>>>> http://hackingdistributed.com/2015/10/14/bitcoin-ng/ >>>>>> while the whitepaper has all the nitty gritty details: >>>>>> http://arxiv.org/abs/1510.02037 >>>>>> >>>>>> Fitting NG on top of the current Bitcoin blockchain is >>>>>> future work that >>>>> we >>>>>> think is quite possible. NG is compatible with both >>>>>> Bitcoin as is, as >>>>> well as >>>>>> Blockstream-like sidechains, and we currently are not >>>>>> planning to compete commercially with either technology >>>>>> -- we see NG as being complementary >>>>> to both >>>>>> efforts. This is pure science, published and shared with >>>>>> the community to advance the state of blockchains and to >>>>>> help them reach throughputs and latencies required of >>>>>> cutting edge fintech applications. Perhaps it can >>>>> be >>>>>> adopted, or perhaps it can provide the spark of >>>>>> inspiration for someone >>>>> else to >>>>>> come up with even better solutions. >>>>>> >>>>>> We would be delighted to hear your feedback. - Ittay Eyal >>>>>> and E. Gün Sirer. >>>>>> >>>>>> !DSPAM:561e98cd301391127216946! >>>>> >>>>>> _______________________________________________ >>>>>> bitcoin-dev mailing list >>>>>> bitcoin-dev@lists•linuxfoundation.org >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>> >>>>>> >>>>>> >>>>>> !DSPAM:561e98cd301391127216946! >>>>> >>>>> -- Cheers, Bob McElrath >>>>> >>>>> "For every complex problem, there is a solution that is >>>>> simple, neat, and wrong." -- H. L. Mencken >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ bitcoin-dev >>>> mailing list bitcoin-dev@lists•linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> > >>>> >> _______________________________________________ bitcoin-dev >> mailing list bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJWH2hSAAoJEGxwq/inSG8CztwH/3kaBDCpci0WMjw9gEUybI+R 320i/cbPHHFO0eEJgWOK0mpYXYiEyoZULRjvHBjTNTS7wUVNmKsnmZDx1n9X9OCS hQc9yoSZejoulA0f/Sys++N5ku9KPYN9EFnHpmgTtV7OW7aD8L66PCtiAOhNy7WD T75eXjQvhWCCId1C3lvIzB6X1qTdK1gGMjNHzv49FP6RJDXa7RB7ceKrHwrXQ8J/ kbQvwOjfmGbfDZb0tSvlNKT05s4CWW6TzsUdkg5QfMs16r6b1TAz55LLj7bonTNG muFhywfBo0oLG0NbTTQTW0pmq9TF8iy8HV/4Z48Yu8bwrZ7UA1+Q7ghV3AFPHyE= =x4Ek -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-15 8:48 ` odinn @ 2015-10-15 15:12 ` Ittay 2015-10-15 18:43 ` odinn 0 siblings, 1 reply; 17+ messages in thread From: Ittay @ 2015-10-15 15:12 UTC (permalink / raw) To: odinn; +Cc: odinn via bitcoin-dev, Ittay Eyal, Bob McElrath [-- Attachment #1: Type: text/plain, Size: 9757 bytes --] 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: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > So, there could not be, for example, a user decision to activate it? > (versus not activate it)? I'm wondering if something about this can > be boiled down to allowing the user to make a choice on the matter > (turn it on and off). In Bitcoin-NG, the protocol as follows (as > described in a general overview of it): every 10 minutes, NG elects a > 'leader,' who then vets future transactions as soon as they happen. NG > approach supposedly can run as fast as the network will allow. > > If this is the case, and if NG functions without major hiccup, > shouldn't a user (of Core, for example) be able to be given the option > to choose between: > > (a) being limited by the blocksize and block interval, or > (b) running out as fast as the network will allow (NG)? > > The other questions I had pertained to privacy. How would this scheme > affect users who would be trying to do things like stealth or > confidential transactions? > > Matt Corallo: > > Huh? No... This is not a Bitcoin Core issue, it is a Bitcoin > > protocol one and should be discussed here, not on github. I really > > appreciate Ittay and Emin's efforts in this space and their > > willingness to work with the Bitcoin community on it! It seems it > > still needs some tuning, but seems like if the pool-mining issues > > were resolved it could make block relay times irrelevant, at > > least. > > > > Matt > > > > On October 14, 2015 3:21:19 PM PDT, odinn via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation.org> wrote: This (Bitcoin-NG in > > concept) could be done as a (issue and pull request process) to > > Bitcoin Core itself, amirite? It seems like it would provide an > > interesting issue to open and have healthy discussion on both > > mailing list and github, adding the caveat that it would be at the > > user's option. Thus if something like Bitcoin-NG did come to be it > > would be something more like a feature that the user could > > activate / deactivate from within Core. I assume it would be > > default off, but with the option to utilize. Code would thus be > > available to others as well. I am not saying yea or nay on it, > > just that it seems like this could be done. > > > > Some notes: > > > > Once a node generates a key block it becomes the leader. As a > > leader, the node is allowed to generate microblocks at a set > > rate smaller than a prede >ned maximum. A microblock in > > Bitcoin-NG contains ledger entries and a header. The header > > contains the reference to the previous block, the current > > GMT time, a cryptographic hash of its ledger entries, and > > a cryptographic signature of the header. The signature uses > > the private key that matches the public key in the latest key > > block in the chain. For a microblock to be valid, all its entries > > must be valid according to the specification of the state machine, > > and the signature has to be valid. However, the microblocks, it is > > said, don't affect the weight of the chain, because they do not > > contain proof of work. It is assumed by the authors of this model > > that this situation is critical for maintaining incentives here. > > > > The questions that then begin to emerge to me are how is this > > information managed and protected? The headers, thus containing > > reference(s) to previous block(s), current GMT time(s), > > cryptographic hash(es) of ledger entries, and cryptographic > > signature(s) of the headers, so forth, and other information. Can > > the Bitcoin-NG scheme be designed or implemented in a manner which > > supports Stealth sends, Confidential Transactions, or similar > > privacy measures? Or is this something which cannot be answered at > > this time? > > > > Emin Gün Sirer via bitcoin-dev: > >>>>> So it seems to me that all I need to do is figure out who > >>>>> the current > >>>> leader is, > >>>>> and DDoS him off the network to shut Bitcoin-NG down. > >>>> > >>>> Good point. If NG is layered on top of Bitcoin, we'd retain > >>>> all of Bitcoin as is. This would confer all the benefits of > >>>> Bitcoin's retrospective blocks, as well as add the ability to > >>>> mint microblocks with low latency in between. And despite the > >>>> phrase "the leader," the actual leader in NG is a key, not a > >>>> specific node. That makes it possible to deter DDoS attacks > >>>> by dynamically migrating where in the network the leader is > >>>> operating in response to an attack. Finally, DDoS attacks > >>>> against miners are already possible, but they seem rare, and > >>>> I suspect it's at least partly because of the success of Matt > >>>> Corallo's high speed bitcoin relay network. Similar defenses > >>>> can apply here. > >>>> > >>>> - egs > >>>> > >>>> > >>>> > >>>> On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath > >>>> <bob@mcelrath•org> wrote: > >>>> > >>>>> So it seems to me that all I need to do is figure out who > >>>>> the current leader is, and DDoS him off the network to > >>>>> shut Bitcoin-NG down. > >>>>> > >>>>> This is a significant advantage to bitcoin's ex-post-facto > >>>>> blocks: no one knows where the next one will come from. > >>>>> The only way to shut the network down is to shut all nodes > >>>>> down. > >>>>> > >>>>> Emin Gün Sirer via bitcoin-dev > >>>>> [bitcoin-dev@lists•linuxfoundation.org] wrote: > >>>>>> Hi everyone, > >>>>>> > >>>>>> We just released the whitepaper describing Bitcoin-NG, a > >>>>>> new technique > >>>>> for > >>>>>> addressing some of the scalability challenges faced by > >>>>>> Bitcoin. > >>>>> Surprisingly, > >>>>>> Bitcoin-NG can simultaneously increase throughput while > >>>>>> reducing > >>>>> latency, and > >>>>>> do so without impacting Bitcoin's open architecture or > >>>>>> changing its trust model. This post illustrates the core > >>>>>> technique: > >>>>>> http://hackingdistributed.com/2015/10/14/bitcoin-ng/ > >>>>>> while the whitepaper has all the nitty gritty details: > >>>>>> http://arxiv.org/abs/1510.02037 > >>>>>> > >>>>>> Fitting NG on top of the current Bitcoin blockchain is > >>>>>> future work that > >>>>> we > >>>>>> think is quite possible. NG is compatible with both > >>>>>> Bitcoin as is, as > >>>>> well as > >>>>>> Blockstream-like sidechains, and we currently are not > >>>>>> planning to compete commercially with either technology > >>>>>> -- we see NG as being complementary > >>>>> to both > >>>>>> efforts. This is pure science, published and shared with > >>>>>> the community to advance the state of blockchains and to > >>>>>> help them reach throughputs and latencies required of > >>>>>> cutting edge fintech applications. Perhaps it can > >>>>> be > >>>>>> adopted, or perhaps it can provide the spark of > >>>>>> inspiration for someone > >>>>> else to > >>>>>> come up with even better solutions. > >>>>>> > >>>>>> We would be delighted to hear your feedback. - Ittay Eyal > >>>>>> and E. Gün Sirer. > >>>>>> > >>>>>> !DSPAM:561e98cd301391127216946! > >>>>> > >>>>>> _______________________________________________ > >>>>>> bitcoin-dev mailing list > >>>>>> bitcoin-dev@lists•linuxfoundation.org > >>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >>>>>> > >>>>>> > >>>>>> > >>>>>> > !DSPAM:561e98cd301391127216946! > >>>>> > >>>>> -- Cheers, Bob McElrath > >>>>> > >>>>> "For every complex problem, there is a solution that is > >>>>> simple, neat, and wrong." -- H. L. Mencken > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ bitcoin-dev > >>>> mailing list bitcoin-dev@lists•linuxfoundation.org > >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >>>> > > > >>>> > >> _______________________________________________ bitcoin-dev > >> mailing list bitcoin-dev@lists•linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > - -- > http://abis.io ~ > "a protocol concept to enable decentralization > and expansion of a giving economy, and a new social good" > https://keybase.io/odinn > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBCgAGBQJWH2hSAAoJEGxwq/inSG8CztwH/3kaBDCpci0WMjw9gEUybI+R > 320i/cbPHHFO0eEJgWOK0mpYXYiEyoZULRjvHBjTNTS7wUVNmKsnmZDx1n9X9OCS > hQc9yoSZejoulA0f/Sys++N5ku9KPYN9EFnHpmgTtV7OW7aD8L66PCtiAOhNy7WD > T75eXjQvhWCCId1C3lvIzB6X1qTdK1gGMjNHzv49FP6RJDXa7RB7ceKrHwrXQ8J/ > kbQvwOjfmGbfDZb0tSvlNKT05s4CWW6TzsUdkg5QfMs16r6b1TAz55LLj7bonTNG > muFhywfBo0oLG0NbTTQTW0pmq9TF8iy8HV/4Z48Yu8bwrZ7UA1+Q7ghV3AFPHyE= > =x4Ek > -----END PGP SIGNATURE----- > [-- Attachment #2: Type: text/html, Size: 13721 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-15 15:12 ` Ittay @ 2015-10-15 18:43 ` odinn 0 siblings, 0 replies; 17+ messages in thread From: odinn @ 2015-10-15 18:43 UTC (permalink / raw) To: Ittay; +Cc: odinn via bitcoin-dev, Bob McElrath -----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----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-14 18:02 [bitcoin-dev] Bitcoin-NG whitepaper Emin Gün Sirer ` (2 preceding siblings ...) [not found] ` <20151014182055.GC23875@mcelrath.org> @ 2015-10-14 20:52 ` Bob McElrath 2015-11-09 18:33 ` Emin Gün Sirer 4 siblings, 0 replies; 17+ messages in thread From: Bob McElrath @ 2015-10-14 20:52 UTC (permalink / raw) To: Emin Gün Sirer; +Cc: bitcoin-dev, Ittay Eyal 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Bitcoin-NG whitepaper. 2015-10-14 18:02 [bitcoin-dev] Bitcoin-NG whitepaper Emin Gün Sirer ` (3 preceding siblings ...) 2015-10-14 20:52 ` Bob McElrath @ 2015-11-09 18:33 ` Emin Gün Sirer 4 siblings, 0 replies; 17+ messages in thread From: Emin Gün Sirer @ 2015-11-09 18:33 UTC (permalink / raw) To: bitcoin-dev; +Cc: Ittay Eyal [-- Attachment #1: Type: text/plain, Size: 2601 bytes --] 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 <el33th4x0r@gmail•com> 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. > > [-- Attachment #2: Type: text/html, Size: 3546 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-11-09 18:33 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-14 18:02 [bitcoin-dev] Bitcoin-NG whitepaper Emin Gün Sirer
2015-10-14 18:12 ` Bryan Bishop
2015-10-14 18:28 ` Ittay
2015-10-14 18:57 ` Matt Corallo
2015-10-15 15:09 ` Ittay
2015-10-28 2:08 ` Matt Corallo
2015-11-06 20:48 ` Ittay
2015-10-14 18:14 ` Sergio Demian Lerner
[not found] ` <20151014182055.GC23875@mcelrath.org>
2015-10-14 18:38 ` Ittay
2015-10-14 18:39 ` Emin Gün Sirer
2015-10-14 22:21 ` odinn
2015-10-15 1:59 ` Matt Corallo
2015-10-15 8:48 ` odinn
2015-10-15 15:12 ` Ittay
2015-10-15 18:43 ` odinn
2015-10-14 20:52 ` Bob McElrath
2015-11-09 18:33 ` Emin Gün Sirer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox