Topic: Experimental pre-0.8 builds for testing - page 2. (Read 19841 times)
I'm trying this client, downloaded it yesterday. I don't have precise data since i didn't run it continuosly but i can say that it was much much faster and much less heavy on hard disk. I started it without a blockchain and let it download from peers, yes i know, not optimal but it worked well. Memory usage is a bit high, it was at 600MB during the chain download, now it's at like 400 but it's fine
Tried again the low-end PC with the latest build:
Windows XP SP3
Pentium M, 1.6 GHz
760 MB RAM
wired LAN connection, bitcoin-qt.exe -connect=192.168.0.xxx -logtimestamps -benchmark
Took about nine hours. Here are the ~30-minute excerpts from debug.log:
Windows XP SP3
Pentium M, 1.6 GHz
760 MB RAM
wired LAN connection, bitcoin-qt.exe -connect=192.168.0.xxx -logtimestamps -benchmark
Took about nine hours. Here are the ~30-minute excerpts from debug.log:
Code:
2013-01-17 15:06:47 Bitcoin version v0.7.1-353-g3afefd8-beta (2013-01-14 23:38:10 +0100)
2013-01-17 15:11:49 received block 00000000e7abef25d5ec8934b2905dd82fe46b081e9381849744dadadc9198ed
2013-01-17 15:11:49 - Connect 1 transactions: 0.00ms (0.000ms/tx, 0.000ms/txin)
2013-01-17 15:11:49 - Verify 0 txins: 0.00ms (0.000ms/txin)
2013-01-17 15:11:49 - Connect: 0.00ms
2013-01-17 15:11:49 - Flush 1 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 15:11:49 SetBestChain: new best=00000000e7abef25d5ec8934b2905dd82fe46b081e9381849744dadadc9198ed height=3167 work=13606664014944 tx=3218 date=2009-02-05 23:49:49
2013-01-17 15:41:28 received block 00000000000c4510fb6b1a939a71297dd696ca9fc6fcf7668208c494eb00129a
2013-01-17 15:41:28 - Connect 2 transactions: 15.63ms (7.813ms/tx, 15.625ms/txin)
2013-01-17 15:41:28 - Verify 1 txins: 15.63ms (15.625ms/txin)
2013-01-17 15:41:28 - Connect: 15.63ms
2013-01-17 15:41:28 - Flush 3 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 15:41:28 SetBestChain: new best=00000000000c4510fb6b1a939a71297dd696ca9fc6fcf7668208c494eb00129a height=87531 work=63638573136918620 tx=134628 date=2010-10-25 19:56:28
2013-01-17 16:11:20 received block 000000000000011cd76a8313d18ea0cb4d789978fecd159a230243b51985f23d
2013-01-17 16:11:20 - Connect 8 transactions: 0.00ms (0.000ms/tx, 0.000ms/txin)
2013-01-17 16:11:20 - Verify 11 txins: 0.00ms (0.000ms/txin)
2013-01-17 16:11:20 - Connect: 0.00ms
2013-01-17 16:11:20 - Flush 19 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 16:11:20 SetBestChain: new best=000000000000011cd76a8313d18ea0cb4d789978fecd159a230243b51985f23d height=139885 work=71942799566013213550 tx=1224773 date=2011-08-06 20:08:02
2013-01-17 16:41:12 received block 000000000000019c4df1c73f4b605ce0dfac15419d5f7efc7f9e1417715c8399
2013-01-17 16:41:12 - Connect 72 transactions: 0.00ms (0.000ms/tx, 0.000ms/txin)
2013-01-17 16:41:12 - Verify 201 txins: 15.63ms (0.078ms/txin)
2013-01-17 16:41:12 - Connect: 15.63ms
2013-01-17 16:41:12 - Flush 249 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 16:41:12 SetBestChain: new best=000000000000019c4df1c73f4b605ce0dfac15419d5f7efc7f9e1417715c8399 height=171699 work=266924021998143281220 tx=2640821 date=2012-03-18 10:18:44
2013-01-17 17:11:16 received block 000000000000028079e07bdb0b0c63361880b3a5c85073dd98f9a9504b8d5502
2013-01-17 17:11:16 - Connect 125 transactions: 31.25ms (0.250ms/tx, 0.094ms/txin)
2013-01-17 17:11:16 - Verify 333 txins: 31.25ms (0.094ms/txin)
2013-01-17 17:11:16 - Connect: 31.25ms
2013-01-17 17:11:16 - Flush 428 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 17:11:16 SetBestChain: new best=000000000000028079e07bdb0b0c63361880b3a5c85073dd98f9a9504b8d5502 height=187070 work=372869096415509690028 tx=4617893 date=2012-07-01 18:23:34
2013-01-17 17:41:14 received block 000000000000012dfce2a5a790c707112d1a3d69cfc3a80d2c7ba6c05b26bd49
2013-01-17 17:41:14 - Connect 895 transactions: 46.88ms (0.052ms/tx, 0.029ms/txin)
2013-01-17 17:41:14 - Verify 1589 txins: 46.88ms (0.029ms/txin)
2013-01-17 17:41:14 - Connect: 93.75ms
2013-01-17 17:41:14 - Flush 1614 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 17:41:14 SetBestChain: new best=000000000000012dfce2a5a790c707112d1a3d69cfc3a80d2c7ba6c05b26bd49 height=197131 work=460455491179234775440 tx=6726284 date=2012-09-04 07:34:20
2013-01-17 18:11:22 received block 000000000000020c0c0f368e594a06dea40f96f157446aa60192fff00832b082
2013-01-17 18:11:22 - Connect 235 transactions: 15.63ms (0.066ms/tx, 0.032ms/txin)
2013-01-17 18:11:22 - Verify 483 txins: 15.63ms (0.032ms/txin)
2013-01-17 18:11:22 - Connect: 31.25ms
2013-01-17 18:11:22 - Flush 589 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 18:11:22 SetBestChain: new best=000000000000020c0c0f368e594a06dea40f96f157446aa60192fff00832b082 height=205740 work=567751994200247679652 tx=8445902 date=2012-10-30 17:44:32
2013-01-17 18:41:06 received block 0000000000000207549b461347cd2ecc9a7914ae8fe3fdcdaf4c446b5a8f614a
2013-01-17 18:41:08 Flushed 0 addresses to peers.dat 31ms
2013-01-17 18:41:11 - Connect 474 transactions: 4718.75ms (9.955ms/tx, 5.203ms/txin)
2013-01-17 18:41:11 - Verify 907 txins: 4734.38ms (5.220ms/txin)
2013-01-17 18:41:11 - Connect: 4812.50ms
2013-01-17 18:41:11 - Flush 1059 transactions: 31.25ms (0.0295ms/tx)
2013-01-17 18:41:11 SetBestChain: new best=0000000000000207549b461347cd2ecc9a7914ae8fe3fdcdaf4c446b5a8f614a height=210290 work=633247113574839609696 tx=9413266 date=2012-11-30 14:23:19
2013-01-17 19:11:13 stored orphan tx cb64431484 (mapsz 6651)
2013-01-17 19:11:13 stored orphan tx dbe05eeb5c (mapsz 6652)
2013-01-17 19:11:13 stored orphan tx 8142517fd0 (mapsz 6653)
2013-01-17 19:11:13 stored orphan tx 16d52d019b (mapsz 6654)
2013-01-17 19:11:13 stored orphan tx 29a97c4c21 (mapsz 6655)
2013-01-17 19:11:13 stored orphan tx 8f22d7d9d5 (mapsz 6656)
2013-01-17 19:11:13 stored orphan tx 20912b744d (mapsz 6657)
2013-01-17 19:11:13 stored orphan tx a3ee47ae13 (mapsz 6658)
2013-01-17 19:11:13 stored orphan tx a8face7aec (mapsz 6659)
2013-01-17 19:11:13 stored orphan tx feb5f21da3 (mapsz 6660)
2013-01-17 19:11:13 stored orphan tx 4aca3abc42 (mapsz 6661)
2013-01-17 19:11:13 stored orphan tx 8cf102225c (mapsz 6662)
2013-01-17 19:11:13 stored orphan tx 8e598df2a4 (mapsz 6663)
2013-01-17 19:11:13 received block 0000000000000445188b833eb4e60b5d8fc3208d0a331bc89aa49bde1c630845
2013-01-17 19:11:13 ProcessBlock: ORPHAN BLOCK, prev=000000000000030b3bbb839923eeeba29a5d6829197f987cff8656faafb5428e
2013-01-17 19:11:13 stored orphan tx 3835b37372 (mapsz 6664)
2013-01-17 19:11:13 stored orphan tx 766ce354cc (mapsz 6665)
2013-01-17 19:11:13 stored orphan tx e38a74d735 (mapsz 6666)
2013-01-17 19:11:13 stored orphan tx 7265314c2a (mapsz 6667)
2013-01-17 19:11:13 stored orphan tx 1736e7aa63 (mapsz 6668)
2013-01-17 19:11:13 stored orphan tx 6cf5bc2d0c (mapsz 6669)
2013-01-17 19:11:13 stored orphan tx 6be01d22eb (mapsz 6670)
2013-01-17 19:11:13 stored orphan tx 0f4365d217 (mapsz 6671)
2013-01-17 19:11:13 stored orphan tx 1035b2eab1 (mapsz 6672)
2013-01-17 19:11:13 stored orphan tx bcc75e6415 (mapsz 6673)
2013-01-17 19:11:13 stored orphan tx 813da0920d (mapsz 6674)
2013-01-17 19:11:13 stored orphan tx 04af77ad7b (mapsz 6675)
2013-01-17 19:11:13 stored orphan tx 8d617b9127 (mapsz 6676)
2013-01-17 19:11:13 stored orphan tx 32474c1e58 (mapsz 6677)
2013-01-17 19:11:13 stored orphan tx c1d541608f (mapsz 6678)
2013-01-17 19:11:13 stored orphan tx dff6e0e183 (mapsz 6679)
2013-01-17 19:11:13 stored orphan tx c1d10a3a6b (mapsz 6680)
2013-01-17 19:11:13 ignoring large orphan tx (size: 22939, hash: 6594192053)
2013-01-17 19:11:13 stored orphan tx fb8af03201 (mapsz 6681)
2013-01-17 19:11:13 stored orphan tx d38f4464f7 (mapsz 6682)
2013-01-17 19:11:13 stored orphan tx 4792a6d1a0 (mapsz 6683)
2013-01-17 19:11:13 stored orphan tx ce2261d632 (mapsz 6684)
2013-01-17 19:11:13 stored orphan tx 54cff21eb1 (mapsz 6685)
2013-01-17 19:11:13 stored orphan tx 2a4d40e5e8 (mapsz 6686)
2013-01-17 19:11:13 stored orphan tx 74b8b14f23 (mapsz 6687)
2013-01-17 19:11:13 stored orphan tx 8390becc3b (mapsz 6688)
2013-01-17 19:11:13 stored orphan tx 92e3eb4c6b (mapsz 6689)
2013-01-17 19:11:13 stored orphan tx 4aac75c43e (mapsz 6690)
2013-01-17 19:11:13 stored orphan tx 238d403d8e (mapsz 6691)
2013-01-17 19:11:13 stored orphan tx 8049d1c030 (mapsz 6692)
2013-01-17 19:11:13 stored orphan tx ece3251c33 (mapsz 6693)
2013-01-17 19:11:13 stored orphan tx 9a14344359 (mapsz 6694)
2013-01-17 19:11:13 stored orphan tx 2acebce64e (mapsz 6695)
2013-01-17 19:11:13 stored orphan tx 5910521432 (mapsz 6696)
2013-01-17 19:11:13 stored orphan tx a142371312 (mapsz 6697)
2013-01-17 19:11:13 stored orphan tx 548add4f5f (mapsz 6698)
2013-01-17 19:11:13 stored orphan tx 7205745479 (mapsz 6699)
2013-01-17 19:11:13 stored orphan tx 8742cbc03c (mapsz 6700)
2013-01-17 19:11:13 stored orphan tx 8e4ace9cd1 (mapsz 6701)
2013-01-17 19:11:13 stored orphan tx dadc82a737 (mapsz 6702)
2013-01-17 19:11:13 stored orphan tx efe3d28b89 (mapsz 6703)
2013-01-17 19:11:13 stored orphan tx b81ad7f532 (mapsz 6704)
2013-01-17 19:11:13 stored orphan tx 25aaad74e2 (mapsz 6705)
2013-01-17 19:11:13 stored orphan tx 3f68b27c6e (mapsz 6706)
2013-01-17 19:11:13 stored orphan tx 071901591f (mapsz 6707)
2013-01-17 19:11:13 stored orphan tx 00df69e4de (mapsz 6708)
2013-01-17 19:11:13 stored orphan tx efacbb1cae (mapsz 6709)
2013-01-17 19:11:13 stored orphan tx 2d351ba176 (mapsz 6710)
2013-01-17 19:11:13 stored orphan tx 04a39b3b50 (mapsz 6711)
2013-01-17 19:11:13 stored orphan tx cda3dc582a (mapsz 6712)
2013-01-17 19:11:13 stored orphan tx aabec9725d (mapsz 6713)
2013-01-17 19:11:13 stored orphan tx dbcf582abe (mapsz 6714)
2013-01-17 19:11:13 stored orphan tx 255fabe2b1 (mapsz 6715)
2013-01-17 19:11:13 stored orphan tx 6c9224d40c (mapsz 6716)
2013-01-17 19:11:13 stored orphan tx 56682ce367 (mapsz 6717)
2013-01-17 19:11:13 stored orphan tx e36502a3b8 (mapsz 6718)
2013-01-17 19:11:13 stored orphan tx 4ddf978e6d (mapsz 6719)
2013-01-17 19:11:13 stored orphan tx 2cffe8428e (mapsz 6720)
2013-01-17 19:11:13 stored orphan tx 949b140bf6 (mapsz 6721)
2013-01-17 19:11:13 stored orphan tx 78cc570ef5 (mapsz 6722)
2013-01-17 19:11:13 stored orphan tx 3137bc57b1 (mapsz 6723)
2013-01-17 19:11:13 stored orphan tx a9c8e03b1f (mapsz 6724)
2013-01-17 19:11:13 stored orphan tx c04eb9d4c4 (mapsz 6725)
2013-01-17 19:11:13 stored orphan tx 933309e35e (mapsz 6726)
2013-01-17 19:11:13 stored orphan tx 9f20af3983 (mapsz 6727)
2013-01-17 19:11:13 stored orphan tx bbdd648e36 (mapsz 6728)
2013-01-17 19:11:13 stored orphan tx 8d32171de6 (mapsz 6729)
2013-01-17 19:11:13 stored orphan tx f6986d503f (mapsz 6730)
2013-01-17 19:11:13 stored orphan tx 126bb4c1e2 (mapsz 6731)
2013-01-17 19:11:13 stored orphan tx f0d49cb01b (mapsz 6732)
2013-01-17 19:11:13 stored orphan tx 8d2935a5c0 (mapsz 6733)
2013-01-17 19:11:13 stored orphan tx f3c1bdb59f (mapsz 6734)
2013-01-17 19:11:13 stored orphan tx 9ef648b8f8 (mapsz 6735)
2013-01-17 19:11:13 stored orphan tx 007d124dbc (mapsz 6736)
2013-01-17 19:11:13 stored orphan tx 42c6861b51 (mapsz 6737)
2013-01-17 19:11:13 stored orphan tx 9232ad318f (mapsz 6738)
2013-01-17 19:11:13 stored orphan tx 528fe9faca (mapsz 6739)
2013-01-17 19:11:14 stored orphan tx d353033ebd (mapsz 6740)
2013-01-17 19:11:14 stored orphan tx d6ab1d1fda (mapsz 6741)
2013-01-17 19:11:14 stored orphan tx 0632ab2b9e (mapsz 6742)
2013-01-17 19:11:14 stored orphan tx 7e0a8b9a1c (mapsz 6743)
2013-01-17 19:11:14 stored orphan tx 6c27459121 (mapsz 6744)
2013-01-17 19:11:14 stored orphan tx 1ba74fa654 (mapsz 6745)
2013-01-17 19:11:14 stored orphan tx a7c4621072 (mapsz 6746)
2013-01-17 19:11:14 stored orphan tx 5d1802125a (mapsz 6747)
2013-01-17 19:11:14 stored orphan tx 1b25c094c4 (mapsz 6748)
2013-01-17 19:11:14 stored orphan tx 9413888e19 (mapsz 6749)
2013-01-17 19:11:14 stored orphan tx 07dfd16688 (mapsz 6750)
2013-01-17 19:11:14 stored orphan tx a9e7d5837b (mapsz 6751)
2013-01-17 19:11:14 stored orphan tx fec541bc86 (mapsz 6752)
2013-01-17 19:11:14 stored orphan tx 656a13b7f4 (mapsz 6753)
2013-01-17 19:11:14 stored orphan tx cac559109f (mapsz 6754)
2013-01-17 19:11:14 stored orphan tx cc2fcdc279 (mapsz 6755)
2013-01-17 19:11:14 stored orphan tx 95540cc272 (mapsz 6756)
2013-01-17 19:11:14 stored orphan tx c4a2f1360a (mapsz 6757)
2013-01-17 19:11:14 stored orphan tx a07243d00b (mapsz 6758)
2013-01-17 19:11:14 stored orphan tx 06de72f3fd (mapsz 6759)
2013-01-17 19:11:14 stored orphan tx 17071efeeb (mapsz 6760)
2013-01-17 19:11:14 stored orphan tx edb5625970 (mapsz 6761)
2013-01-17 19:11:14 stored orphan tx 739684907c (mapsz 6762)
2013-01-17 19:11:14 stored orphan tx ace2db864d (mapsz 6763)
2013-01-17 19:11:14 stored orphan tx 6294e525c2 (mapsz 6764)
2013-01-17 19:11:14 stored orphan tx 6285ea2d47 (mapsz 6765)
2013-01-17 19:11:14 stored orphan tx f37686c3b3 (mapsz 6766)
2013-01-17 19:11:14 stored orphan tx 5c3d13090e (mapsz 6767)
2013-01-17 19:11:14 stored orphan tx 478962b79c (mapsz 6768)
2013-01-17 19:11:14 stored orphan tx c945fed0a4 (mapsz 6769)
2013-01-17 19:11:14 stored orphan tx 7efdad7d1b (mapsz 6770)
2013-01-17 19:11:14 stored orphan tx 22ff4f6053 (mapsz 6771)
2013-01-17 19:11:14 stored orphan tx 25610d6188 (mapsz 6772)
2013-01-17 19:11:14 stored orphan tx e034527d36 (mapsz 6773)
2013-01-17 19:11:14 stored orphan tx 237913aa81 (mapsz 6774)
2013-01-17 19:11:14 stored orphan tx 18c2c27902 (mapsz 6775)
2013-01-17 19:11:14 stored orphan tx 2aff86856e (mapsz 6776)
2013-01-17 19:11:14 stored orphan tx f8b2b48408 (mapsz 6777)
2013-01-17 19:11:14 stored orphan tx bedc1acc6d (mapsz 6778)
2013-01-17 19:11:14 stored orphan tx dad1eaf115 (mapsz 6779)
2013-01-17 19:11:14 stored orphan tx 2698ae7d11 (mapsz 6780)
2013-01-17 19:11:14 stored orphan tx c3a1b465a1 (mapsz 6781)
2013-01-17 19:11:14 stored orphan tx 55747cdc42 (mapsz 6782)
2013-01-17 19:11:14 stored orphan tx e2aa1f0d7c (mapsz 6783)
2013-01-17 19:11:14 stored orphan tx 562cc53ce7 (mapsz 6784)
2013-01-17 19:11:14 stored orphan tx 4f21ffff73 (mapsz 6785)
2013-01-17 19:11:14 stored orphan tx 0a6e41e249 (mapsz 6786)
2013-01-17 19:11:14 stored orphan tx ad31135373 (mapsz 6787)
2013-01-17 19:11:14 stored orphan tx e205a2b53e (mapsz 6788)
2013-01-17 19:11:14 stored orphan tx ebf088bd22 (mapsz 6789)
2013-01-17 19:11:14 stored orphan tx b9fa0b1dab (mapsz 6790)
2013-01-17 19:11:14 stored orphan tx 162eb9903c (mapsz 6791)
2013-01-17 19:11:14 stored orphan tx 04fc5662c4 (mapsz 6792)
2013-01-17 19:11:14 stored orphan tx 541453b4da (mapsz 6793)
2013-01-17 19:11:14 stored orphan tx 140ce2bc9c (mapsz 6794)
2013-01-17 19:11:14 stored orphan tx 4d374ab52e (mapsz 6795)
2013-01-17 19:11:14 stored orphan tx 00b8a9ba57 (mapsz 6796)
2013-01-17 19:11:14 stored orphan tx 90320c1a22 (mapsz 6797)
2013-01-17 19:11:14 stored orphan tx e3bd01c04e (mapsz 6798)
2013-01-17 19:11:14 stored orphan tx 68a1bd51aa (mapsz 6799)
2013-01-17 19:11:14 stored orphan tx 058395fb06 (mapsz 6800)
2013-01-17 19:11:14 stored orphan tx 6a05543d2a (mapsz 6801)
2013-01-17 19:11:14 stored orphan tx f2aea276dc (mapsz 6802)
2013-01-17 19:11:14 stored orphan tx 2e7cb28a09 (mapsz 6803)
2013-01-17 19:11:14 stored orphan tx 6a198e4d08 (mapsz 6804)
2013-01-17 19:11:14 stored orphan tx fe2b0632be (mapsz 6805)
2013-01-17 19:11:14 stored orphan tx 114f1f182d (mapsz 6806)
2013-01-17 19:11:14 stored orphan tx 9e7bb7f8a0 (mapsz 6807)
2013-01-17 19:11:14 stored orphan tx 7b5e015b30 (mapsz 6808)
2013-01-17 19:11:14 stored orphan tx 53788344b0 (mapsz 6809)
2013-01-17 19:11:14 stored orphan tx 9413539cfe (mapsz 6810)
2013-01-17 19:11:14 stored orphan tx e699aae309 (mapsz 6811)
2013-01-17 19:11:14 stored orphan tx a4d0852f4a (mapsz 6812)
2013-01-17 19:11:14 stored orphan tx 26ab251649 (mapsz 6813)
2013-01-17 19:11:14 stored orphan tx 26d3ac4c25 (mapsz 6814)
2013-01-17 19:11:14 stored orphan tx 492a633709 (mapsz 6815)
2013-01-17 19:11:14 stored orphan tx fc89b4b582 (mapsz 6816)
2013-01-17 19:11:14 stored orphan tx 0d00cd9dca (mapsz 6817)
2013-01-17 19:11:14 stored orphan tx af8f8e8283 (mapsz 6818)
2013-01-17 19:11:14 stored orphan tx b42f205817 (mapsz 6819)
2013-01-17 19:11:14 stored orphan tx 25066606dc (mapsz 6820)
2013-01-17 19:11:14 stored orphan tx c2aaf2cd73 (mapsz 6821)
2013-01-17 19:11:14 stored orphan tx da7f9d74cd (mapsz 6822)
2013-01-17 19:11:14 stored orphan tx 347761e8f3 (mapsz 6823)
2013-01-17 19:11:14 stored orphan tx 57dd36dab2 (mapsz 6824)
2013-01-17 19:11:14 stored orphan tx fac81dc5f3 (mapsz 6825)
2013-01-17 19:11:14 stored orphan tx 4239ea707b (mapsz 6826)
2013-01-17 19:11:14 stored orphan tx 63f7d5bbb7 (mapsz 6827)
2013-01-17 19:11:14 stored orphan tx c05c088888 (mapsz 6828)
2013-01-17 19:11:14 stored orphan tx 664742bcac (mapsz 6829)
2013-01-17 19:11:14 stored orphan tx 574b46588d (mapsz 6830)
2013-01-17 19:11:14 stored orphan tx bf60134e61 (mapsz 6831)
2013-01-17 19:11:14 stored orphan tx 951fa4b45b (mapsz 6832)
2013-01-17 19:11:14 stored orphan tx 944b10d9c0 (mapsz 6833)
2013-01-17 19:11:14 stored orphan tx 2a93736091 (mapsz 6834)
2013-01-17 19:11:14 stored orphan tx cfa5a8be10 (mapsz 6835)
2013-01-17 19:11:14 stored orphan tx 363c280e9a (mapsz 6836)
2013-01-17 19:11:14 stored orphan tx f03dc7baca (mapsz 6837)
2013-01-17 19:11:14 stored orphan tx 8e53474d7c (mapsz 6838)
2013-01-17 19:11:14 stored orphan tx 90b8c677ce (mapsz 6839)
2013-01-17 19:11:14 stored orphan tx c4f25d20dd (mapsz 6840)
2013-01-17 19:11:14 stored orphan tx 6598309734 (mapsz 6841)
2013-01-17 19:11:14 stored orphan tx 1fdd27ef36 (mapsz 6842)
2013-01-17 19:11:14 stored orphan tx 2b1cdae560 (mapsz 6843)
2013-01-17 19:11:14 stored orphan tx 505f238918 (mapsz 6844)
2013-01-17 19:11:14 stored orphan tx 4c9e0855f2 (mapsz 6845)
2013-01-17 19:11:14 stored orphan tx 3dc378f82a (mapsz 6846)
2013-01-17 19:11:14 stored orphan tx b1a6f2baca (mapsz 6847)
2013-01-17 19:11:14 stored orphan tx b9ad95a382 (mapsz 6848)
2013-01-17 19:11:14 stored orphan tx 272e167d28 (mapsz 6849)
2013-01-17 19:11:14 stored orphan tx 9f0c7e1b08 (mapsz 6850)
2013-01-17 19:11:14 stored orphan tx fff092fa24 (mapsz 6851)
2013-01-17 19:11:14 stored orphan tx 9e1e9e5c1b (mapsz 6852)
2013-01-17 19:11:14 stored orphan tx 9b70735d1e (mapsz 6853)
2013-01-17 19:11:14 stored orphan tx d5db3510c4 (mapsz 6854)
2013-01-17 19:11:14 stored orphan tx 8e0e991080 (mapsz 6855)
2013-01-17 19:11:14 stored orphan tx a2d875f9e4 (mapsz 6856)
2013-01-17 19:11:14 stored orphan tx bd101dd32e (mapsz 6857)
2013-01-17 19:11:14 stored orphan tx 81874f8941 (mapsz 6858)
2013-01-17 19:11:14 stored orphan tx 7e4650a505 (mapsz 6859)
2013-01-17 19:11:14 stored orphan tx a17bd2e7ba (mapsz 6860)
2013-01-17 19:11:14 stored orphan tx e361cf3326 (mapsz 6861)
2013-01-17 19:11:14 stored orphan tx ba0cbb7f5e (mapsz 6862)
2013-01-17 19:11:14 stored orphan tx 415cb3e562 (mapsz 6863)
2013-01-17 19:11:14 stored orphan tx 85dfe35278 (mapsz 6864)
2013-01-17 19:11:14 stored orphan tx b8c010414b (mapsz 6865)
2013-01-17 19:11:14 stored orphan tx 743868edb1 (mapsz 6866)
2013-01-17 19:11:14 stored orphan tx d1e8a8d48f (mapsz 6867)
2013-01-17 19:11:14 stored orphan tx f118682f3c (mapsz 6868)
2013-01-17 19:11:14 stored orphan tx 277ac09d9b (mapsz 6869)
2013-01-17 19:11:14 stored orphan tx aa236ce04e (mapsz 6870)
2013-01-17 19:11:14 stored orphan tx 4e3fbbb5d3 (mapsz 6871)
2013-01-17 19:11:14 stored orphan tx 7b4c19a0df (mapsz 6872)
2013-01-17 19:11:14 stored orphan tx 458cf9b822 (mapsz 6873)
2013-01-17 19:11:14 stored orphan tx 5091b925ab (mapsz 6874)
2013-01-17 19:11:14 stored orphan tx 014dd3d28e (mapsz 6875)
2013-01-17 19:11:14 stored orphan tx 709c2c5101 (mapsz 6876)
2013-01-17 19:11:14 stored orphan tx 117973679a (mapsz 6877)
2013-01-17 19:11:14 stored orphan tx 7d29213af9 (mapsz 6878)
2013-01-17 19:11:14 stored orphan tx e7ee35e620 (mapsz 6879)
2013-01-17 19:11:14 stored orphan tx 8742e2e7d5 (mapsz 6880)
2013-01-17 19:11:14 stored orphan tx 300f6e157d (mapsz 6881)
2013-01-17 19:11:14 stored orphan tx d5ab77db82 (mapsz 6882)
2013-01-17 19:11:14 stored orphan tx 975c315669 (mapsz 6883)
2013-01-17 19:11:14 ignoring large orphan tx (size: 5655, hash: 68c41a6236)
2013-01-17 19:11:14 stored orphan tx 3759e2e9b4 (mapsz 6884)
2013-01-17 19:11:14 stored orphan tx b8a4baf345 (mapsz 6885)
2013-01-17 19:11:14 stored orphan tx 7ee56951fe (mapsz 6886)
2013-01-17 19:11:14 stored orphan tx bc7a172398 (mapsz 6887)
2013-01-17 19:11:14 stored orphan tx a3760b9c71 (mapsz 6888)
2013-01-17 19:11:14 stored orphan tx c89e140390 (mapsz 6889)
2013-01-17 19:11:14 stored orphan tx 22d4318254 (mapsz 6890)
2013-01-17 19:11:14 stored orphan tx b25d04f60f (mapsz 6891)
2013-01-17 19:11:14 stored orphan tx 16da08e263 (mapsz 6892)
2013-01-17 19:11:14 stored orphan tx f105ce02a6 (mapsz 6893)
2013-01-17 19:11:14 stored orphan tx e3477507ae (mapsz 6894)
2013-01-17 19:11:14 stored orphan tx c12ff833a1 (mapsz 6895)
2013-01-17 19:11:14 stored orphan tx 68a566b247 (mapsz 6896)
2013-01-17 19:11:14 stored orphan tx c35a2c21ea (mapsz 6897)
2013-01-17 19:11:14 stored orphan tx 35301f1b1f (mapsz 6898)
2013-01-17 19:11:14 stored orphan tx 0659d1e214 (mapsz 6899)
2013-01-17 19:11:14 stored orphan tx b75ecf5743 (mapsz 6900)
2013-01-17 19:11:14 stored orphan tx 88f55e7ee0 (mapsz 6901)
2013-01-17 19:11:14 stored orphan tx ba5f856b95 (mapsz 6902)
2013-01-17 19:11:14 stored orphan tx c52afaadd0 (mapsz 6903)
2013-01-17 19:11:14 stored orphan tx 8a4de513c3 (mapsz 6904)
2013-01-17 19:11:14 stored orphan tx b0a8b19abe (mapsz 6905)
2013-01-17 19:11:14 stored orphan tx 2fcc717993 (mapsz 6906)
2013-01-17 19:11:14 stored orphan tx d0fddd56ff (mapsz 6907)
2013-01-17 19:11:14 stored orphan tx 05d92120a7 (mapsz 6908)
2013-01-17 19:11:14 stored orphan tx 237c407f66 (mapsz 6909)
2013-01-17 19:11:14 stored orphan tx 72a97bc53b (mapsz 6910)
2013-01-17 19:11:14 stored orphan tx 0cef07bed5 (mapsz 6911)
2013-01-17 19:11:14 stored orphan tx 051720748d (mapsz 6912)
2013-01-17 19:11:14 stored orphan tx f9c89c04e1 (mapsz 6913)
2013-01-17 19:11:14 stored orphan tx deadcf5a07 (mapsz 6914)
2013-01-17 19:11:14 stored orphan tx e2581ae24d (mapsz 6915)
2013-01-17 19:11:14 stored orphan tx 6da43516b6 (mapsz 6916)
2013-01-17 19:11:14 stored orphan tx 3735a8c1d0 (mapsz 6917)
2013-01-17 19:11:14 stored orphan tx 5c23b392ed (mapsz 6918)
2013-01-17 19:11:14 stored orphan tx 22d11b3a8a (mapsz 6919)
2013-01-17 19:11:14 stored orphan tx 8c891489fa (mapsz 6920)
2013-01-17 19:11:14 stored orphan tx 0884e0c8ec (mapsz 6921)
2013-01-17 19:11:14 stored orphan tx 58d7079ffb (mapsz 6922)
2013-01-17 19:11:14 stored orphan tx 15e42cdc13 (mapsz 6923)
2013-01-17 19:11:14 stored orphan tx a537dd40e3 (mapsz 6924)
2013-01-17 19:11:14 stored orphan tx e0a698a1d0 (mapsz 6925)
2013-01-17 19:11:14 stored orphan tx 0133b1bd17 (mapsz 6926)
2013-01-17 19:11:14 stored orphan tx 2d06c3d32d (mapsz 6927)
2013-01-17 19:11:14 stored orphan tx 7a2e50533e (mapsz 6928)
2013-01-17 19:11:14 stored orphan tx 9be23b74b0 (mapsz 6929)
2013-01-17 19:11:14 stored orphan tx 8bca7f5365 (mapsz 6930)
2013-01-17 19:11:14 stored orphan tx cc0c0c9f00 (mapsz 6931)
2013-01-17 19:11:14 stored orphan tx 052c421cdd (mapsz 6932)
2013-01-17 19:11:14 stored orphan tx aba6d8a178 (mapsz 6933)
2013-01-17 19:11:14 stored orphan tx 50b9e660ec (mapsz 6934)
2013-01-17 19:11:14 stored orphan tx 1a798bef1e (mapsz 6935)
2013-01-17 19:11:14 stored orphan tx 046304310c (mapsz 6936)
2013-01-17 19:11:14 stored orphan tx 4c6730a698 (mapsz 6937)
2013-01-17 19:11:14 stored orphan tx 7d2a00fb04 (mapsz 6938)
2013-01-17 19:11:14 stored orphan tx 69b70083a1 (mapsz 6939)
2013-01-17 19:11:14 stored orphan tx 2d01933ca9 (mapsz 6940)
2013-01-17 19:11:14 stored orphan tx 64681a3fbb (mapsz 6941)
2013-01-17 19:11:14 stored orphan tx 1864ff886d (mapsz 6942)
2013-01-17 19:11:14 stored orphan tx 5fd5da2aff (mapsz 6943)
2013-01-17 19:11:14 stored orphan tx 3fbd71925d (mapsz 6944)
2013-01-17 19:11:14 stored orphan tx cf4503487d (mapsz 6945)
2013-01-17 19:11:14 stored orphan tx 1080a2c6c7 (mapsz 6946)
2013-01-17 19:11:14 stored orphan tx 0deda6869e (mapsz 6947)
2013-01-17 19:11:14 stored orphan tx 3f66f843a7 (mapsz 6948)
2013-01-17 19:11:14 stored orphan tx 6b27c3c048 (mapsz 6949)
2013-01-17 19:11:14 stored orphan tx 546466e7e3 (mapsz 6950)
2013-01-17 19:11:14 stored orphan tx defb1d34b9 (mapsz 6951)
2013-01-17 19:11:14 stored orphan tx 757f5aea10 (mapsz 6952)
2013-01-17 19:11:14 stored orphan tx 968bd36c84 (mapsz 6953)
2013-01-17 19:11:14 stored orphan tx b3e9d87ba3 (mapsz 6954)
2013-01-17 19:11:14 stored orphan tx 8eb9c03bed (mapsz 6955)
2013-01-17 19:11:14 stored orphan tx 19015ae83b (mapsz 6956)
2013-01-17 19:11:14 stored orphan tx 82c93d2472 (mapsz 6957)
2013-01-17 19:11:14 stored orphan tx b941d6a3a7 (mapsz 6958)
2013-01-17 19:11:14 stored orphan tx 7914423717 (mapsz 6959)
2013-01-17 19:11:14 stored orphan tx 3f6a4764fa (mapsz 6960)
2013-01-17 19:11:14 stored orphan tx 339e8b88d5 (mapsz 6961)
2013-01-17 19:11:14 stored orphan tx 0fe7744628 (mapsz 6962)
2013-01-17 19:11:14 stored orphan tx 074b3b3b8d (mapsz 6963)
2013-01-17 19:11:14 stored orphan tx bbe915d145 (mapsz 6964)
2013-01-17 19:11:14 stored orphan tx 102c2719cb (mapsz 6965)
2013-01-17 19:11:14 stored orphan tx d46db40c77 (mapsz 6966)
2013-01-17 19:11:14 stored orphan tx 0d4210eb05 (mapsz 6967)
2013-01-17 19:11:14 stored orphan tx 59069473ab (mapsz 6968)
2013-01-17 19:11:14 stored orphan tx c4ebbf00ca (mapsz 6969)
2013-01-17 19:11:14 stored orphan tx c34a5686bb (mapsz 6970)
2013-01-17 19:11:14 stored orphan tx e70dc1396c (mapsz 6971)
2013-01-17 19:11:14 stored orphan tx 9d869bcbd7 (mapsz 6972)
2013-01-17 19:11:14 stored orphan tx 2646775a11 (mapsz 6973)
2013-01-17 19:11:14 stored orphan tx d32936a6e0 (mapsz 6974)
2013-01-17 19:11:14 stored orphan tx a617fbbe30 (mapsz 6975)
2013-01-17 19:11:14 stored orphan tx 3c248615db (mapsz 6976)
2013-01-17 19:11:14 stored orphan tx ef3f238442 (mapsz 6977)
2013-01-17 19:11:14 stored orphan tx 45e64430fc (mapsz 6978)
2013-01-17 19:11:14 stored orphan tx d677b7fdc7 (mapsz 6979)
2013-01-17 19:11:14 stored orphan tx 5e9fbdcd89 (mapsz 6980)
2013-01-17 19:11:14 stored orphan tx 489a94f663 (mapsz 6981)
2013-01-17 19:11:14 stored orphan tx 834a0a6f4b (mapsz 6982)
2013-01-17 19:11:14 stored orphan tx 50c54d1c07 (mapsz 6983)
2013-01-17 19:11:14 stored orphan tx f778538244 (mapsz 6984)
2013-01-17 19:11:14 stored orphan tx 39aea73f6c (mapsz 6985)
2013-01-17 19:11:14 stored orphan tx 92c62357bf (mapsz 6986)
2013-01-17 19:11:14 stored orphan tx e6a0e4f466 (mapsz 6987)
2013-01-17 19:11:14 stored orphan tx 8be8302046 (mapsz 6988)
2013-01-17 19:11:14 stored orphan tx f56409c527 (mapsz 6989)
2013-01-17 19:11:14 stored orphan tx 5dff97e666 (mapsz 6990)
2013-01-17 19:11:14 stored orphan tx d64dfb2ce7 (mapsz 6991)
2013-01-17 19:11:14 stored orphan tx 9d82172227 (mapsz 6992)
2013-01-17 19:11:14 stored orphan tx a8618d9774 (mapsz 6993)
2013-01-17 19:11:14 stored orphan tx 5c3ed6f253 (mapsz 6994)
2013-01-17 19:11:14 stored orphan tx df7583cda0 (mapsz 6995)
2013-01-17 19:11:14 stored orphan tx 1f7629a7aa (mapsz 6996)
2013-01-17 19:11:14 stored orphan tx 0fe4878081 (mapsz 6997)
2013-01-17 19:11:14 stored orphan tx 5280c5615c (mapsz 6998)
2013-01-17 19:11:14 stored orphan tx 87dc82c148 (mapsz 6999)
2013-01-17 19:11:14 stored orphan tx 33e8e2a2d6 (mapsz 7000)
2013-01-17 19:11:14 stored orphan tx 8f7d0eb5f1 (mapsz 7001)
2013-01-17 19:11:14 stored orphan tx f665284414 (mapsz 7002)
2013-01-17 19:11:14 stored orphan tx 9c4aa38be9 (mapsz 7003)
2013-01-17 19:11:14 stored orphan tx 5e1426ea17 (mapsz 7004)
2013-01-17 19:11:14 stored orphan tx 46e6b25cfb (mapsz 7005)
2013-01-17 19:11:14 stored orphan tx 056ec4bbf7 (mapsz 7006)
2013-01-17 19:11:14 stored orphan tx 179d04cfa3 (mapsz 7007)
2013-01-17 19:11:14 stored orphan tx 2685005c9f (mapsz 7008)
2013-01-17 19:11:14 stored orphan tx 410792cfc2 (mapsz 7009)
2013-01-17 19:11:14 stored orphan tx 4263fdede4 (mapsz 7010)
2013-01-17 19:11:14 stored orphan tx d10ada15ca (mapsz 7011)
2013-01-17 19:11:14 stored orphan tx 272377fc1e (mapsz 7012)
2013-01-17 19:11:14 stored orphan tx 92793028c4 (mapsz 7013)
2013-01-17 19:11:14 stored orphan tx 9ed978604b (mapsz 7014)
2013-01-17 19:11:14 stored orphan tx 4d6d2eb7b2 (mapsz 7015)
2013-01-17 19:11:14 stored orphan tx 32e7f42202 (mapsz 7016)
2013-01-17 19:11:14 stored orphan tx 361d0be105 (mapsz 7017)
2013-01-17 19:11:14 stored orphan tx 075fac6443 (mapsz 7018)
2013-01-17 19:11:14 stored orphan tx c94c443196 (mapsz 7019)
2013-01-17 19:11:14 stored orphan tx 99794e9a0f (mapsz 7020)
2013-01-17 19:11:14 stored orphan tx 2e204f77ef (mapsz 7021)
2013-01-17 19:11:14 stored orphan tx 611f50adb9 (mapsz 7022)
2013-01-17 19:11:14 stored orphan tx 4e8f48abf9 (mapsz 7023)
2013-01-17 19:11:14 stored orphan tx e37f1cbc7c (mapsz 7024)
2013-01-17 19:11:14 stored orphan tx fbef46fbfe (mapsz 7025)
2013-01-17 19:11:14 stored orphan tx 4d69eb14e1 (mapsz 7026)
2013-01-17 19:11:14 stored orphan tx a9f7890442 (mapsz 7027)
2013-01-17 19:11:14 stored orphan tx 4f4385d272 (mapsz 7028)
2013-01-17 19:11:14 stored orphan tx 74954680f2 (mapsz 7029)
2013-01-17 19:11:14 stored orphan tx db1b38514e (mapsz 7030)
2013-01-17 19:11:14 stored orphan tx 980cab9703 (mapsz 7031)
2013-01-17 19:11:14 stored orphan tx 1fd6e33420 (mapsz 7032)
2013-01-17 19:11:14 stored orphan tx 608f623099 (mapsz 7033)
2013-01-17 19:11:14 stored orphan tx f518b22dae (mapsz 7034)
2013-01-17 19:11:14 stored orphan tx 16b5c806ac (mapsz 7035)
2013-01-17 19:11:14 stored orphan tx 0455cacba6 (mapsz 7036)
2013-01-17 19:11:14 stored orphan tx e9c1c5ec77 (mapsz 7037)
2013-01-17 19:11:14 stored orphan tx 188dad04bc (mapsz 7038)
2013-01-17 19:11:14 stored orphan tx 961caa4a2a (mapsz 7039)
2013-01-17 19:11:14 stored orphan tx 451ce8ac7e (mapsz 7040)
2013-01-17 19:11:14 stored orphan tx 2a5166a56a (mapsz 7041)
2013-01-17 19:11:14 stored orphan tx e5e558c830 (mapsz 7042)
2013-01-17 19:11:14 stored orphan tx ffd0193498 (mapsz 7043)
2013-01-17 19:11:14 stored orphan tx 2a1103d455 (mapsz 7044)
2013-01-17 19:11:14 stored orphan tx d7a28102f2 (mapsz 7045)
2013-01-17 19:11:14 stored orphan tx 9dac5f3f60 (mapsz 7046)
2013-01-17 19:11:14 stored orphan tx cc778412b8 (mapsz 7047)
2013-01-17 19:11:14 stored orphan tx e8b72dfabf (mapsz 7048)
2013-01-17 19:11:14 stored orphan tx 93e54aeaff (mapsz 7049)
2013-01-17 19:11:14 stored orphan tx 48e3cf66c6 (mapsz 7050)
2013-01-17 19:11:14 stored orphan tx 6a20f9fd6f (mapsz 7051)
2013-01-17 19:11:14 stored orphan tx 9bf52ddbaf (mapsz 7052)
2013-01-17 19:11:14 stored orphan tx 8044a6ef38 (mapsz 7053)
2013-01-17 19:11:14 stored orphan tx 662545ebf2 (mapsz 7054)
2013-01-17 19:11:14 stored orphan tx 7d8fb14c9c (mapsz 7055)
2013-01-17 19:11:14 stored orphan tx 7e58df6330 (mapsz 7056)
2013-01-17 19:11:14 stored orphan tx 23aa94ed96 (mapsz 7057)
2013-01-17 19:11:14 stored orphan tx 61e54174ac (mapsz 7058)
2013-01-17 19:11:14 stored orphan tx 0219898cce (mapsz 7059)
2013-01-17 19:11:14 stored orphan tx 6386bd6c47 (mapsz 7060)
2013-01-17 19:11:14 stored orphan tx 3e9b534ed1 (mapsz 7061)
2013-01-17 19:11:14 stored orphan tx 206851d1b2 (mapsz 7062)
2013-01-17 19:11:14 stored orphan tx 8c20cfaeeb (mapsz 7063)
2013-01-17 19:11:14 stored orphan tx 260d4c4d32 (mapsz 7064)
2013-01-17 19:11:14 stored orphan tx 8184713219 (mapsz 7065)
2013-01-17 19:11:14 stored orphan tx 8093517d6e (mapsz 7066)
2013-01-17 19:11:14 stored orphan tx 2c9c66a6c0 (mapsz 7067)
2013-01-17 19:11:14 stored orphan tx 8cc699aa9f (mapsz 7068)
2013-01-17 19:11:14 stored orphan tx b01a5d5329 (mapsz 7069)
2013-01-17 19:11:14 stored orphan tx 79a15e5f89 (mapsz 7070)
2013-01-17 19:11:14 stored orphan tx 818349218e (mapsz 7071)
2013-01-17 19:11:14 stored orphan tx 12de4714dc (mapsz 7072)
2013-01-17 19:11:14 stored orphan tx 60421a0b99 (mapsz 7073)
2013-01-17 19:11:14 stored orphan tx 12ffa70073 (mapsz 7074)
2013-01-17 19:11:14 stored orphan tx e42ea15855 (mapsz 7075)
2013-01-17 19:11:14 stored orphan tx 1d0cbd4cd0 (mapsz 7076)
2013-01-17 19:11:14 stored orphan tx 34cfe38721 (mapsz 7077)
2013-01-17 19:11:14 stored orphan tx c60075f0bc (mapsz 7078)
2013-01-17 19:11:14 stored orphan tx 0ea568b267 (mapsz 7079)
2013-01-17 19:11:14 stored orphan tx 58f18a23be (mapsz 7080)
2013-01-17 19:11:14 stored orphan tx 3d38ab964f (mapsz 7081)
2013-01-17 19:11:14 stored orphan tx 69736e57f5 (mapsz 7082)
2013-01-17 19:11:14 stored orphan tx 874b8e5aec (mapsz 7083)
2013-01-17 19:11:14 stored orphan tx 9f5dbe5660 (mapsz 7084)
2013-01-17 19:11:14 stored orphan tx a138fd4f60 (mapsz 7085)
2013-01-17 19:11:14 stored orphan tx b46c2e593b (mapsz 7086)
2013-01-17 19:11:14 stored orphan tx eed899d00a (mapsz 7087)
2013-01-17 19:11:14 stored orphan tx 60fbc0dee7 (mapsz 7088)
2013-01-17 19:11:14 stored orphan tx 0310144984 (mapsz 7089)
2013-01-17 19:11:14 stored orphan tx f211c51fee (mapsz 7090)
2013-01-17 19:11:14 stored orphan tx b202d3cb1b (mapsz 7091)
2013-01-17 19:11:14 stored orphan tx 19327ba427 (mapsz 7092)
2013-01-17 19:11:14 stored orphan tx 5570b694d0 (mapsz 7093)
2013-01-17 19:11:14 stored orphan tx a899af5177 (mapsz 7094)
2013-01-17 19:11:14 stored orphan tx c9304baa9d (mapsz 7095)
2013-01-17 19:11:14 received block 00000000000002d2176b37b9cf8b5efe26ed427ad0bbdab45a063ccd824252f3
2013-01-17 19:11:14 ProcessBlock: ORPHAN BLOCK, prev=0000000000000445188b833eb4e60b5d8fc3208d0a331bc89aa49bde1c630845
2013-01-17 19:11:14 stored orphan tx 12aa398973 (mapsz 7096)
2013-01-17 19:11:14 stored orphan tx 4cb71aa585 (mapsz 7097)
2013-01-17 19:11:14 stored orphan tx 80d0e9d446 (mapsz 7098)
2013-01-17 19:11:14 stored orphan tx f5e041bde7 (mapsz 7099)
2013-01-17 19:11:14 stored orphan tx 56b3f68157 (mapsz 7100)
2013-01-17 19:11:14 stored orphan tx bcd0510a1f (mapsz 7101)
2013-01-17 19:11:14 stored orphan tx 3b7533a5cd (mapsz 7102)
2013-01-17 19:11:14 stored orphan tx 2d4c400116 (mapsz 7103)
2013-01-17 19:11:14 stored orphan tx e0f06a8294 (mapsz 7104)
2013-01-17 19:11:14 stored orphan tx 695d8f3648 (mapsz 7105)
2013-01-17 19:11:14 stored orphan tx bc94451d1a (mapsz 7106)
2013-01-17 19:11:14 stored orphan tx 84ef1e7b5e (mapsz 7107)
2013-01-17 19:11:14 stored orphan tx 83ac500327 (mapsz 7108)
2013-01-17 19:11:14 stored orphan tx 6ae7b25dba (mapsz 7109)
2013-01-17 19:11:14 stored orphan tx 9dd1de37c4 (mapsz 7110)
2013-01-17 19:11:14 stored orphan tx 01bec6b640 (mapsz 7111)
2013-01-17 19:11:14 stored orphan tx f20da853e3 (mapsz 7112)
2013-01-17 19:11:14 stored orphan tx f19cf27a49 (mapsz 7113)
2013-01-17 19:11:14 stored orphan tx 4912e535e4 (mapsz 7114)
2013-01-17 19:11:14 stored orphan tx 44f9348522 (mapsz 7115)
2013-01-17 19:11:14 stored orphan tx fbd8a03e24 (mapsz 7116)
2013-01-17 19:11:14 stored orphan tx 74aa8cba4d (mapsz 7117)
2013-01-17 19:11:14 stored orphan tx f8a43f757d (mapsz 7118)
2013-01-17 19:11:14 stored orphan tx 479cbac1af (mapsz 7119)
2013-01-17 19:11:14 stored orphan tx 010e54671e (mapsz 7120)
2013-01-17 19:11:14 stored orphan tx 5baccdae6e (mapsz 7121)
2013-01-17 19:11:14 ignoring large orphan tx (size: 7994, hash: 06a3591784)
2013-01-17 19:11:14 stored orphan tx 3d79ec0e33 (mapsz 7122)
2013-01-17 19:11:14 stored orphan tx 159b1197a0 (mapsz 7123)
2013-01-17 19:11:14 stored orphan tx 7e0559ee77 (mapsz 7124)
2013-01-17 19:11:14 stored orphan tx 1324ab562a (mapsz 7125)
2013-01-17 19:11:14 stored orphan tx 332136b962 (mapsz 7126)
2013-01-17 19:11:14 stored orphan tx 344570800d (mapsz 7127)
2013-01-17 19:11:14 stored orphan tx b3ebc22f47 (mapsz 7128)
2013-01-17 19:11:14 stored orphan tx 536db2155d (mapsz 7129)
2013-01-17 19:11:14 stored orphan tx 08de5233a0 (mapsz 7130)
2013-01-17 19:11:14 stored orphan tx 2e4330f973 (mapsz 7131)
2013-01-17 19:11:14 stored orphan tx de051cebdb (mapsz 7132)
2013-01-17 19:11:14 stored orphan tx 23f6c661ff (mapsz 7133)
2013-01-17 19:11:14 stored orphan tx a0c1e3ecd3 (mapsz 7134)
2013-01-17 19:11:14 stored orphan tx 96401dd160 (mapsz 7135)
2013-01-17 19:11:14 stored orphan tx 0e0cc14b3b (mapsz 7136)
2013-01-17 19:11:14 stored orphan tx 614ca459ee (mapsz 7137)
2013-01-17 19:11:14 stored orphan tx 2c22977543 (mapsz 7138)
2013-01-17 19:11:14 stored orphan tx 6da15fd472 (mapsz 7139)
2013-01-17 19:11:14 stored orphan tx 08fbf723dd (mapsz 7140)
2013-01-17 19:11:14 stored orphan tx dbe2065abf (mapsz 7141)
2013-01-17 19:11:14 stored orphan tx 55c1a20ecc (mapsz 7142)
2013-01-17 19:11:14 stored orphan tx 52309938e7 (mapsz 7143)
2013-01-17 19:11:14 stored orphan tx 6425740a5b (mapsz 7144)
2013-01-17 19:11:14 stored orphan tx acd3eead39 (mapsz 7145)
2013-01-17 19:11:14 stored orphan tx e490d6c625 (mapsz 7146)
2013-01-17 19:11:14 stored orphan tx 91f333fd40 (mapsz 7147)
2013-01-17 19:11:14 stored orphan tx 469e78f53a (mapsz 7148)
2013-01-17 19:11:14 stored orphan tx c3044e0d46 (mapsz 7149)
2013-01-17 19:11:14 stored orphan tx 9ec66b91e7 (mapsz 7150)
2013-01-17 19:11:14 stored orphan tx 7f1ddb0470 (mapsz 7151)
2013-01-17 19:11:14 stored orphan tx f79b1692c0 (mapsz 7152)
2013-01-17 19:11:14 stored orphan tx f3f73d2af7 (mapsz 7153)
2013-01-17 19:11:14 stored orphan tx ecbc87b01a (mapsz 7154)
2013-01-17 19:11:14 stored orphan tx 204320562b (mapsz 7155)
2013-01-17 19:11:14 stored orphan tx 7e2f63e7cc (mapsz 7156)
2013-01-17 19:11:14 received block 0000000000000374cc5210432cbc43f0ca9a7efd08a907040e8117cf45ced018
2013-01-17 19:11:14 ProcessBlock: ORPHAN BLOCK, prev=00000000000002d2176b37b9cf8b5efe26ed427ad0bbdab45a063ccd824252f3
2013-01-17 19:11:14 stored orphan tx f78b3ad562 (mapsz 7157)
2013-01-17 19:11:14 stored orphan tx e50f9c93e4 (mapsz 7158)
2013-01-17 19:11:14 stored orphan tx a72ed900ee (mapsz 7159)
2013-01-17 19:11:14 stored orphan tx 3e6c3fa7d2 (mapsz 7160)
2013-01-17 19:11:14 stored orphan tx 9d19001971 (mapsz 7161)
2013-01-17 19:11:14 stored orphan tx a7d3c783e5 (mapsz 7162)
2013-01-17 19:11:14 stored orphan tx d306194101 (mapsz 7163)
2013-01-17 19:11:14 stored orphan tx d795ca48c5 (mapsz 7164)
2013-01-17 19:11:14 stored orphan tx af297f71cf (mapsz 7165)
2013-01-17 19:11:14 stored orphan tx 69fb578d88 (mapsz 7166)
2013-01-17 19:11:14 stored orphan tx d2a1a62e66 (mapsz 7167)
2013-01-17 19:11:14 stored orphan tx 755b422acf (mapsz 7168)
2013-01-17 19:11:14 stored orphan tx adf3f9c5e9 (mapsz 7169)
2013-01-17 19:11:14 stored orphan tx dbb2996f85 (mapsz 7170)
2013-01-17 19:11:14 stored orphan tx e4169abf76 (mapsz 7171)
2013-01-17 19:11:14 stored orphan tx f9515fc7c8 (mapsz 7172)
2013-01-17 19:11:14 stored orphan tx a6b1b1886e (mapsz 7173)
2013-01-17 19:11:14 stored orphan tx e1ce978ea0 (mapsz 7174)
2013-01-17 19:11:14 stored orphan tx 7ea0515163 (mapsz 7175)
2013-01-17 19:11:14 stored orphan tx 8e8962ba0d (mapsz 7176)
2013-01-17 19:11:14 stored orphan tx b31d48ea96 (mapsz 7177)
2013-01-17 19:11:14 stored orphan tx 3f176c5b91 (mapsz 7178)
2013-01-17 19:11:14 stored orphan tx 7e2fe0ceec (mapsz 7179)
2013-01-17 19:11:14 stored orphan tx 874d714d13 (mapsz 7180)
2013-01-17 19:11:14 stored orphan tx b7beeb468f (mapsz 7181)
2013-01-17 19:11:14 stored orphan tx 017483423f (mapsz 7182)
2013-01-17 19:11:14 stored orphan tx 2c49534102 (mapsz 7183)
2013-01-17 19:11:14 stored orphan tx 3397254d76 (mapsz 7184)
2013-01-17 19:11:14 stored orphan tx 7748cba49d (mapsz 7185)
2013-01-17 19:11:14 stored orphan tx d1352174f5 (mapsz 7186)
2013-01-17 19:11:14 stored orphan tx 5209776ead (mapsz 7187)
2013-01-17 19:11:14 stored orphan tx 81cba4e449 (mapsz 7188)
2013-01-17 19:11:14 stored orphan tx 6a721c7f5e (mapsz 7189)
2013-01-17 19:11:14 stored orphan tx a7fdc5bc8f (mapsz 7190)
2013-01-17 19:11:14 stored orphan tx 4f693fc538 (mapsz 7191)
2013-01-17 19:11:14 stored orphan tx 412c9964fa (mapsz 7192)
2013-01-17 19:11:14 stored orphan tx bfcca92649 (mapsz 7193)
2013-01-17 19:11:14 stored orphan tx d2413cca51 (mapsz 7194)
2013-01-17 19:11:14 stored orphan tx 2253644024 (mapsz 7195)
2013-01-17 19:11:14 stored orphan tx b2ae3cfaea (mapsz 7196)
2013-01-17 19:11:14 stored orphan tx 48a92882d1 (mapsz 7197)
2013-01-17 19:11:14 stored orphan tx cd1c20a556 (mapsz 7198)
2013-01-17 19:11:14 stored orphan tx 7bb54015d5 (mapsz 7199)
2013-01-17 19:11:14 stored orphan tx 0ffdefbab0 (mapsz 7200)
2013-01-17 19:11:14 stored orphan tx ec476b49c1 (mapsz 7201)
2013-01-17 19:11:14 stored orphan tx 067f7fea75 (mapsz 7202)
2013-01-17 19:11:14 stored orphan tx 91d6f7ea9d (mapsz 7203)
2013-01-17 19:11:14 stored orphan tx 63400cc375 (mapsz 7204)
2013-01-17 19:11:14 stored orphan tx cdb34e3626 (mapsz 7205)
2013-01-17 19:11:14 stored orphan tx 40f784d2e4 (mapsz 7206)
2013-01-17 19:11:14 stored orphan tx f91560becc (mapsz 7207)
2013-01-17 19:11:14 stored orphan tx de16419175 (mapsz 7208)
2013-01-17 19:11:14 stored orphan tx 9214176189 (mapsz 7209)
2013-01-17 19:11:14 stored orphan tx 112e788962 (mapsz 7210)
2013-01-17 19:11:14 stored orphan tx e0e36f39ff (mapsz 7211)
2013-01-17 19:11:14 stored orphan tx c0d7770df2 (mapsz 7212)
2013-01-17 19:11:14 stored orphan tx c202df772c (mapsz 7213)
2013-01-17 19:11:14 stored orphan tx e8b89a035f (mapsz 7214)
2013-01-17 19:11:14 stored orphan tx 81341817bb (mapsz 7215)
2013-01-17 19:11:14 stored orphan tx 8f7e433cfb (mapsz 7216)
2013-01-17 19:11:14 stored orphan tx 643a2cda01 (mapsz 7217)
2013-01-17 19:11:14 stored orphan tx eed9cb3d26 (mapsz 7218)
2013-01-17 19:11:14 stored orphan tx 3cb950b729 (mapsz 7219)
2013-01-17 19:11:14 stored orphan tx 62a280dace (mapsz 7220)
2013-01-17 19:11:14 stored orphan tx edd3bc500a (mapsz 7221)
2013-01-17 19:11:14 stored orphan tx da6d7161d6 (mapsz 7222)
2013-01-17 19:11:14 stored orphan tx c34e837e7b (mapsz 7223)
2013-01-17 19:11:14 stored orphan tx e3216c04a8 (mapsz 7224)
2013-01-17 19:11:14 stored orphan tx 0f4abd37dc (mapsz 7225)
2013-01-17 19:11:14 stored orphan tx 89126a99ef (mapsz 7226)
2013-01-17 19:11:14 stored orphan tx 17ec5e23a7 (mapsz 7227)
2013-01-17 19:11:14 stored orphan tx e7462ecaab (mapsz 7228)
2013-01-17 19:11:14 stored orphan tx 1f9880359b (mapsz 7229)
2013-01-17 19:11:14 stored orphan tx 5de5e690f1 (mapsz 7230)
2013-01-17 19:11:14 stored orphan tx dc455b4d75 (mapsz 7231)
2013-01-17 19:11:14 stored orphan tx 7b18ca42cf (mapsz 7232)
2013-01-17 19:11:14 stored orphan tx 3134ff5047 (mapsz 7233)
2013-01-17 19:11:14 stored orphan tx 24063f9edb (mapsz 7234)
2013-01-17 19:11:14 stored orphan tx e066e941f0 (mapsz 7235)
2013-01-17 19:11:14 stored orphan tx 882245dc89 (mapsz 7236)
2013-01-17 19:11:14 stored orphan tx 7afd0f80f2 (mapsz 7237)
2013-01-17 19:11:14 stored orphan tx e670702a37 (mapsz 7238)
2013-01-17 19:11:14 stored orphan tx faf3dc0540 (mapsz 7239)
2013-01-17 19:11:14 CTxMemPool::accept() : accepted f44449018c (poolsz 14)
2013-01-17 19:11:14 stored orphan tx 8589f51aac (mapsz 7240)
2013-01-17 19:11:14 stored orphan tx 5e3267f8e6 (mapsz 7241)
2013-01-17 19:11:14 stored orphan tx 08ee81bb11 (mapsz 7242)
2013-01-17 19:11:14 stored orphan tx e40d190b18 (mapsz 7243)
2013-01-17 19:11:14 stored orphan tx 5334577e67 (mapsz 7244)
2013-01-17 19:11:14 stored orphan tx f246e72f3d (mapsz 7245)
2013-01-17 19:11:14 stored orphan tx 1b5c50366b (mapsz 7246)
2013-01-17 19:11:14 stored orphan tx 4e6f309c7c (mapsz 7247)
2013-01-17 19:11:14 stored orphan tx a715638d44 (mapsz 7248)
2013-01-17 19:11:14 stored orphan tx 4811bf8ff1 (mapsz 7249)
2013-01-17 19:11:14 stored orphan tx d7c08a680c (mapsz 7250)
2013-01-17 19:11:14 stored orphan tx 4fef9531e9 (mapsz 7251)
2013-01-17 19:11:14 stored orphan tx 658f439ead (mapsz 7252)
2013-01-17 19:11:14 stored orphan tx d5b2087e6b (mapsz 7253)
2013-01-17 19:11:14 stored orphan tx 394d6f94c9 (mapsz 7254)
2013-01-17 19:11:14 stored orphan tx fe67803aaa (mapsz 7255)
2013-01-17 19:11:14 stored orphan tx 5ecdcaaaad (mapsz 7256)
2013-01-17 19:11:14 stored orphan tx 4542bec7ca (mapsz 7257)
2013-01-17 19:11:14 stored orphan tx 8c8459a5ff (mapsz 7258)
2013-01-17 19:11:14 stored orphan tx 1da48d55ba (mapsz 7259)
2013-01-17 19:11:14 stored orphan tx 21404028a4 (mapsz 7260)
2013-01-17 19:11:14 stored orphan tx 8ad70735a0 (mapsz 7261)
2013-01-17 19:11:14 stored orphan tx 31e53de588 (mapsz 7262)
2013-01-17 19:11:14 stored orphan tx b81748c0fe (mapsz 7263)
2013-01-17 19:11:14 stored orphan tx 98709b233e (mapsz 7264)
2013-01-17 19:11:14 stored orphan tx 9cfd9f6985 (mapsz 7265)
2013-01-17 19:11:14 stored orphan tx 2d55ed33ec (mapsz 7266)
2013-01-17 19:11:14 stored orphan tx dba0f32c0e (mapsz 7267)
2013-01-17 19:11:14 stored orphan tx 0316528b9c (mapsz 7268)
2013-01-17 19:11:14 stored orphan tx 7c6c3688b1 (mapsz 7269)
2013-01-17 19:11:14 stored orphan tx 229ee74e61 (mapsz 7270)
2013-01-17 19:11:14 stored orphan tx 9a90a5ce62 (mapsz 7271)
2013-01-17 19:11:14 stored orphan tx fab93a44e6 (mapsz 7272)
2013-01-17 19:11:14 stored orphan tx 06d8ea5d3e (mapsz 7273)
2013-01-17 19:11:14 stored orphan tx c7408f3857 (mapsz 7274)
2013-01-17 19:11:14 stored orphan tx 89fe925108 (mapsz 7275)
2013-01-17 19:11:14 stored orphan tx 5f4c855cbd (mapsz 7276)
2013-01-17 19:11:14 stored orphan tx 3fb708120b (mapsz 7277)
2013-01-17 19:11:14 stored orphan tx 889ef13408 (mapsz 7278)
2013-01-17 19:11:14 stored orphan tx 23ec5a6a95 (mapsz 7279)
2013-01-17 19:11:14 stored orphan tx 84447b8e97 (mapsz 7280)
2013-01-17 19:11:14 stored orphan tx 2cfac7f2fc (mapsz 7281)
2013-01-17 19:11:14 stored orphan tx b1350231bf (mapsz 7282)
2013-01-17 19:11:14 stored orphan tx a17bda3326 (mapsz 7283)
2013-01-17 19:11:14 stored orphan tx d0da050989 (mapsz 7284)
2013-01-17 19:11:14 stored orphan tx a2127fb7b2 (mapsz 7285)
2013-01-17 19:11:14 stored orphan tx c6c3b008fa (mapsz 7286)
2013-01-17 19:11:14 stored orphan tx 6470cb32e5 (mapsz 7287)
2013-01-17 19:11:14 stored orphan tx f77c59bf89 (mapsz 7288)
2013-01-17 19:11:14 stored orphan tx 7b72b1f24f (mapsz 7289)
2013-01-17 19:11:14 stored orphan tx 4a24e9cd1f (mapsz 7290)
2013-01-17 19:11:14 stored orphan tx afa3b54a01 (mapsz 7291)
2013-01-17 19:11:14 stored orphan tx ede53dfec5 (mapsz 7292)
2013-01-17 19:11:14 stored orphan tx 8264e26c4b (mapsz 7293)
2013-01-17 19:11:14 stored orphan tx 6afae7d023 (mapsz 7294)
2013-01-17 19:11:14 stored orphan tx f4a7cc0e9b (mapsz 7295)
2013-01-17 19:11:14 stored orphan tx 695b7adac7 (mapsz 7296)
2013-01-17 19:11:14 stored orphan tx 2de15f8fe3 (mapsz 7297)
2013-01-17 19:11:14 stored orphan tx 4fc11a55db (mapsz 7298)
2013-01-17 19:11:14 stored orphan tx b77b52e24e (mapsz 7299)
2013-01-17 19:11:14 stored orphan tx 68a5acf644 (mapsz 7300)
2013-01-17 19:11:14 stored orphan tx 20068291aa (mapsz 7301)
2013-01-17 19:11:14 stored orphan tx acff53a892 (mapsz 7302)
2013-01-17 19:11:14 stored orphan tx 5620eef063 (mapsz 7303)
2013-01-17 19:11:14 stored orphan tx 7368c34510 (mapsz 7304)
2013-01-17 19:11:14 stored orphan tx 9c934de434 (mapsz 7305)
2013-01-17 19:11:14 stored orphan tx 538c97923b (mapsz 7306)
2013-01-17 19:11:14 stored orphan tx 6eaad1ca2d (mapsz 7307)
2013-01-17 19:11:14 stored orphan tx 117a0bcdff (mapsz 7308)
2013-01-17 19:11:14 stored orphan tx 352614fb77 (mapsz 7309)
2013-01-17 19:11:14 stored orphan tx 9610dc8ead (mapsz 7310)
2013-01-17 19:11:14 stored orphan tx 8f9c99e4a6 (mapsz 7311)
2013-01-17 19:11:14 stored orphan tx ca46dce228 (mapsz 7312)
2013-01-17 19:11:14 stored orphan tx c0023f763f (mapsz 7313)
2013-01-17 19:11:14 stored orphan tx 5d14df9b79 (mapsz 7314)
2013-01-17 19:11:14 stored orphan tx 09f132e223 (mapsz 7315)
2013-01-17 19:11:14 stored orphan tx 9097adbf04 (mapsz 7316)
2013-01-17 19:11:14 stored orphan tx 567916d0d8 (mapsz 7317)
2013-01-17 19:11:14 stored orphan tx f9dabfb14c (mapsz 7318)
2013-01-17 19:11:14 stored orphan tx a0fb1b31b7 (mapsz 7319)
2013-01-17 19:11:14 stored orphan tx 5b8ab65712 (mapsz 7320)
2013-01-17 19:11:14 stored orphan tx 0390428339 (mapsz 7321)
2013-01-17 19:11:14 stored orphan tx b476300ddf (mapsz 7322)
2013-01-17 19:11:14 stored orphan tx 01418d8cca (mapsz 7323)
2013-01-17 19:11:14 stored orphan tx 971f8623ca (mapsz 7324)
2013-01-17 19:11:14 stored orphan tx 83eee01758 (mapsz 7325)
2013-01-17 19:11:14 stored orphan tx 4ddc660108 (mapsz 7326)
2013-01-17 19:11:14 stored orphan tx 40c9e5cc7a (mapsz 7327)
2013-01-17 19:11:14 stored orphan tx 1ae6fecf9f (mapsz 7328)
2013-01-17 19:11:14 stored orphan tx 6128b3ed3d (mapsz 7329)
2013-01-17 19:11:14 stored orphan tx 3c2095c207 (mapsz 7330)
2013-01-17 19:11:14 stored orphan tx c03c03cdd3 (mapsz 7331)
2013-01-17 19:11:14 stored orphan tx 8b0c3fae72 (mapsz 7332)
2013-01-17 19:11:14 stored orphan tx 0e4c48e631 (mapsz 7333)
2013-01-17 19:11:14 stored orphan tx 0490c0a88e (mapsz 7334)
2013-01-17 19:11:14 stored orphan tx 122a274a20 (mapsz 7335)
2013-01-17 19:11:14 stored orphan tx 83cb8cdf5f (mapsz 7336)
2013-01-17 19:11:14 stored orphan tx c662eda95e (mapsz 7337)
2013-01-17 19:11:14 stored orphan tx 1f8c36253a (mapsz 7338)
2013-01-17 19:11:14 stored orphan tx f546358dd5 (mapsz 7339)
2013-01-17 19:11:14 stored orphan tx a6fb6807da (mapsz 7340)
2013-01-17 19:11:14 stored orphan tx 2e88c0b3e8 (mapsz 7341)
2013-01-17 19:11:14 stored orphan tx d6e92888ba (mapsz 7342)
2013-01-17 19:11:14 stored orphan tx b55fdf7544 (mapsz 7343)
2013-01-17 19:11:14 stored orphan tx 1dece1c10b (mapsz 7344)
2013-01-17 19:11:14 stored orphan tx fb700bcce5 (mapsz 7345)
2013-01-17 19:11:14 stored orphan tx eb36455510 (mapsz 7346)
2013-01-17 19:11:14 stored orphan tx 238a2db63c (mapsz 7347)
2013-01-17 19:11:14 stored orphan tx 850a7235c2 (mapsz 7348)
2013-01-17 19:11:14 stored orphan tx bf2a0dfc0f (mapsz 7349)
2013-01-17 19:11:14 stored orphan tx 37ae5ca60d (mapsz 7350)
2013-01-17 19:11:14 stored orphan tx 2804a554a7 (mapsz 7351)
2013-01-17 19:11:14 stored orphan tx 501a366dba (mapsz 7352)
2013-01-17 19:11:14 stored orphan tx 6772be7a0f (mapsz 7353)
2013-01-17 19:11:14 stored orphan tx d5b30f1552 (mapsz 7354)
2013-01-17 19:11:14 stored orphan tx 2ab1acad56 (mapsz 7355)
2013-01-17 19:11:14 stored orphan tx 4cd00856c4 (mapsz 7356)
2013-01-17 19:11:14 stored orphan tx 54a6d900e6 (mapsz 7357)
2013-01-17 19:11:14 stored orphan tx 7c1468f6a6 (mapsz 7358)
2013-01-17 19:11:14 stored orphan tx 5d64317eef (mapsz 7359)
2013-01-17 19:11:14 stored orphan tx 5045289f55 (mapsz 7360)
2013-01-17 19:11:14 stored orphan tx 1013b54981 (mapsz 7361)
2013-01-17 19:11:14 stored orphan tx 153843cc36 (mapsz 7362)
2013-01-17 19:11:14 stored orphan tx df1e4704ec (mapsz 7363)
2013-01-17 19:11:14 stored orphan tx 66aca2e1c1 (mapsz 7364)
2013-01-17 19:11:14 stored orphan tx ab87274069 (mapsz 7365)
2013-01-17 19:11:14 stored orphan tx 05fefe4bd0 (mapsz 7366)
2013-01-17 19:11:14 stored orphan tx 3a88e8de2d (mapsz 7367)
2013-01-17 19:11:14 stored orphan tx f3ac021b67 (mapsz 7368)
2013-01-17 19:11:14 stored orphan tx a9a48c6a35 (mapsz 7369)
2013-01-17 19:11:14 stored orphan tx 38a3c511ff (mapsz 7370)
2013-01-17 19:11:14 stored orphan tx 93943fda5f (mapsz 7371)
2013-01-17 19:11:15 received block 00000000000001c9c0927b4e0ed222789714581d6cced7d32be84af3628f8434
2013-01-17 19:11:22 - Connect 570 transactions: 7015.63ms (12.308ms/tx, 5.621ms/txin)
2013-01-17 19:11:22 - Verify 1248 txins: 7015.63ms (5.621ms/txin)
2013-01-17 19:11:22 - Connect: 7046.88ms
2013-01-17 19:11:22 - Flush 1599 transactions: 15.63ms (0.0098ms/tx)
2013-01-17 19:11:22 SetBestChain: new best=00000000000001c9c0927b4e0ed222789714581d6cced7d32be84af3628f8434 height=211001 work=643748744896176013536 tx=9557893 date=2012-12-05 17:22:57
2013-01-17 19:41:17 received block 00000000000002d4d9c3d7a7d9e97b314197634b519af93861d92a8f928b7d8a
2013-01-17 19:41:19 - Connect 162 transactions: 1687.50ms (10.417ms/tx, 4.623ms/txin)
2013-01-17 19:41:19 - Verify 365 txins: 1687.50ms (4.623ms/txin)
2013-01-17 19:41:19 - Connect: 1687.50ms
2013-01-17 19:41:19 - Flush 439 transactions: 15.63ms (0.0356ms/tx)
2013-01-17 19:41:19 SetBestChain: new best=00000000000002d4d9c3d7a7d9e97b314197634b519af93861d92a8f928b7d8a height=211621 work=652906285570196506336 tx=9720244 date=2012-12-10 08:34:15
2013-01-17 20:11:10 received block 00000000000003e54445f7f3f26b24734887a80ccd8f0e29732b38c3c9196fc1
2013-01-17 20:11:13 - Connect 175 transactions: 2531.25ms (14.464ms/tx, 4.731ms/txin)
2013-01-17 20:11:13 - Verify 535 txins: 2546.88ms (4.761ms/txin)
2013-01-17 20:11:13 - Connect: 2578.13ms
2013-01-17 20:11:13 - Flush 622 transactions: 15.63ms (0.0251ms/tx)
2013-01-17 20:11:13 SetBestChain: new best=00000000000003e54445f7f3f26b24734887a80ccd8f0e29732b38c3c9196fc1 height=212176 work=660957054346119685231 tx=9878527 date=2012-12-14 12:10:46
2013-01-17 20:41:25 received block 00000000000002ba2d3d124ede97c2d5b9430bd29cb3909fd9a4d35e9cbd597e
2013-01-17 20:41:30 - Connect 784 transactions: 5531.25ms (7.055ms/tx, 4.974ms/txin)
2013-01-17 20:41:30 - Verify 1112 txins: 5531.25ms (4.974ms/txin)
2013-01-17 20:41:30 - Connect: 5609.38ms
2013-01-17 20:41:30 - Flush 1338 transactions: 15.63ms (0.0117ms/tx)
2013-01-17 20:41:30 SetBestChain: new best=00000000000002ba2d3d124ede97c2d5b9430bd29cb3909fd9a4d35e9cbd597e height=212652 work=667847174091112515731 tx=10031069 date=2012-12-18 13:54:56
2013-01-17 21:11:17 received block 000000000000010d710f8a255d2c51d096f454116a0e66fb6e457d35b4ed420c
2013-01-17 21:11:17 - Connect 37 transactions: 156.25ms (4.223ms/tx, 3.720ms/txin)
2013-01-17 21:11:17 - Verify 42 txins: 156.25ms (3.720ms/txin)
2013-01-17 21:11:17 - Connect: 171.88ms
2013-01-17 21:11:17 - Flush 76 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 21:11:17 SetBestChain: new best=000000000000010d710f8a255d2c51d096f454116a0e66fb6e457d35b4ed420c height=213078 work=674013541762051477481 tx=10177173 date=2012-12-21 23:20:16
2013-01-17 21:41:11 received block 0000000000000252d7a5e126f5e69f9fc03c56eb4b96dc9ba87ca3d16abe143f
2013-01-17 21:41:11 - Connect 62 transactions: 406.25ms (6.552ms/tx, 2.621ms/txin)
2013-01-17 21:41:11 - Verify 155 txins: 421.88ms (2.722ms/txin)
2013-01-17 21:41:11 - Connect: 437.50ms
2013-01-17 21:41:11 - Flush 196 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 21:41:11 SetBestChain: new best=0000000000000252d7a5e126f5e69f9fc03c56eb4b96dc9ba87ca3d16abe143f height=213586 work=681366862834438783981 tx=10323498 date=2012-12-25 18:29:16
2013-01-17 22:11:06 received block 00000000000001580e802dc4d822d30a83895f5211abf90b4acd8603b69f93b9
2013-01-17 22:11:15 - Connect 698 transactions: 8875.00ms (12.715ms/tx, 5.261ms/txin)
2013-01-17 22:11:15 - Verify 1687 txins: 8875.00ms (5.261ms/txin)
2013-01-17 22:11:15 - Connect: 8921.88ms
2013-01-17 22:11:15 - Flush 1754 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 22:11:15 SetBestChain: new best=00000000000001580e802dc4d822d30a83895f5211abf90b4acd8603b69f93b9 height=214095 work=688063697195939463856 tx=10459906 date=2012-12-29 00:00:38
2013-01-17 22:41:13 received block 00000000000001a6382b9a5305b0704e62bc77b1564baa90b6e0feb107b31055
2013-01-17 22:41:13 - Connect 9 transactions: 46.88ms (5.208ms/tx, 2.930ms/txin)
2013-01-17 22:41:13 - Verify 16 txins: 46.88ms (2.930ms/txin)
2013-01-17 22:41:13 - Connect: 46.88ms
2013-01-17 22:41:13 - Flush 25 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 22:41:13 SetBestChain: new best=00000000000001a6382b9a5305b0704e62bc77b1564baa90b6e0feb107b31055 height=214727 work=696151803843239392536 tx=10605906 date=2013-01-02 00:27:27
2013-01-17 23:11:13 received block 000000000000032a8da12d4b5d9a0df0ba135249e222dac6e1cebf69350b0eae
2013-01-17 23:11:18 - Connect 500 transactions: 4671.88ms (9.344ms/tx, 5.445ms/txin)
2013-01-17 23:11:18 - Verify 858 txins: 4671.88ms (5.445ms/txin)
2013-01-17 23:11:18 - Connect: 4750.00ms
2013-01-17 23:11:18 - Flush 1202 transactions: 0.00ms (0.0000ms/tx)
2013-01-17 23:11:18 SetBestChain: new best=000000000000032a8da12d4b5d9a0df0ba135249e222dac6e1cebf69350b0eae height=215269 work=703088123151525090866 tx=10755228 date=2013-01-05 13:18:39
2013-01-17 23:41:13 received block 00000000000001b892f486cc4e8dcace8fbe722126a4a1b81fa07df9e75c3e7c
2013-01-17 23:41:17 - Connect 489 transactions: 4359.38ms (8.915ms/tx, 5.323ms/txin)
2013-01-17 23:41:17 - Verify 819 txins: 4359.38ms (5.323ms/txin)
2013-01-17 23:41:17 - Connect: 4437.50ms
2013-01-17 23:41:17 - Flush 998 transactions: 15.63ms (0.0157ms/tx)
2013-01-17 23:41:17 SetBestChain: new best=00000000000001b892f486cc4e8dcace8fbe722126a4a1b81fa07df9e75c3e7c height=215795 work=709917060211053043020 tx=10893874 date=2013-01-09 03:20:46
2013-01-18 00:11:29 received block 000000000000051430baf2c168b3bdd4ea85db1578f4cc16c7f806b308fcc5e2
2013-01-18 00:11:36 - Connect 534 transactions: 6359.38ms (11.909ms/tx, 5.317ms/txin)
2013-01-18 00:11:36 - Verify 1196 txins: 6359.38ms (5.317ms/txin)
2013-01-18 00:11:36 - Connect: 6421.88ms
2013-01-18 00:11:36 - Flush 1307 transactions: 15.63ms (0.0120ms/tx)
2013-01-18 00:11:36 SetBestChain: new best=000000000000051430baf2c168b3bdd4ea85db1578f4cc16c7f806b308fcc5e2 height=216159 work=714997379876504659424 tx=11028193 date=2013-01-11 20:29:56
2013-01-18 00:41:11 received block 00000000000000825f49ec951fd298345ff685d6d0eeb5755a739bef78501b46
2013-01-18 00:41:18 - Connect 490 transactions: 6671.88ms (13.616ms/tx, 5.469ms/txin)
2013-01-18 00:41:18 - Verify 1220 txins: 6671.88ms (5.469ms/txin)
2013-01-18 00:41:18 - Connect: 6718.75ms
2013-01-18 00:41:18 - Flush 1397 transactions: 31.25ms (0.0224ms/tx)
2013-01-18 00:41:18 SetBestChain: new best=00000000000000825f49ec951fd298345ff685d6d0eeb5755a739bef78501b46 height=216567 work=720691804116900976712 tx=11169766 date=2013-01-14 21:16:00
Is there anything in particular we should try with the latest build (Jan 15)?
Try loading from scratch with an empty data directory. It's fast
.
Is there anything in particular we should try with the latest build (Jan 15)?
Are you joking? Your whole attitude and the reality (0.7.99 is experimental!) press new people to use bootstrap.dat and this will increase as longer you wait.
And if a newbie complains to me about long first initialization, of course I will point them to bootstrap.dat method, who won´t?
And if a newbie complains to me about long first initialization, of course I will point them to bootstrap.dat method, who won´t?
Of course. I'll point them to bootstrap.dat now too. But that doesn't mean we don't have to fix the real problem (the fact that the built-in block download code is very crappy). If things were working as they should, we wouldn't need to tell new users about bootstrap.dat (although it may still be useful).
My attitude? I don't want to be responsible for a network fork. The purpose of the reference client is implementing a full node, and that means zero trust: it will verify all incoming data. If you can't live with the resource requirements that are needed for that, and consider trusting some instance to do checking for you, you're better off using a lightweight client (which only checks block headers - see SPV mode in Satoshi's paper), as those don't need trust in the data source and don't risk creating a network fork if the trusted data is wrong.
I think everything that had to be said, is said now. You may disagree with me, but if so, please take it elsewhere. I won't respond anymore to messages here which are not about getting 0.8 tested.
And yes, using bootstrap.dat for initialization avoids the problem with slow block downloading, but that's not what you want to be telling new users.
Are you joking? Your whole attitude and the reality (0.7.99 is experimental!) press new people to use bootstrap.dat and this will increase as longer you wait.And if a newbie complains to me about long first initialization, of course I will point them to bootstrap.dat method, who won´t?
smtp
It took my machine less than 4 hours to download from scratch, and most of that was waiting on peers to send the data. What is the problem?
Really, if you don't have any bug reports or testing results, can you please start a new thread to discuss potential future improvements. This thread is for testing 0.8 so that it can be released sometime this decade.
See, I didn't lie.
Then you have your own definition of "concatenation". But the reader of these postings can judge by themselves.smtp
And yes, using bootstrap.dat for initialization avoids the problem with slow block downloading, but that's not what you want to be telling new users.
Are you joking? Your whole attitude and the reality (0.7.99 is experimental!) press new people to use bootstrap.dat and this will increase as longer you wait.And if a newbie complains to me about long first initialization, of course I will point them to bootstrap.dat method, who won´t?
smtp
Sorry, I get tired, I just wanted to reply with the 4th, last part, but it looks superflously. Therefore only one obviously point: even if you don't know what "cmp" do, and what you can conclude from my cited, given output, the sum of bytes in all these blocks/blk*.dat files is larger than the original bootstrap.dat. So you tell us false.
(and because all except the last are 2^27 bytes in size) you even need not to add up, only consider size modulo 2^27 of bootstarp.dat for a check).
(and because all except the last are 2^27 bytes in size) you even need not to add up, only consider size modulo 2^27 of bootstarp.dat for a check).
You make the wrong assumption that because the file format is the same, the concatenation will be binary identical. In the 0.8 code, the files are pre-allocated in blocks of 16 MiB, to avoid high fragmentation. That means that at the end of those files, you'll have some zero bytes. So the concatenated files will have these zeroes too, and you'll get a slightly larger bootstrap.dat. Both the loading code in 0.7 and 0.8 should be able to deal with holes in the files, though.
See, I didn't lie.
"completeness of the verification" let the user decide what degree he wants. There is an option -checklevel (introduced by yourself, add e.g. a 7 for signature-check if you like, or whatever you like personally to fine-tune control the verification process when block loading) -- I tried do do all these with my blockparser I know bitcoin-0.7.99 does when bootstraping data (to get a fair real-time comparison).
But initialization with the bootstrap.dat which you got from a trusted source, should need no (deep?) verification to judify long real-times!
But initialization with the bootstrap.dat which you got from a trusted source, should need no (deep?) verification to judify long real-times!
-checkblocks is about how much verification you want at startup about the data you already have. I find disabling checks when importing a bootstrap.dat very risky - someone distributing "trusted" files which have an accidental (or deliberate!) error in them is enough to cause a block chain split, which in case of widespread deployment could be devastating for the bitcoin economy. If there was something significant to be gained, it could be made optional with a flag with a big warning on that, but I doubt it will help much (I don't have numbers, and you're welcome to do benchmarks yourself if you want to help), as most time is maintaining the database and not doing checks.
Quote
"As said, not a priority now" -- well I present you quantitative real-time measurement and you judge this is of no importance.
"Yes if you do everything in RAM using a hash map, I'm sure it will be faster (it should!)." Sorry, your 0.7.99 with bootstrap.dat also (could/should?) do everything in RAM, and I wrote already: the write back of the new data-structure in 0.7.99 happens in parallel to the CPU on my system, so no (a very, very negligible) real-time win possible, if no writing back to disk occurs. Your qualitative comment "it will be faster (it should!)", I already estimated quantitatively to be > 10 to give the true magnitudes. :-(
"Yes if you do everything in RAM using a hash map, I'm sure it will be faster (it should!)." Sorry, your 0.7.99 with bootstrap.dat also (could/should?) do everything in RAM, and I wrote already: the write back of the new data-structure in 0.7.99 happens in parallel to the CPU on my system, so no (a very, very negligible) real-time win possible, if no writing back to disk occurs. Your qualitative comment "it will be faster (it should!)", I already estimated quantitatively to be > 10 to give the true magnitudes. :-(
Yes, thank you very much for those numbers. I know there are performance improvements possible, I've told you a zillion times now. This thread is about doing tests, so we can get 0.8 out as soon as possible, because 0.7.x's performance is terrible, and it won't be released before it is stable.
Can we please stop this discussion, and get this thread back to test results?
I did (already yesterday) a "cmp $HOME/.bitcoin.0.7.99/blocks/blk00000.dat $HOME/.bitcoin/blk0001.dat" which results in the (first) difference at byte 134214364. So they can not be simply concatenated to get the block-chain back, right? But maybe I have discovered a bug in the data structure/files.
The old files are limited to (almost) 2GB. The new files are limited to 128MiB. Apart from that, they are exactly the same format, they just store fewer blocks per file. If you concatenate either (in the right order), you get a usable bootstrap.dat
Sorry, I get tired, I just wanted to reply with the 4th, last part, but it looks superflously. Therefore only one obviously point: even if you don't know what "cmp" do, and what you can conclude from my cited, given output, the sum of bytes in all these blocks/blk*.dat files is larger than the original bootstrap.dat. So you tell us false.
(and because all except the last are 2^27 bytes in size) you even need not to add up, only consider size modulo 2^27 of bootstarp.dat for a check).
smtp
3rd part:
My priority is correctness/completeness of the verification, consistency of the database on disk, and minimizing the working set size. That on itself leads to improved performance, but there are certainly a lot of things possible to improve it. As said, not a priority now. Yes if you do everything in RAM using a hash map, I'm sure it will be faster (it should!).
"completeness of the verification" let the user decide what degree he wants. There is an option -checklevel (introduced by yourself, add e.g. a 7 for signature-check if you like, or whatever you like personally to fine-tune control the verification process when block loading) -- I tried do do all these with my blockparser I know bitcoin-0.7.99 does when bootstraping data (to get a fair real-time comparison).
But initialization with the bootstrap.dat which you got from a trusted source, should need no (deep?) verification to judify long real-times!
"As said, not a priority now" -- well I present you quantitative real-time measurement and you judge this is of no importance.
"Yes if you do everything in RAM using a hash map, I'm sure it will be faster (it should!)." Sorry, your 0.7.99 with bootstrap.dat also (could/should?) do everything in RAM, and I wrote already: the write back of the new data-structure in 0.7.99 happens in parallel to the CPU on my system, so no (a very, very negligible) real-time win possible, if no writing back to disk occurs. Your qualitative comment "it will be faster (it should!)", I already estimated quantitatively to be > 10 to give the true magnitudes. :-(
Yes, you can argue, that minimizing your working set has highest priority, and then I should shut up (I use about 2.3 GB totally, because I store all txout-scripts in memory, you need only to keep the unspent in memory, 1/7.5 or less).
BTW: I discovered today I can simply improve my performance by about 15 % if I only suppress all the statistics output for each block. But then my blockparser is limited by the disk-access speed when reading the bootstrap.dat, checking and building up the data structures, not the CPU-speed anymore.
smtp
I think I have shown with my block-parser, that conversion of this data into a bitcoin-qt usable structure can be done only in a few minutes on a typical hardware and not in more than 20 times real time for bitcoin-turbo and checking everything inside the main block chain except the script-verification! Yes, before, 0.7.?, it were more than 200-times of real time, so a great achievement of your new experimental 0.7.99 version.
My priority is correctness/completeness of the verification, consistency of the database on disk, and minimizing the working set size. That on itself leads to improved performance, but there are certainly a lot of things possible to improve it. As said, not a priority now. Yes if you do everything in RAM using a hash map, I'm sure it will be faster (it should!).
"completeness of the verification" let the user decide what degree he wants. There is an option -checklevel (introduced by yourself, add e.g. a 7 for signature-check if you like, or whatever you like personally to fine-tune control the verification process when block loading) -- I tried do do all these with my blockparser I know bitcoin-0.7.99 does when bootstraping data (to get a fair real-time comparison).
But initialization with the bootstrap.dat which you got from a trusted source, should need no (deep?) verification to judify long real-times!
"As said, not a priority now" -- well I present you quantitative real-time measurement and you judge this is of no importance.
"Yes if you do everything in RAM using a hash map, I'm sure it will be faster (it should!)." Sorry, your 0.7.99 with bootstrap.dat also (could/should?) do everything in RAM, and I wrote already: the write back of the new data-structure in 0.7.99 happens in parallel to the CPU on my system, so no (a very, very negligible) real-time win possible, if no writing back to disk occurs. Your qualitative comment "it will be faster (it should!)", I already estimated quantitatively to be > 10 to give the true magnitudes. :-(
Yes, you can argue, that minimizing your working set has highest priority, and then I should shut up (I use about 2.3 GB totally, because I store all txout-scripts in memory, you need only to keep the unspent in memory, 1/7.5 or less).
BTW: I discovered today I can simply improve my performance by about 15 % if I only suppress all the statistics output for each block. But then my blockparser is limited by the disk-access speed when reading the bootstrap.dat, checking and building up the data structures, not the CPU-speed anymore.
smtp
I did (already yesterday) a "cmp $HOME/.bitcoin.0.7.99/blocks/blk00000.dat $HOME/.bitcoin/blk0001.dat" which results in the (first) difference at byte 134214364. So they can not be simply concatenated to get the block-chain back, right? But maybe I have discovered a bug in the data structure/files.
The old files are limited to (almost) 2GB. The new files are limited to 128MiB. Apart from that, they are exactly the same format, they just store fewer blocks per file. If you concatenate either (in the right order), you get a usable bootstrap.dat
Quote
Well, "everything except the block files isn't intended to be used by third party code", together with "It's being replaced to improve performance" this both sounds like old Mircosoft-windows argumentation. :-/ "Bitcoin needs exclusive access to the database" Huch? only if it is run - but this line of argumentation matches the previous.
Obviously you can use it for whatever you like while Bitcoin isn't running. I just mean that compatibility with external applications was not a design priority (except for the block files - they could have been made smaller as well, but we chose not to, in order not to break external applications).
Quote
BTW: Why do I sound so negatively? Because I must think of my horrible long initialiation of the block chain which lasts far more than 23 h real-time last december and you tell me that it is no bottleneck. Sorry, to be frank.
You're sort of hijacking this thread, ranting about things that are not priorities now.
In 0.7.x, block verification WAS the bottleneck (except when you were on SSD or a tmpfs), and that is the reason for all changes that will be in 0.8, and what this thread exists for. I'm just saying that after those, it isn't. Block downloading and signature verification are the bottleneck. And yes, using bootstrap.dat for initialization avoids the problem with slow block downloading, but that's not what you want to be telling new users. The priority should be making automatic syncup usable again.
2nd part:
It's being replaced to improve performance. The file format of the block files (blk000?.dat before, blocks/blk000??.dat now) hasn't changed: it's a binary concatenation of blocks in network format. The coins directory is a LevelDB database in a cusitom compact format that represents the set of unspent transaction output. See the source code (specifically: main.h above, class CCoins) for the exact specification. The rev* files contain data to be able to disconnect blocks afterwards in case of reorganisation. Bitcoin needs exclusive access to the database anyway, so everything except the block files isn't intended to be used by third party code. If you need access to the raw blockchain/utxo data, use the getblock, getrawtransaction and gettxout RPC commands.
I did (already yesterday) a "cmp $HOME/.bitcoin.0.7.99/blocks/blk00000.dat $HOME/.bitcoin/blk0001.dat" which results in the (first) difference at byte 134214364. So they can not be simply concatenated to get the block-chain back, right? But maybe I have discovered a bug in the data structure/files.
Well, "everything except the block files isn't intended to be used by third party code", together with "It's being replaced to improve performance" this both sounds like old Mircosoft-windows argumentation. :-/ "Bitcoin needs exclusive access to the database" Huch? only if it is run - but this line of argumentation matches the previous.
BTW: Why do I sound so negatively? Because I must think of my horrible long initialiation of the block chain which lasts far more than 23 h real-time last december and you tell me that it is no bottleneck. Sorry, to be frank.
smtp
Quote
I also dislike to see it to be replaced (the currently undocumented "blkindex.dat"-format) by new formats in rev*dat, blk*dat, coins-directory (and blktree-diretory?), if these stay undocumented or to be over-complex. Again making it impossible to use directly this raw block chain data.
It's being replaced to improve performance. The file format of the block files (blk000?.dat before, blocks/blk000??.dat now) hasn't changed: it's a binary concatenation of blocks in network format. The coins directory is a LevelDB database in a cusitom compact format that represents the set of unspent transaction output. See the source code (specifically: main.h above, class CCoins) for the exact specification. The rev* files contain data to be able to disconnect blocks afterwards in case of reorganisation. Bitcoin needs exclusive access to the database anyway, so everything except the block files isn't intended to be used by third party code. If you need access to the raw blockchain/utxo data, use the getblock, getrawtransaction and gettxout RPC commands.
I did (already yesterday) a "cmp $HOME/.bitcoin.0.7.99/blocks/blk00000.dat $HOME/.bitcoin/blk0001.dat" which results in the (first) difference at byte 134214364. So they can not be simply concatenated to get the block-chain back, right? But maybe I have discovered a bug in the data structure/files.
Well, "everything except the block files isn't intended to be used by third party code", together with "It's being replaced to improve performance" this both sounds like old Mircosoft-windows argumentation. :-/ "Bitcoin needs exclusive access to the database" Huch? only if it is run - but this line of argumentation matches the previous.
BTW: Why do I sound so negatively? Because I must think of my horrible long initialiation of the block chain which lasts far more than 23 h real-time last december and you tell me that it is no bottleneck. Sorry, to be frank.
smtp
Hi
I should lead-in by saying, "sorry that I pressed you to spend so much real time in this reply - only for me". :-/
I'm not sure what you mean. The current downloading mechanism often takes hours just downloading (not including any verification or storage), a lot of which is waiting and not doing anything. Compare that to (order of magnitude) an hour of verification to reach block 210000 (without signature checks). After block 210000, signature checking becomes the bottleneck. So if we want to improve the experience for new users, the first step should be speeding up the download itself, and the signature verification. After that, we can have a look at further improvements for the verification itself.
And I'm not sure what is (principlely) unclear in my sentences. :-/
You (the newbie) can get the download with maximal speed (his band-width limitation) by simply download a trusted bootstrap.dat! It can't be faster. It is our responsibility to provide in regular (short) time distances these block chains. E.g. each week. So simply!
BTW: I did load bootstrap.dat of the main blockchain until height 216283 once again with your 0.7.99 release (and compiled with -march=athlon64 -O2)
and got 36.5 minutes cpu-time until height 210000 and 96.5 minutes cpu-time until height 216283 which uses a total of 108 min real-time.
(My testing of this -reindex-bug had finally corrupted my blockchain data).
The last 6283 blocks needed exactly 1 h cpu-time or 0.57 sec/block. But better comparing transaction counts not block counts. The first 9344206 tx until block height 210000, could be loaded from bootstrap.dat into the bitcoin-qt data structures with 4266 tx/sec the remaining 1731667 transactions with 481 tx/sec (due to verification checks). Thus, if there would have been a new bootstrap.dat until block height 216283, total real-time would have been only 43 min. Well, my blockparser needs less than 2 min (without sig-checks yields > 92000 tx/sec) , but maybe your deletion of redeemed deposits is expensive (but I doubt). So I guess there is surely a factor 20 (or more) which could be improved (I did no aggressive coding in my parser to reduce cpu or real time).
And I already praised you -- you are faster already by a factor 10 (or even a bit more) compared to version 0.7.1.
BTW: Writing the data new to disk, needs neglectable cpu-time and no further real-time (I see it at the running 0.7.99 because it is done in parallel) , but this I can't do as long as I neither know the structure of blkindex.dat nor of your new structured files in 0.7.99 (I asked for). (A following item).
Sorry, it becomes too late in the night. I will continue tomorrow, discussing the/your following items/responses.
Regards,
smtp
I should lead-in by saying, "sorry that I pressed you to spend so much real time in this reply - only for me". :-/
Sorry, but I think I should disagree strongly! This might to be an (or better the!) important bottleneck for each newbie who want to start to use bitcoin-qt.
You are true, it is no bottleneck for you and probably for > 95% of all forums posters here who has done already the initial download of the blockchain data. "crappy block download and signature validation" becomes the next bottle neck AFTER you have your personal block chain in a bitcoin-client-conform format!
You are true, it is no bottleneck for you and probably for > 95% of all forums posters here who has done already the initial download of the blockchain data. "crappy block download and signature validation" becomes the next bottle neck AFTER you have your personal block chain in a bitcoin-client-conform format!
I'm not sure what you mean. The current downloading mechanism often takes hours just downloading (not including any verification or storage), a lot of which is waiting and not doing anything. Compare that to (order of magnitude) an hour of verification to reach block 210000 (without signature checks). After block 210000, signature checking becomes the bottleneck. So if we want to improve the experience for new users, the first step should be speeding up the download itself, and the signature verification. After that, we can have a look at further improvements for the verification itself.
You (the newbie) can get the download with maximal speed (his band-width limitation) by simply download a trusted bootstrap.dat! It can't be faster. It is our responsibility to provide in regular (short) time distances these block chains. E.g. each week. So simply!
BTW: I did load bootstrap.dat of the main blockchain until height 216283 once again with your 0.7.99 release (and compiled with -march=athlon64 -O2)
and got 36.5 minutes cpu-time until height 210000 and 96.5 minutes cpu-time until height 216283 which uses a total of 108 min real-time.
(My testing of this -reindex-bug had finally corrupted my blockchain data).
The last 6283 blocks needed exactly 1 h cpu-time or 0.57 sec/block. But better comparing transaction counts not block counts. The first 9344206 tx until block height 210000, could be loaded from bootstrap.dat into the bitcoin-qt data structures with 4266 tx/sec the remaining 1731667 transactions with 481 tx/sec (due to verification checks). Thus, if there would have been a new bootstrap.dat until block height 216283, total real-time would have been only 43 min. Well, my blockparser needs less than 2 min (without sig-checks yields > 92000 tx/sec) , but maybe your deletion of redeemed deposits is expensive (but I doubt). So I guess there is surely a factor 20 (or more) which could be improved (I did no aggressive coding in my parser to reduce cpu or real time).
And I already praised you -- you are faster already by a factor 10 (or even a bit more) compared to version 0.7.1.
BTW: Writing the data new to disk, needs neglectable cpu-time and no further real-time (I see it at the running 0.7.99 because it is done in parallel) , but this I can't do as long as I neither know the structure of blkindex.dat nor of your new structured files in 0.7.99 (I asked for). (A following item).
Sorry, it becomes too late in the night. I will continue tomorrow, discussing the/your following items/responses.
Regards,
smtp
Sorry, but I think I should disagree strongly! This might to be an (or better the!) important bottleneck for each newbie who want to start to use bitcoin-qt.
You are true, it is no bottleneck for you and probably for > 95% of all forums posters here who has done already the initial download of the blockchain data. "crappy block download and signature validation" becomes the next bottle neck AFTER you have your personal block chain in a bitcoin-client-conform format!
You are true, it is no bottleneck for you and probably for > 95% of all forums posters here who has done already the initial download of the blockchain data. "crappy block download and signature validation" becomes the next bottle neck AFTER you have your personal block chain in a bitcoin-client-conform format!
I'm not sure what you mean. The current downloading mechanism often takes hours just downloading (not including any verification or storage), a lot of which is waiting and not doing anything. Compare that to (order of magnitude) an hour of verification to reach block 210000 (without signature checks). After block 210000, signature checking becomes the bottleneck. So if we want to improve the experience for new users, the first step should be speeding up the download itself, and the signature verification. After that, we can have a look at further improvements for the verification itself.
Quote
I also dislike to see it to be replaced (the currently undocumented "blkindex.dat"-format) by new formats in rev*dat, blk*dat, coins-directory (and blktree-diretory?), if these stay undocumented or to be over-complex. Again making it impossible to use directly this raw block chain data.
It's being replaced to improve performance. The file format of the block files (blk000?.dat before, blocks/blk000??.dat now) hasn't changed: it's a binary concatenation of blocks in network format. The coins directory is a LevelDB database in a cusitom compact format that represents the set of unspent transaction output. See the source code (specifically: main.h above, class CCoins) for the exact specification. The rev* files contain data to be able to disconnect blocks afterwards in case of reorganisation. Bitcoin needs exclusive access to the database anyway, so everything except the block files isn't intended to be used by third party code. If you need access to the raw blockchain/utxo data, use the getblock, getrawtransaction and gettxout RPC commands.
Quote
I think I have shown with my block-parser, that conversion of this data into a bitcoin-qt usable structure can be done only in a few minutes on a typical hardware and not in more than 20 times real time for bitcoin-turbo and checking everything inside the main block chain except the script-verification! Yes, before, 0.7.?, it were more than 200-times of real time, so a great achievement of your new experimental 0.7.99 version.
My priority is correctness/completeness of the verification, consistency of the database on disk, and minimizing the working set size. That on itself leads to improved performance, but there are certainly a lot of things possible to improve it. As said, not a priority now. Yes if you do everything in RAM using a hash map, I'm sure it will be faster (it should!).
Quote
Please remember: I only started activity in this Bitcoin Forum, because the VERY SLOW initialization with the main block chain by the (most spread) bitcoin-qt client might put off increasingly many want-to-be starters into the bitcoin world.
I'm very aware of the slowness, but changing in the reference code things takes time (to implement, to review and to test) - this slows development down, but I'm sure the community wouldn't want even a blazingly fast release with subtle bugs in it that lead to a split of the network after a large part of the community adopts it. We do what we can, and most of us (including me) just do this in our free time. The real bottleneck is testing, so thanks for helping out here (though I really can't do much about a segfault without more details...).
Oh and by the way, use `qmake RELEASE=1` to build optimized binaries.
I think that it is a terrible legacy of Microsoft (and/or Apple) that various Linux distributions switched to "disable core dumps by default". The old "remove core dumps older than a week by default" was much better, because nobody would use the "program crashes, but not under the debugger" excuse.
The main problem is people don't express precisely what they are talking of or assume environments/dependencies others don't have/use. :-/When checking for "ulimit" on my sytem/environment , I did "man ulimit" and later "which ulimit". So I got my informations (also for ubuntu & SunOS) from the man-pages and from the which/PATH-search. So, should I apologize for not doing "whence ulimit", but "which ulimit", don't I?
ulimit (as typed in the command-line) is a shell-built-in (if you use an appropriate shell!) with all these many options, including option -c for size of core-limit, even in (my) Linux (if you use sh or ksh or bash, but not e.g. in csh or tcsh).
Appendum: There exists also the (obsolete) system/library-call ulimit, see "man ulimit 3".
smtp
I wonder what core precisely is meant.
I apologize I wrote like everyone knows and understands the postmortem debugging.1) I did not grasp your idea, that I must/should force the OS to produce this core-file.
2) You seem to have a different environment (I even don't know your OS), where ulimit has this -c option.
3) We have the rare case, that a program which crashes when invoked by the shell doesn't crash when invoked by gdb.
BTW: I still remember well, when , about 20 years ago, nearly every crash of a program left a core file.
Thanks,
smtp
I wonder what core precisely is meant.
I apologize I wrote like everyone knows and understands the postmortem debugging.$ cat bitcoind.c
#include
int main() { return printf("Hello %s!\n",2112); }
$ make bitcoind
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
$ ulimit -c unlimited
$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
$ ./bitcoind
Segmentation fault (core dumped)
$ ls core*
core
$ gdb ./bitcoind core
GNU gdb (GDB) 7.1-ubuntu
Reading symbols from /home/2112/bitcoind...(no debugging symbols found)...done.
Reading symbols from /lib/libc.so.6...done.
Core was generated by `./bitcoind'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f4f24cd7e32 in _IO_vfprintf_internal (s=0x7f4f2500c780,
format=
1617 vfprintf.c: No such file or directory.
in vfprintf.c
(gdb) where
#0 0x00007f4f24cd7e32 in _IO_vfprintf_internal (s=0x7f4f2500c780,
format=
#1 0x00007f4f24cdf65a in __printf (
format=0xffffe906 ) at printf.c:35
#2 0x000000000040053f in main ()
(gdb)
So on a reasonable OS program doesn't have to be compiled with debugging and/or run under the debugger to approximately locate the place where it crashed.
I think that it is a terrible legacy of Microsoft (and/or Apple) that various Linux distributions switched to "disable core dumps by default". The old "remove core dumps older than a week by default" was much better, because nobody would use the "program crashes, but not under the debugger" excuse.
Again, I want to apologize for writing like everyone already knows and just needed a reminder. Hopefully there will be at least one reader who wasn't familiar with the postmortem concept who now will learn how to override the default in their Linux installation to re-enable to perform good old core dumps. Nowadays core memory can probably be found only in museums, but the core dumps are still useful. Lets debug like it is 1970 again!
3) There occurs no crash in gdb, thus it is not meaningfull (in my context) to talk about "use the debugger after the crash". 
I got another idea. You could compile the source with the "-g" flag and then start your client as normal with the "-reindex"-option hoping still(!) the crash occurs and force the OS to produce a core-file (image of all his allocated memory into a file). Then you could investigate this core-file with gdb afterwards.But I think, before realizing these thoughts, at first sipa must tell us his oppinion in this "-reindex" case.
smtp
Jump to: