On Mon, Nov 4, 2013 at 8:39 PM, Peter Todd 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
"centeralized" things
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
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 th
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
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 02:12:44PM -0500, Ittay wrote:
> On Mon, Nov 4, 2013 at 10:25 AM, Ittay 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 alleviate you
On Mon, Nov 04, 2013 at 04:27:58PM +0100, Mike Hearn 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.
> >
>
> There's no stable way to know that. The whole purpose of the block chain to
> es
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 th
(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 wrote:
>
> > On Mon, Nov 04, 2013 at 10:25:19AM -0500, Ittay wrote:
> > > Peter - how can you guarantee that the majority mines
On Mon, Nov 4, 2013 at 3:58 AM, Michael Gronager 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
> chain. The paper si
On Mon, Nov 4, 2013 at 3:26 AM, Mike Hearn wrote:
> 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 and changing the
> rules for selecting th
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 su
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd 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
process here -
On Mon, Nov 04, 2013 at 09:49:09AM -0500, Ittay wrote:
> 1. Something important that is being overlooked is that the attack is
> relevant even without the sybil attack. Even if you assume the selfish
> miners loose every time on a 1:1 competition, they can still benefit in
> pools larger than 33%.
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
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd 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 do two things:
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 t
"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 t
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
>
> 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 could broadcast a newly discovered block at any
point and have a 50
On Mon, Nov 4, 2013 at 12:53 PM, Peter Todd 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 force.
>
They cou
On 4/11/13, 12:26 , 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.
The suggested change is actu
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 t
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 a
24 matches
Mail list logo
