Even if it was a really wallet to wallet transfer you can't go blocking them.  If you did then every future legitimate user of Bitcoin would have the onus on them to check the entire history of every coin received in the transaction to ensure their new coins aren't one of the stolen ones.  What if the same coin is transferred a hundred times through private transactions or OTC exchange then a couple of years later the newest owner goes to MtGox to cash it out?  Our new owner, 100 transactions removed from the theft, with no knowledge of the theft suddenly loses his bitcoins?

If I had to deal with that risk I know I'd be a lot more reluctant to accept bitcoins as payment.  Then you have the question of who decides that coin is in fact stolen?  Some independent body to arbitrate claims of theft and maintain a 'stolen coin' register?  As soon as you do that you break the P2P model.  Who will trust the arbitrator?  Who will believe the arbitrator actually knows 100% whether a theft occurred?  Couldn't you acheive a theft by registering some of you past coins as stolen in a false claim so they are grabbed back for you as soon as they pass through an exchange?

No, the solution is simple, people have to take responsibility for their own security.  If you keep you coins privately, secure your wallet properly.  If you pass them to an exchange to hold on your behalf then understand the risk involved, minimize as much as possible then accept that risk.  Sensible people already do this with fiat currency.  You don't leave you wallet on the dashboard of an unlocked car.  You give your money to some bloke on the street to hang on to for you, you put it in a bank which you know has decent security.  It's not a big leap from that ingrained culture to being conscious of digital security.

Wow, do these guys not get that this interview is one of the most critical PR exercises they'll ever face.  This is really not inspiring any confidence that they know what they're doing.  They supposed to be exchange operators for fucksake, they sound like a bunch of kids who don't know how to work their new toy.

No hadn't read it, woke up about a hour ago and there was a lot of threads to go through...

Hacker steals x thousand BTC.
Hacker tries to withdraw and hits limit $1k USD limit.
Hacker starts dumping BTC to crash price.
Number of bitcoins he can withdraw equivalent to under $1k USD increases dramatically.
Hacker withdraws all remaining BTC.

If the end result is a partial exodus from MtGox to other exchanges then it's a great thing.  Even MtGox acknowledged that having one monolithic exchange was not a good thing.

Doesn't really say on that page hence the question here.   It looks to me like V1 but it would nice for it to be explicitly stated.

Easy question, which JSON-RPC spec does bitcoin use?

thanks for link, that makes it a lot clearer so I can get to work now... The only part I'm not clear on is this:


Does this mean that the long poll itself should be dropped and reconnected every 60 seconds?  Or is it only talking about the main connection.

Also the long poll request is basically identical to a getwork request except for the different URL and lack of timeout?

I've searched a lot but not really found an explanation of what it is or how it works.

I'm keen to get to work on a java implementation of a pool server.  It sounds to me like it's some sort of persistent HTTP connection that allows the server to push a message back to the client sometime after the getwork response has been sent to inform them that the block is finished and they need to get some fresh work to do. Is that the basic idea?

If so is there any doco or spec for it so I can make sure my pool server implements it correctly?

I think you should read my first post again.  I said nothing of the sort, didn't even mention miners and no I'm not interested in solo mining or even pool mining for that matter.


When the proposed change allowing partial databases is implemented this won't be a problem.  On the other hand someone being able to walk into a coffee shop and buy a coffee with a 1 minute delay is vastly better than having to wait 10 mins.

In any case I wasn't actually arguing that the change should be made, I was asking if there was any technical reason why it was made that way in the first place that would preclude such a change being considered.

No I'm arguing that such a change would not benefit miners at all, it would benefit users and that is more important.  The only negative impact on miners would be a larger database size.  The larger blockchain for users is not an issue, it's already predicted to become a problem in the future and is dealt with via the plan for future client to only need part of the database.  The same would still apply.

Unless I misunderstad block = header + transactions + footer. Transactions would be 1/10th the size so it wouldn't be 10 times the files size but it would be more.

With respect I think your view of what bitcoin is for is a bit topsy turvy.  If bitcoin is to succeed it will driven 99.9% by users who have no interest in mining.  If we don't have those users there's nothing to give BTCs value and therefore no reason to mine.  So benefitting miners really isn't the point.  Benefiting users is.

doesn't really alter the proposition though, just divide the expected time and the expected reward by the same number.  If you divided by ten then for the miners it would have the same net effect as forming a pool with 10 identcal machines, but for the end users (who really drive bitcoin) it means 9 mins less delay to get a confirmation.

Hi,

Can I make a whilelist request.  I'm a java developer and I'm keen to get to work on a few things but I need to post questions in the technical forums.  The following post should show that I've actually read some doco:

https://forum.bitcoin.org/index.php?topic=17630.0

It seems to me the biggest barrier for BTC to overcome in terms of widespread adoption is POS.  And with a 10 minute delay for first confirmation this is problematic at best.  I know this problem can be solved with BTC banks or payment processors but it is still a pretty fundamental barrier.

So why is that a block is set to take 10 mins on average for a 50BTC reward?  Why not 1 minute and 5Btc or 30 sec and 2.5Btc?  I understand that as you approach 1 second network latency might start to have an impact so there is a practical limit to how short a block cycle can be but I still don't get why it has to be so long?

I've been looking around for a few days trying to understand the guts of bitcoin but between the wiki and the forum there seems to be a lot of gaps.  I'm wondering is some other part of the doco I'm missing or is it just a case of trawling the source code?


e.g. I've been trying to get a proper understanding of how getWork behaves.  Specifically I'm trying to work out if there's a way to get multiple getWorks in a single request.  The API reference on the wiki really just shows how to make a request and the getWork article is pretty thin on details.

Also been trying to figure out long polling.  As in enough info to work out how to make my own long polling request with my own code.  Can someone point me to a proper explanation of long polling?