On Mon, Oct 28, 2013 at 07:17:50AM +, John Dillon wrote:
This discussion seems to be a lot of hot air over a simple observation that
estimates are imperfect and always will be. I do not understand you vehement
opposition the notion that a backup is a good thing except in the context that
Might leak less wiggle room and be simpler/more robut to validate that
*everything* has to be the same except for the amount going to one (presumed
change) address. A privacy leak I know, but dont do that - ie send enough
change the first time. And network analysis has shown change addresses
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 04, 2013 at 12:10:38PM +0100, Adam Back wrote:
Might leak less wiggle room and be simpler/more robut to validate that
*everything* has to be the same except for the amount going to one (presumed
change) address. A privacy leak I know, but dont do that - ie send enough
change the
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 01:00:16PM +0100, Mike Hearn wrote:
Given that IP address data is inherently transient, perhaps a better
solution is to define a short hash in the coinbase that commits to extra
data that is relayed along with block data (e.g. appended to the block
message). It can then
On Mon, Nov 04, 2013 at 01:16:49PM -0500, Peter Todd wrote:
You'll want to put some reasonable limit on actual path lengths, just
pick something like 32 levels; if applications pick their UUIDs honestly
a collision will be very unlikely. You can also make the allowed paths
block specific by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 10:16 AM, Peter Todd wrote:
Again, the right way to do this is define the standard to use the
last txout so that midstate compression can be applied in the
future. We can re-use this for merge-mining and other commitments
easily by
I like the UUID-as-path idea. That resolves the problem of how to share the
alt-chain merkle tree quite nicely.
On Mon, Nov 4, 2013 at 7:16 PM, Peter Todd p...@petertodd.org wrote:
No sense in compromising - you need a whole merkle path to prove the
extra data is valid so you might as well
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 11:38 AM, Mike Hearn wrote:
The Merkle branch doesn't get stored indefinitely though, whereas
the coinbase hash does. The data stored in the coinbase [output]
can always just be the 256-bit root hash truncated to less.
I doubt the
Yes, sure. I was talking about the case of transiently relayed data, like
IP addresses.
On Mon, Nov 4, 2013 at 8:53 PM, Mark Friedenbach m...@monetize.io wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 11:38 AM, Mike Hearn wrote:
The Merkle branch doesn't get stored
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
28 matches
Mail list logo
