Bitcoin Block Explorer

[theymos]

If you mean, how does one audit your addresses with block explorer, simply check the addresses that you have to make sure that there have been no transactions that you didn't do yourself and that the address balances add up to what you should have.  If you have more than what you should have, then the website is sharing accounts among users and tracking the individual values internally.  Which would allow the website owner to loan out portions of the pooled balance, much like how fractional reserve banks do now, since they don't actually keep your money on hand.  If there has been any transactions in or out of said accounts that you didn't perform, then that means the website owner is using member accounts to "float" his own activities.

Bitcoin shares balances among addresses, so you'd have to modify Bitcoin to achieve this separation.

[MoonShadow]

This is a generally awesome tool.  In addition to it's other uses, it will allow us to keep Mybitcoin.com and it's (presumedly less honest) future competitors from the temptation of fractional reserve nonsense.  Just the threat that any Joe can run his addresses past block explorer and tell if his funds have been mixed with other accounts not his own, or otherwise borrowed without consent, should be enough to keep most on the up-and-up.  Not that I don't have a fair trust of Mybitcoin.com, I do have an account that has been climbing in value as of late, but I also feel better knowing that I can check on my balances without having to trust the websites' honesty itself.

hmmm, has this ever been possible?

It seems like mybitcoin, bitcoinmarket, mtgox etc. all use a shared wallet to store deposits, and make withdrawals.  Accounts are kept straight through a separate accounting system.  Thus you cannot be guaranteed that your BTC deposit isn't immediately -- and legitimately -- withdrawn by someone else.

I imagine that there will be a push for separated accounts and/or wallets in future competitors of Mybitcoin.  Although I understand why they do it this way, I don't think that an online wallet management website should use a pooled system.  It's a bit different for the markets, as there is no implication that the wallet is your's.

[MoonShadow]

If you mean, how does one audit your addresses with block explorer, simply check the addresses that you have to make sure that there have been no transactions that you didn't do yourself and that the address balances add up to what you should have.  If you have more than what you should have, then the website is sharing accounts among users and tracking the individual values internally.  Which would allow the website owner to loan out portions of the pooled balance, much like how fractional reserve banks do now, since they don't actually keep your money on hand.  If there has been any transactions in or out of said accounts that you didn't perform, then that means the website owner is using member accounts to "float" his own activities.

Bitcoin shares balances among addresses, so you'd have to modify Bitcoin to achieve this separation.

I had made the assumption that they already had.  One client with one wallet.dat would be fine if the client was modified for multiple independent users, and sets of addresses were linked to a user and not assumed to be one person.  That's a very Windoze like mentality.  For that matter, there should be a GNU/Linux version that plays nice with multi-user systems, where the wallet.dat is in the user's disk space.

[davout]

Thanks theymos, this was much needed. I sent you some bitcoins for your efforts

Will you be releasing the source? Or maybe just giving access to your processed data in a nice format? I'd like to try to make some GraphViz charts (for example, being able to graph all transactions to/from a certain address given a maximum depth - that sort of thing).

Thanks!

I will not release the source unless there is a lot of demand for it. It is written specifically for BBE, and it would probably not be very useful for learning about Bitcoin or making similar things. For example, my getblock->SQL script does a bunch of unnecessary and redundant work in order to create database tables that can be efficiently accessed by BBE.

Here are the PHP base58/address functions that I wrote for this project, though:
http://pastebin.com/vmRQC7ha

I will offer data (maybe for a small fee). What format would be useful?

Hey theymos, jsut discovered your awesome tool.
If you feel like releasing the source, it'll be very appreciated =)

[Cdecker]

Thanks theymos, this is a great tool. I've been playing with the idea myself, but I'm happy you were faster :-)

[theymos]

There is now a version of BBE that runs on the test network:
http://theymos.ath.cx:64150/testnet/bbe/

[ByteCoin]

It's a very handy tool.

It would be good (for me at least) if there was a field in the "Block" view that gave the length of the block in bytes. It would be nice to have a size column which gives the transaction size in bytes and a priority column which shows the priority as calculated using the recently implemented formula.(Priority no sooo important to me at the moment though.)

On the "From" and "To" columns it would be nice to see the "balance" associated with that public key before the transaction so that a coinbase transaction would say for 91812
16va6NxJrMGe5d2LP6wUzuVnzBBoKQZKom:0 +50 = 50
and the other transaction would show as

777ed67c58... 0 1BFrS5LQSTY... : 1 -1 = 0 16QjxpGVX6EF... : 19 -19 = 0   1MCwBbhNGp5hR...: 411.9 +20 = 431.9

You can imagine that it's handy to have this info at block level without having to drill down to transaction or address level.

Also, it would be very interesting to have a list of unspent addresses and their balances. Obviously this total should add up to the currentblocknumber*50

If you wanted to be a hero you could work out how much space could be recovered from the block chain by removing spent transactions and stubbing the merkle tree down as much as possible. I suspect it wouldn't be much at the moment.

If you wanted a tougher task and be a real hero you could create a graph of bitcoin transactions with each address being a node and each transaction being a directed edge. You could display the thickness of the edges as being the number of transactions or the total value and see how many isolated graphs the transactions fall into.

The last two are harder more long term projects but the block page changes would be very handy for me in the short term.

Thanks theymos

ByteCoin
 

 

[theymos]

BBE and Real-Time Stats are now at a more easy-to-remember location:
http://blockexplorer.com/
http://blockexplorer.com/testnet/
http://blockexplorer.com/q/

All old links should redirect to the equivalent page at the new domain. Tell me if any links fail to do so.

[theymos]

And now HTTPS, too:
https://blockexplorer.com/

[TTBit]

A+

[theymos]

Data sizes are now shown for transactions and blocks.

[ByteCoin]

Data sizes are now shown for transactions and blocks.

Awesome, theymos! Thanks for that.

It'll be handy to see during the next spam flood.

ByteCoin

[theymos]

HTTPS access to http://blockexplorer.com/q and the rest of BBE will be offline for 2-5 days starting a few days from now. If anything uses the tools over HTTPS, change it ASAP or prepare to have your packets rejected for a few days.

(I'm making some hardware+software changes that require me to move BBE to a different computer temporarily, and I don't want to move the private key for security reasons.)

[theymos]

BBE now publishes RSS feeds for addresses. Your browser should be showing you an RSS option on all address pages. Should I include a human-readable link, too, you think?

This is useful for tracking your own transactions without having to run the client or log into your e-wallet. You can also get emailed about your transactions by using one of the many RSS-to-email providers.

The feed shows the last 20 received transactions, with the newest transactions first. Sends are not shown since they are mostly uncontrollable. The links all point to the address page right now -- eventually I will have them highlight the specific transaction on that page.

[theymos]

There are now Real-Time Stats tools for the testnet, too:
http://blockexplorer.com/testnet/q

Now is a good time to mention that testnet BBE will not automatically switch to a new chain if anyone attempts to replace the entire chain, but will stop updating until I switch it over manually. (This is to prevent mainline blocks from being lost in case an attacker finds a way to destroy all Bitcoin clients' block databases.)

[theymos]

I mentioned this a while ago on IRC, but hardly anyone seems to be using it:
http://blockexplorer.com/q/nethash/144

Possibly I need to explain the columns:
- blockNumber: Each row looks at a section of blocks (the section size is specified by the query parameter). This is the latest block included in the section. So the section includes data from the last row's blockNumber+1 up to this blockNumber. The first row looks back to block 1.
- time: Unix time at blockNumber.
- target: Full decimal target at blockNumber.
- difficulty: Difficulty at blockNumber.
- hashesToWin: Average number of hashes required to solve a block at blockNumber's difficulty.
- avgIntervalSinceLast: The average number of seconds between each block in the section.
- netHashPerSecond: Number of hashes the network is doing per second in this section. Calculated by comparing avgIntervalSinceLast to hashesToWin.

This data can be used to make a very nice graph of network power and difficulty.

[bitcool]

wow, that's a bitcoin data gold mine.

I know people here have put great faith on bitcoin's ability of preventing double-spending, or creating coins out of thin air, because that's one of the cornerstone of this currency and the foundation of bitcoin's value.

But as a paranoid person as I am, I feel much more comfortable if there's a way to independently count (or estimate) the total amount bitcoins in circulation, without relying on 50 btc x (# of blocks) calculation. -- i.e. can we look at all blocks, add up all the amount flowing into recipient addresses, then subtract whatever flows out of these addresses, and get the total amount of bitcoin in circulation?

This way, if there's some evil government or evil scientist finds a way bypassing the double-spending prevention mechanism, they will have to expose themselves via block chain data.

[theymos]

But as a paranoid person as I am, I feel much more comfortable if there's a way to independently count (or estimate) the total amount bitcoins in circulation, without relying on 50 btc x (# of blocks) calculation. -- i.e. can we look at all blocks, add up all the amount flowing into recipient addresses, then subtract whatever flows out of these addresses, and get the total amount of bitcoin in circulation?

It checks out on my database:

Code:

SELECT sum(outputs.value) FROM outputs LEFT JOIN inputs ON (outputs.tx=inputs.prev AND outputs.index=inputs.index) WHERE inputs IS NULL;
       sum
------------------
 5343100.00000000
(1 row)

My database updating script will refuse to accept a double-spend, though I doubt I will catch something that Bitcoin itself doesn't.

[bitcool]

Code:

SELECT sum(outputs.value) FROM outputs LEFT JOIN inputs ON (outputs.tx=inputs.prev AND outputs.index=inputs.index) WHERE inputs IS NULL;
       sum
------------------
 5343100.00000000
(1 row)

My database updating script will refuse to accept a double-spend, though I doubt I will catch something that Bitcoin itself doesn't.

Thanks. Looks this is what I've been looking for. I don't quite understand your table definition though. Does "WHERE inputs IS NULL" restrict result only to coin-generation transactions?

[theymos]

Thanks. Looks this is what I've been looking for. I don't quite understand your table definition though. Does "WHERE inputs IS NULL" restrict result only to coin-generation transactions?

It eliminates spent outputs. The total value of unspent outputs should equal the total BTC in circulation (as it does).

The LEFT JOIN matches each output with the input that spent it. If inputs IS NULL for a row, then the output is unspent.

I intend to release my getblock-to-SQL script at some point in the far future, since it allows easy access to stats like this. It's much too messy right now, though.