So true.  Woz fit right in with the "early Apple".  Hackers building shit in their garage, trying to make something from nothing, and getting laughed at by most of the world in the process.  When Apple transformed into the trendy, hip, "cool kids Apple" Woz stuck out like a sore thumb.

Once they do I will resume donating to them.  At this point there are enough worthwhile charitable organizations which DO accept Bitcoins and I have a finite amount of resources I can give away that there is no reason to not direct it towards those organizations which intelligently cut credit cards out of the process and improve the efficiency of their process by 2% or so.

Um you should "notice" you get 1/1.27 revenue when difficulty increases 27% or difficulty increases x% you now earn 1/(1+x%) compared to prior to the increase.  Anything else is simply short term variance.  

http://www.reddit.com/r/Bitcoin/comments/1zz21j/mtgox_2014_hack_database_revealed_live_from_mark/

(oh and the dump is hosted on Mark's blog).

WARNING:  I haven't verified or scanned the files.  It is at least possible they contain malware including the bitcoin stealing kind.   BE SMART and take precautions when downloading unknown files from self described hackers.

On edit: the exe in the zip file a wallet stealer.  Don't run unless you have too many bitcoins and then it will solve that problem for you.

I winz one internets!  Don't feel bad if Danny was here he would have beat both of us.  The guy must either type 500 wpm or has a mind machine interface.

Regarding the extra nonce the early mining code always incremented the extra nonce until the application is restarted (in hindsight it would have been better to use a random number).  You can find this is the earliest copies of the bitcon software (which still had mining integrated in the client, you were always mining when the client was running). 

So all miners will show an incrementing extra nonce.  However the lower the particular hashrate of a given miner the less steep the slope. For example in the graph immediately above you will see that the red blocks between 400 and 450 were probably all from the same miner.  Even the utterly "random" blocks by unaligned solo miners are using incrementing nonces however if they have a very low hashrate and/or restarted frequently they would never operate long enough (measured in hashes) to find a block with a large extra nonce. 

It includes a checksum (just like addresses) to avoid importing incorrect key.  It also includes a compressed or uncompressed flag so the proper PubKeyHash can be computed.

https://en.bitcoin.it/wiki/Wallet_import_format

Had enough forsight to publish it under a burner email address but not enough forsight to realize that would be pointless if he used his real name?

Any progress on this.  Going to put it up on github? Curious to see the implementation.  While I don't like public eWallets I can see this being useful on a corporate intranet. 

Well to clarify bitcoind "core" works as expected.  IMHO the accounts functionality have always been next to worthless (there are other edge cases which can cause unexpected problems).   Most people wouldn't miss it if accounts were moved completely and it would avoid these kind of x-y questions.

That would be the worst possible solution.  bitcoind supports block and tx callback notifications.  At an application level you don't need to be concerned with the "balance at each address" (an abstraction which doesn't even exist at the protocol level) instead you only care about the balance per user.  When a tx comes in, determine which user it belongs to.



Once again who cares what the current balance of an individual address is, in a pool fund situation.  Joe has deposited 5 BTC, you owe Joe 5 BTC, Joe's "balance" is 5 BTC.  

Of course it changes on ever withdraw (and every transfer and ever deposit).

If a user has the following tx stored in the database
Deposit 10 BTC to deposit address x, tx id y
Withdraw 2 BTC to address x, tx id y
Transfer 1 BTC to user z

What is the user's current balance?

If those records were in a table couldn't you get the balance at any moment in time with a SELECT?


Then the issue isn't coding but architecture.    Forget Bitcoin a second.  Imagine you ran a USD based service.  Customers can deposit funds, customers can withdraw funds, customers can transfer funds to other customers accounts.  Are you telling me there is no possible way you could keep track of user balances without doing it all inside the banking system?   If the answer is no then replace bank/USD with bitcoind/BTC and that is your solution.  If the answer is yes, then please don't develop or launch a service without a lot more research.

Even if bitcoind did everything you wanted it to do it doesn't scale trying to use it as a real time balance data feed.  Use it as it was intended, as a interface to the bitcoin network.  You can then scale out if needed (multiple instances).

You don't have a PayPal account?  If you do just sell some coins using BitSimple and request withdraw to your PayPal account.   I don't know of any service which will make a purchase for you though.

Agreed.   It is just another attack vector but VPS are already swiss cheese when it comes to security.  They shouldn't be used for storing and processing irreversible money.


The answer should be no.  Anyone stupid enough to think otherwise WILL (it is a matter of when not if) lose bitcoins.

bitcoind for network connectivity and transaction processing.  With all high level functions in custom application and database.

If you had an application which needed to connect to the US banking network would you build it all inside your banks online banking interface?  Of course not.  You would build a high level application that issued commands and pulled data from your banks interface.

Don't use account.  Don't even plan on using accounts.  It is an uttterly worthless "feature" which has no place in bitcoind to begin with.

Bitcoind works flawlessly for its core functionality and that is running as a full node & wallet. "Account" level features should be in your application business logic and put in your application data store.

Yeah he called the cops on her, kept the door shut, and refused to come out and talk to her.  He waited for the cops to arrive  and then she decided to flit with him in front of the cops.   Maybe you just need to get laid because that is the most implausible scenario ever.  You sure you aren't confusing this with the start of some porn?

Well to Marks credit there is more than one anti-pattern in the code.   

Well actually he called the cops because a strange woman was at his door and wouldn't leave.  He only opened the door once the deputies arrived on the scene.  Doesn't sound like a friendly flirt and chat.

I still wonder if it was a miscommunication.  When she said Bitcoin he misheard her and thought she named a project he had worked on with the government.   In the AP interview he sometimes referred to Bitcoin as "BitCom".