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
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 tec
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
By now, we have seen quite a few proposals for the block size increase.
It's hard not to notice that there are potentially infinitely many
functions for future block size increases. One could, for instance, double
every N years for any rational number N, one could increase linearly, one
could doubl
Thanks Peter for the careful, quantitative work.
I want to bring one additional issue to everyone's consideration, related
to the choice of the Lempel-Ziv family of compressors.
While I'm not familiar with every single compression engine tested, the
Lempel-Ziv family of compressors are generally
.,
,
/.
, /,
,.
/ ,
..
,,, . // ., .
_. ... .. ._.
,_
,
,
,
, , ... _ _.
,.
. ,.,_.
.,, ..
,
,,
._
. .
_
.
,
, ,, /..,,
/ ,
. .
_
.,. _.. ,
,
.. _
..
,.,, _
, _
,
///
. ,
/ . ,.
,
,.,
. ,
, ., ,. ._ , ,,,//
,,
.
There's quite a bit of confusion in this thread.
Peter is referring to block withholding attacks. Ittay Eyal (as sole
author -- I was not involved in this paper [1]) was the first
to analyze these attacks and to discover a fascinating, paradoxical
result. An attacker pool (A) can take a certain po
Initial reactions aren't always accurate, people's views change, and
science has its insurmountable way of convincing people. Gavin [1]
and others [2] now cite selfish mining as a concern in the block size
debate, and more importantly, the paper has been peer-reviewed,
cited, and even built-upon [3
On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd wrote:
> There are a number of techniques that can be used to detect block
> withholding attacks that you are not aware of. These techniques usually
> have the characteristic that if known they can be avoided, so obviously
> those who know about them ar
>Another option for how to deal with block withholding attacks: Give the
miner who finds the block a bonus.
...
>This must have been proposed before, right? Anyone know of a good analysis
of the game theory math?
Yes, Section 8.D. in Ittay's paper discusses this countermeasure, as well
as a few ot
On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Do you specifically mean selfish mining as defined in Emin Gün
> Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant
> issue in a scenario - one malicious miner with >
Ittay Eyal and I just put together a writeup that we're informally calling
Bitcoin-United for preserving the value of coins following a permanent fork:
http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/
Half of the core idea is to eliminate double-spends (where someone
On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd wrote:
> Note how transaction malleability can quickly sabotage naive notions of
> this idea.
>
Bitcoin-United relies on a notion of transaction equivalence that doesn't
involve the transaction hash at all, so it should be immune to malleability
issues
At the 3rd Bitcoin Workshop being held in conjunction with the Financial
Cryptography Conference in Barbados, my group will be presenting a new idea
for improving Bitcoin wallet security and deterring thefts today.
The write-up is here:
http://hackingdistributed.com/2016/02/26/how-to-implement-se
There seems to be a perception out there that Bitcoin is eventually
consistent. I wrote this post to describe why this perception is completely
false.
Bitcoin Guarantees Strong, not Eventual, Consistency
http://hackingdistributed.com/2016/03/01/bitcoin-guarantees-strong-not-eventual-consistency/
> The entire point of the definition of eventually consistency is that your
> computer system is running continously and DO NOT have a final state, and
> therefore you must be able to describe the behavior when your system either
> may give responses to queries across time that are either perfectly
Because there's no consensus on the contents of the mempool, this approach
is unsafe and will lead to forks. It also opens a new attack vector where
people can time the flood of new transactions with the discovery of a block
by a competitor, to orphan the block and to fork the chain.
The technical
>Even when several of the experts involved in the document you refer has my
respect and admiration, I do not agree with some of their conclusions
I'm one of the co-authors of that study. I'd be the first to agree with
your conclusion
and argue that the 4MB size suggested in that paper should not b
18 matches
Mail list logo
