W.R.T. this paper and the oft-discussed miner backbone,
http://arxiv.org/pdf/1311.0243v1.pdf
I'm wondering about an alternative protocol change that perhaps has less
subtle implications than their suggested change. Rather than address the
problem by assuming the network is full of sybil nodes
On Mon, Nov 04, 2013 at 12:26:30PM +0100, Mike Hearn wrote:
W.R.T. this paper and the oft-discussed miner backbone,
http://arxiv.org/pdf/1311.0243v1.pdf
I'm wondering about an alternative protocol change that perhaps has less
subtle implications than their suggested change. Rather than
On Mon, Nov 4, 2013 at 12:53 PM, Peter Todd p...@petertodd.org wrote:
I proposed this as a means of giving a mechanism for wallets to get
non-sybilled peers as well.
Ah yes, good point.
Doing so encourages pools to only bother connecting to other pools,
which is a strong centralizing
On Mon, Nov 04, 2013 at 01:03:50PM +0100, Mike Hearn wrote:
The suggested change is actually very simple (minutes of coding) and
elegant and addresses precisely the identified problem.
Disagree. Unless I'm misunderstanding what they propose, their suggested
change would mean anyone
We propose a simple, backwards-compatible change to the Bitcoin
protocol to address this problem and raise the threshold. Specifically,
when a miner learns of competing branches of the same length, it should
propagate all of them, and choose which one to mine on uniformly at random.
So only in
On Mon, Nov 04, 2013 at 12:26:30PM +0100, Mike Hearn wrote:
W.R.T. this paper and the oft-discussed miner backbone,
http://arxiv.org/pdf/1311.0243v1.pdf
I'm wondering about an alternative protocol change that perhaps has less
subtle implications than their suggested change. Rather than
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd p...@petertodd.org wrote:
The correct, and rational, approach for a miner is to always mine to
extend the block that the majority of hashing power is trying to extend.
The current relay rules don't give you that information at all, but they
can if we
On Mon, Nov 04, 2013 at 03:34:35PM +0100, Pieter Wuille wrote:
Mining strategy is now to mine to extend the first block you see, on the
assumption that the earlier one probably propagated to a large portion
of the total hashing power. But as you receive near-blocks that are
under the PoW
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd p...@petertodd.org wrote:
The attacker now only needs to connect to every identified miner
with especially fast nodes. With judicious use of DoS attacks and low
latency .
So you're back to a complicated sybil attack. I don't follow your thought
On Mon, Nov 04, 2013 at 10:25:19AM -0500, Ittay wrote:
Peter - how can you guarantee that the majority mines on the non-selfish
block?
Feedback basically. So suppose the hashing power is split exactly 50:50,
with half the hashing power hearing about one block first, and half the
other. Also
On Mon, Nov 4, 2013 at 3:58 AM, Michael Gronager grona...@ceptacle.com wrote:
The suggested change is actually very simple (minutes of coding) and
elegant and addresses precisely the identified problem. It is actually a
mental shortcut in the assumption of how probability works when mining a
(not sure if you meant this to go to the list, my apologies if not)
On Mon, Nov 04, 2013 at 10:50:25AM -0500, Ittay wrote:
On Mon, Nov 4, 2013 at 10:46 AM, Peter Todd p...@petertodd.org wrote:
On Mon, Nov 04, 2013 at 10:25:19AM -0500, Ittay wrote:
Peter - how can you guarantee that the
On Mon, Nov 04, 2013 at 11:24:33AM -0500, Ittay wrote:
Yes - this is for the mailing list.
Regarding the algorithm - as we explain in the paper, as long as the
attacker is way ahead - the others can mine on whatever they like. Doesn't
really matter. Once they almost close the gap (and they
On Mon, Nov 04, 2013 at 02:12:44PM -0500, Ittay wrote:
On Mon, Nov 4, 2013 at 10:25 AM, Ittay ittay.e...@cornell.edu wrote:
As for the rational motivation of the individual miners - that's a good
point!
Here is a solution we did not put in the paper due to space constraints
that should
Sorry guys, I'm a little late to the party here. I skimmed over the
paper, and appreciated Peter Todd's recap of it. My first thought was
that this seems profit-neutral at best, when you take into account all
the races you lose by trying to beat the propagation of other miners'
blocks.
So given
On Mon, Nov 04, 2013 at 04:45:24PM -0500, Alan Reiner wrote:
So given the assumption that Alice is well-connected as Peter
mentioned, it seems like this is a concern. But is this a realistic
assumption? All miners have an incentive to be thoroughly connected to
one another, to make sure they
Mike Hearn wrote:
how about if we wrote code to automatically build a miner backbone
Yeah, let's build a backbone, or a cloud, and then we could have Google run it!
Come on, Mike, your conflict-of-interest as an employee is hanging out in the
open, flapping in the breeze here... Don't you
On Mon, Nov 04, 2013 at 08:14:37PM -0800, Gustaw Wieczorek wrote:
Mike Hearn wrote:
how about if we wrote code to automatically build a miner backbone
Yeah, let's build a backbone, or a cloud, and then we could have Google run
it!
Come on, Mike, your conflict-of-interest as an
On Mon, Nov 4, 2013 at 8:39 PM, Peter Todd p...@petertodd.org wrote:
I suggested the mechanism myself for slightly different reasons, and if
you know me, you'd know I'm the first to jump on anyone pushing
centralization.
Likewise, I did too and am also not very tolerant with trusted or
19 matches
Mail list logo
