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
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 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/4/13 11:38 AM, Mike Hearn wrote:
> > The Merkle branch doesn't get stored indefinitely thou
-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
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 wrote:
> No sense in compromising - you need a whole merkle path to prove the
> extra data is valid so you might as well make this a full 256
-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 d
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
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 t
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 Sun, Nov 03, 2013 at 09:39:42AM +0100, Thomas Voegtlin wrote:
>
> Le 03/11/2013 08:40, Timo Hanke a écrit :
> >I think the communication would have to go the other way around. Trezor
> >has to commit to a value First. Like this:
> >
> >Trezor picks random s and sends S=s*G to computer, keeping
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 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 th
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
Electrum version 1.9 is now released.
This version connects to multiple servers, and it also checks the SSL
certificates of servers it knows.
Please note that the BIP32 features are postponed (to version 2.0), due
to the discussions about mnemonic seed format.
Here is the changelog:
# Release
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
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
aren
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
35 matches
Mail list logo
