Blockchain.info - Bitcoin Block explorer & Currency Statistics

[nmat]

I was checking your API and I noticed that you only have rawblock information until block 124620. This works: http://blockchain.info//rawblock/124620 and this doesn't: http://blockchain.info//rawblock/124621

124621 is an invalid block index (this is different from a block height)

I thought it was the height, but that wouldn't work. What exactly is the block index?

[1713286729]

1713286729

[piuk]

I thought it was the height, but that wouldn't work. What exactly is the block index?

Because I allow store orphaned blocks the block height cannot be used as a blocks primary key, instead I use a key called block index. If you can lookup by block index then please do as I cache by block index so lookups are faster, otherwise use

/block-height/$block_height?format=json

.

Added two new api calls:

/rawaddr - to get information about an address

/unspent - get the unspent outputs of one or multiple addresses.

Also regarding usage of this api, if you are displaying data on a public website then please a link back to blockchain.info. + I have a 200GB bandwidth limit so please go easy (or donate).

[piuk]

Announcing beta testing of blockchain.info's new e-wallet service.

http://blockchain.info/wallet

I believe this is the first e-wallet service to offer pure javascript transaction signing and wallet encryption/decryption. At no time do you share your private keys or password with our server. Your private keys are stored AES encrypted on servers so even if our database is compromised your wallet will still be secure.

• Live updating interface if your browser support websockets
• Send transactions with no fees
• Client side wallet decryption, no sharing of private keys
• Instant backups upon new key generation
• Export private keys
• Import private easy using a pywallet dump

This is early beta testing so do not expect everything to work perfectly and be sure you always keep a backup of your private keys on your own PC. I'm looking for feedback on browser compatibility and any errors that occur.

[netrin]

Looks great. Could you provide a sequence diagram? I'm looking for message types and payload between client and server...

Code:

===================================================
server

(stores encrypted wallet or seed)
===================================================
  |       |         ^
  |       |         |
(recv    (recv    (send
wallet   balance  trans
by id)   per)     through
  |      addrs)   server)
  |       |         |
  V       V         |
===================================================
client

(generates addresses locally)
===================================================

Are the wallets deterministic? Are newly generated keys (addresses) stored on the server (even in encrypted form)? Does the server keep track of all public addresses for each identifier? Can the client pull the network plug and continue working, sending transactions and updating balances later?

[MatthewLM]

I believe this is the first e-wallet service to offer pure javascript transaction signing and wallet encryption/decryption. At no time do you share your private keys or password with our server. Your private keys are stored AES encrypted on servers so even if our database is compromised your wallet will still be secure.

I had that idea a few days ago! 

[nmat]

So what's the difference between this and StrongCoin for example?

[piuk]

Are the wallets deterministic? Are newly generated keys (addresses) stored on the server (even in encrypted form)? Does the server keep track of all public addresses for each identifier? Can the client pull the network plug and continue working, sending transactions and updating balances later?

No the wallet is not deterministic, keys are generated randomly. The generated keys are stored AES encrypted on the server. The server does not know the public addresses of a user but does require the hash 160 of an address to get transaction data. These calls are made using the publicly available api @ http://blockchain.info/api. The wallet identifier and hash 160 is is not included in any queries together. Currently you can't send transactions offline because transaction data is lost if the client cannot reach the server, but it is possible with a few minor modifications.

The basic protocol structure is:

For new transactions

Server	Client
	Client Requests encrypted wallet data for an identifier
Sever responds with encrypted payload
	Client decrypts wallet in browser
	Client requests transaction data using methods at http://blockchain.info/api
	Client creates and signs transaction in the browser
	Client pushes transaction to http://blockchain.info/pushtx
Server relays transaction to mining nodes

Generating a new wallet

Server	Client
	Client generates identifier and private key
	Client encrypts a json payload of keys
	Client requests payload is stored on server with a provided identifier
Server stores encrypted payload

Here is the SQL structure for the wallet table

CREATE TABLE `bitcoin_wallets` (
  `guid` char(36) CHARACTER SET latin1 NOT NULL,
  `updated` bigint(20) unsigned NOT NULL DEFAULT '0',
  `created` bigint(20) unsigned NOT NULL DEFAULT '0',
  `payload` text NOT NULL,
  `last_access` bigint(20) unsigned NOT NULL,
  `shared_key` char(36) DEFAULT NULL,
  `notifications_email` varchar(255) NOT NULL,
  PRIMARY KEY (`guid`)
) ENGINE=ndbcluster DEFAULT CHARSET=utf8;

So what's the difference between this and StrongCoin for example?

I have to say I did not know about strongcoin, essentially it the same thing. I guess they now have some competition blockchain.info can be more tightly integrated the block explorer site so we can provide a slicker interface which feels like a fully functioning client.

[MatthewLM]

Why not have a ≈ character instead of ~ for the USD evaluation?

Do you use servers that you already own for other things? Do you plan to make money on this (not just donations), or is it just a hobby?

I would suggest changing the bottom bar so it does not merge with the background and become confusing.

[piuk]

Why not have a ≈ character instead of ~ for the USD evaluation?

Do you use servers that you already own for other things? Do you plan to make money on this (not just donations), or is it just a hobby?

I would suggest changing the bottom bar so it does not merge with the background and become confusing.

x ≈ y means x is approximately equal to y.

This may also be written ≃, ≅, ~ or ≒.

~ Iis the symbol I associate with approximation.

The site runs on 3 i7 Quad core Mac mini's which are collocated in a locked cabinet at a datacenter with a dedicated security guard. I am the only one with access to the servers but I do use them for other things - Backend's for a various iPhone applications, git, afp and email server. Just a hobby site for the moment, if it could pay for itself with advertising that would be great.

Thanks for the suggestion.

[netrin]

Thanks for your clarification. Does the client cycle through a pool of pre-generated addresses, or does it create a buffer of keys (I see only one pair in my wallet)? Are those guaranteed to be encrypted and stored on the server before they are ever used (I suspect not unless change is returned to the sending address)?

I would prefer that the client pre-generates and cycles through a small set of addresses, or that the addresses were generated from a seed (deterministic). I'd then feel much safer backing up my own keys locally. It would be very cool if you also replicated them to our own personal git repository (blockchain.info/git/GUID), so that we could clone the repo ourselves (I wish all cloud services allowed me to decrypt my data locally and stored encrypted data in git).

It is not clear to me what transaction data (API call) the client needs to request immediately before signing and sending a transaction back to the server.

I've never understood how transactions work. Why does the sending entity (your server in this case) need to join the network, with an up-to-date blockchain, before sending a transaction? Sure, he should ensure that the sending addresses actually contain a positive balance, but I'd think such failures should just be ignored (arguments about spam are silly, because NOTHING prevents bogus data transmission). Does a transaction need to inject itself into a specific block before it is validated - such as the hash of the previous block (if that were true then reorgs would be unnecessarily messy and require all senders to remain on the network for hours after sending)? (I know this is off topic, but I suspect you're in a great position to answer these nagging questions).

Do you have any future intension to implement deterministic addresses from seed?

I highly appreciate that you explode the wallet in plaintext JSON. Your project and many other alternate clients give me real hope for bitcoin's future! I look forward to transparent plaintext import/export/split/encrypted block standard formats between all clients. I'm curious why you store the private key in decimal - why not base58?

The server does not know the public addresses of a user but does require the hash 160 of an address to get transaction data.

What is the practical difference between the address and hash160? What is the hash160?

Suppose a user gave a single key pair to another user of your system. Would that expose the first user's entire wallet to the second? Could the first user remove the key pair from his wallet? Could he create a new wallet and mix and match key pairs from an older wallet.

CREATE TABLE `bitcoin_wallets` ( guid, updated, created, payload, last_access, shared_key, notifications_email )

Thanks for your inspiring transparency!

[piuk]

Thanks for your clarification. Does the client cycle through a pool of pre-generated addresses, or does it create a buffer of keys (I see only one pair in my wallet)? Are those guaranteed to be encrypted and stored on the server before they are ever used (I suspect not unless change is returned to the sending address)?

I've put up a technical FAQ with answers to some of your questions. http://blockchain.info/wallet/faq. Initially the client generates a single address only and change is returned to that address.

It is not clear to me what transaction data (API call) the client needs to request immediately before signing and sending a transaction back to the server.

The client calls

/unspent?address=HASH60

to get  a list of available unspent outputs otherwise the client would not know which outputs are spent or not.

Do you have any future intension to implement deterministic addresses from seed?

Possibly although I don't know if the average user can be trusted to keep a seed, wallet identifier and password safe. I'm trying to simplify the process a bit.

I've never understood how transactions work. Why does the sending entity (your server in this case) need to join the network, with an up-to-date blockchain.

It doesn't need an up to date blockchain, it doesn't need a blockchain at all. The javascript client cannot talk with bitcoin nodes directly so it has to go through the server. I could make a Java applet to relay the transaction without touching the server.

I look forward to transparent plaintext import/export/split/encrypted block standard formats between all clients. I'm curious why you store the private key in decimal - why not base58?

They are in base 58.

What is the practical difference between the address and hash160? What is the hash160?

No real difference, both can be determined from the other. I meant a difference between public key which cannot be determined from the hash.

Suppose a user gave a single key pair to another user of your system. Would that expose the first user's entire wallet to the second? Could the first user remove the key pair from his wallet? Could he create a new wallet and mix and match key pairs from an older wallet.

Do you mean sharing the private key? No, as wallets are not deterministic any other keys would be safe. If you meant wallet identifier then no also, as long as the password is not shared the second user can cannot decrypt the wallet.

[netrin]

Do you have any future intension to implement deterministic addresses from seed?

Possibly although I don't know if the average user can be trusted to keep a seed, wallet identifier and password safe. I'm trying to simplify the process a bit.

Currently you are storing an encrypted wallet containing keys. Instead you could store an encrypted wallet containing a seed. Or, as you suggest, trust the user to generate an excellent passphrase. The combination of an obscure GUID (URL) plus a good passphrase protecting the seed exposes exactly the same vulnerable characteristics as your current implementation. But the seed may reduce the memory footprint and can be more reliably backed up.

I've never understood how transactions work. Why does the sending entity (your server in this case) need to join the network, with an up-to-date blockchain.

It doesn't need an up to date blockchain, it doesn't need a blockchain at all.

I'm asking why your server (or my Satoshi client) needs to be on the network before sending. I'm sorry; it was an off topic question.

I'm curious why you store (export) the private key in decimal - why not base58?

Code:

{ "guid" : "xxxx-xxx-xxx-xxx-xxxx",
"sharedKey" : "xxxx-xxx-xxx-xxx-xxxx",
"keys" : [
{"addr" : "1AnAddressInBase58Format",
"priv" : "12345678901234567890987654321234567890987654323456789987654321234323456"}
]
}

[BitPay Business Solutions]

Awesome site!

can I make 1 suggestion?  On the main page, instead of saying "unconfirmed transactions" can you call them "new transactions" ?  the term unconfirmed (to a new user) may give the impression that they are somehow invalid.

[netrin]

Awesome site!

can I make 1 suggestion?  On the main page, instead of saying "unconfirmed transactions" can you call them "new transactions" ?  the term unconfirmed (to a new user) may give the impression that they are somehow invalid.

Hi Bit-pay. I hear ya, but maybe that's exactly the impression the new user should have, no? This transaction is not (yet) to be trusted.

[koin]

I've put up a technical FAQ with answers to some of your questions. http://blockchain.info/wallet/faq.

it is odd to go to a site named BlockChain.info for managing my hybrid javascript wallet.  and then this thread gets polluted with wallet-related topics.  wouldn't it be a better idea to separate the two?

the question i had though is what happens when i want to access from a different computer but don't have a link to the wallet url?  isn't there a way i can give an alias so that i don't need to keep the wallet identifier?

[piuk]

Awesome site!

can I make 1 suggestion?  On the main page, instead of saying "unconfirmed transactions" can you call them "new transactions" ?  the term unconfirmed (to a new user) may give the impression that they are somehow invalid.

Glad you like the site. They are not necessarily new though, I've seen some unconfirmed transactions sit in that list for 24 hours or more. I'll put a paragraph up on the page explaining what unconfirmed means.

it is odd to go to a site named BlockChain.info for managing my hybrid javascript wallet.  and then this thread gets polluted with wallet-related topics.  wouldn't it be a better idea to separate the two?

the question i had though is what happens when i want to access from a different computer but don't have a link to the wallet url?  isn't there a way i can give an alias so that i don't need to keep the wallet identifier?

I will be integrating the wallet into the site (nothing too intrusive). Fro example when you visit a address page you will be able to click 'Add to my Wallet' and have the address added in public key only mode. + I can't be bothered to setup a new domain  

Good idea, but people would likely pick aliases which are easy to guess e.g. 'my-wallet' which would then exposed your encrypted wallet data. What do you think about an alias with a security question something like simple like 'What is your date of birth?'.

New features added

• Save JSON data to file
• Save Wallet as printable PDF
• Import Encrypted JSON, PlainText JSON and pywallet -dumpwallet
• Multi recipient transaction.
• Address book
• Transaction summary and client status
• Confirmation before send

Coming shortly

• Public key only addresses
• Offline Transactions
• Upload and download wallet.dat (Java applet)

[terrytibbs]

What exactly is the "Other Known" on the pools chart?

[piuk]

What exactly is the "Other Known" on the pools chart?

All pools with less than 2 blocks relayed to avoid cluttering the pie chart. They are listed in the Known blocks table.

[terrytibbs]

What exactly is the "Other Known" on the pools chart?

All pools with less than 2 blocks relayed to avoid cluttering the pie chart. They are listed in the Known blocks table.

Ah! Makes sense, thanks.

[netrin]

Puik, I could foresee creating a wallet with a single address, adding some funds, printing it out as a pdf, and then I would like to be able to delete the record from your servers. Following that train of thought, your PDF could produce DIY PuiKash or, the analogy I prefer, traveller cheques. Writing the password on the cheque is equivalent to activating or signing it anonymously.

What is a multi-recipient transaction? First come, first serve?

Public key only address?

Looking forward to offline transactions and upload/download wallet.dat. Your innovations and implementations never cease to amaze!