You are raising valid questions and one goal of our posting here is indeed to
discuss exactly these system issues.
On Thursday 07 August 2014 15:00:11 you wrote:
I think the description at your website leaves out the truly interesting
part: How do you decentralize this securely?
- How do
Since the information exchanged between the pool and the miner is
public, all that's needed is a mutual private MAC key that authenticates
messages.
This requires a registration step, that can be done only once using a
simple web interface over https to the miner website.
But the miner website is
Hi Tim,
It's clear from the paper that the second party in the protocol can
de-anonymize the first party. So it's seems that dishonest shufflers
would prefer to be in that position in the queue.
There are two possible solutions to this:
1. Derive the first order of parties in the shuffle from
On Thu, Aug 07, 2014 at 11:45:44PM +, Luke Dashjr wrote:
On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
Hi there,
I was wondering if you guys have come across this article:
http://www.wired.com/2014/08/isp-bitcoin-theft/
The TL;DR is that somebody is abusing the
On Fri, Aug 08, 2014 at 11:42:52AM +0200, Mike Hearn wrote:
AFAIK the only protection is SSL + certificate validation on client side.
However certificate revocation and updates in miners are pain in the ass,
that's why majority of pools (mine including) don't want to play with
that...
On Sat, Aug 9, 2014 at 6:10 AM, Sergio Lerner sergioler...@certimix.com
wrote:
Hi Tim,
It's clear from the paper that the second party in the protocol can
de-anonymize the first party. So it's seems that dishonest shufflers would
prefer to be in that position in the queue.
That's not
Does anyone see any concerns when it comes to security of the proposed
change?
Yes. This proposal is less secure.
It is incompatible in theory with existing implementations of the
specification. The incompatibility is also a potentially a security
problem because it may cause users to
Does bitcoin properly handle the case of a hash collision? no - because it is
considered too unlikely. The case of I_L = n is also astronomically unlikely,
so it's more a matter of improved performance and simpler data structures under
expected circumstances and taking that less than 1 in 2^127
8 matches
Mail list logo
