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

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

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

On Tue, Oct 27, 2015 at 10:08 PM, Matt Corallo wrote: > Oops, just realized I never responded to this... > > On 10/15/15 15:09, Ittay wrote: > > Thanks, Matt. Response inline. > > > > On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo > > wrote: > > > > That conve

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

Oops, just realized I never responded to this... On 10/15/15 15:09, Ittay wrote: > Thanks, Matt. Response inline. > > On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo > wrote: > > That conversation missed a second issue. Namely that there is no way > to pu

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

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

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

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

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

Thanks, Matt. Response inline. On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo wrote: > That conversation missed a second issue. Namely that there is no way to > punish people if there is a double spend in a micro block that happens in > key block which reorg'd away the first transaction. eg one m

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

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

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

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

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

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

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

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 shu

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

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 fi

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

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

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

On Wed, Oct 14, 2015 at 2:20 PM, Bob McElrath wrote: > So it seems to me that all I need to do is figure out who the current > leader is, > and DDoS him off the network to shut Bitcoin-NG down. > > This is a significant advantage to bitcoin's ex-post-facto blocks: no one > knows > where the next

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

On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop wrote: > On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer > wrote: > > while the whitepaper has all the nitty gritty details: > > http://arxiv.org/abs/1510.02037 > > Taking reward compensation back by fraud proofs is not enough to fix > the probl

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

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,

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

On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer wrote: > while the whitepaper has all the nitty gritty details: > http://arxiv.org/abs/1510.02037 Taking reward compensation back by fraud proofs is not enough to fix the problems associated with double spending (such as, everyone has to wait f

[bitcoin-dev] Bitcoin-NG whitepaper.

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