 Show Posts
|
|
Pages: [1] 2 3 »
|
Interesting paper. According to it, preimage searches can be faster on quantum computers than on classic computers. BTC mining can be expressed as preimage search, so the extended Grovers algorithm could be applied. The paper sais it is not clear what search complexity is required to reach the tip-over point at which a quantum computer is more efficient. Therefore it isnt clear on which side BTC sits. It may or may not be more efficient. If BTC mining was more efficient on quantum computers, it wouldnt necessarily be the end of BTC. As long as the length of SHA2 hashes permit, quantum mining rigs will be dealt with by difficulty adjustments. Just like GPU, FPGA, ASIC technology each is so much more efficient than the previous generations. The network has compensated for all of them and is still running as designed. There is a maximum possible difficulty though. Only when the network hashing power gets beyond that point, BTC mining is broken. Until then: business as usual. Other areas of BTC (such as the public key crypto) are probably much more vulnerable to quantum computers than the mining process. |
|
|
|
BIP 34 - block height in coinbase Is there any web service to see the current ratio of v1 / v2? Not AFAIK. If you have access to a bitcoin node, the debug.log file will show SetBestChain: some_number of last 100 blocks above version 1
Good to know. However it won't help as guide for people who are reluctant to update until absolutely necessary - because we won't get this message in our old clients' debug.log right? I think only a web service can solve this dilema, or a friendly soul who has already updated and posts his debug.log information from time to time for us to see and consider. |
|
|
|
|
Hi,
This is an issue that is plaguing me since months, and I'd like to ask if there is any solution to it.
Often, when I try to send a large amount of BTC, I get the following message:
error: {"code":-4,"message":"Error: Transaction creation failed "}
If this error happens, I try sending a smaller amount. Eventually this succeeds. There is always a treshold below which the transaction can be created successfully. However the treshold is not a static value, but rather depends on some internal details of my wallet. Sometimes the treshold is lower than 1 BTC, sometimes it is near 200 BTC. After each successful send, the treshold jumps a different value (higher or lower). I cannot send more than 200 BTC ever anymore since the problem started to appear, and it becomes worse and worse with time.
After googling this forum and other sites, my understanding is that the error occurs because the transaction becomes too complex. The source of it seems to be "wallet pollution" where many small inputs exist and bitcoind wants to combine too many of them into the transaction.
My wallet file is 2.3 MB, and certainly there may be many small items in it. However there are also plenty of large items that could be used to form the desired transaction (without reaching the excessive complexity). Bitcoind seems to use a poor strategy in choosing the inputs from the available ones.
The problem appears accross many versions of bitcoin, including v0.3.x and v0.6.3, and on several machines. It never appears on a fresh install, only starts to appear after the wallet has grown a lot, and then becomes worse with time.
My questions:
1. Do I have some way to influence which inputs are chosen? For example, can I choose 10 "virgin" coins for a 500 BTC transaction, instead of thousands of 0.01xxx inputs?
2. Can I somehow view the details of my wallet? I imagine that I could send the offending small inputs away to a different wallet, if I only knew their exact face value and the order in which they appear in the wallet.
3. Is there any other way to "clean" my wallet, or reorder the items in it so that the offending items will be selected last instead of first?
I am living with the problem, but it gets worse and worse every week. I cannot ignore it much longer. Right now I am thinking about this resolution strategy: Fresh install on a new box. Try to send 99.9 BTC to the new box. If fails, decrease the amount by 0.1 BTC and retry (until success). Start over with 99.9. Continue until the wallet is empty or near empty. Delete the remaining wallet file. Obviously this method is costly because of the TX fees involved.
|
|
|
|
BIP 34 - block height in coinbase Is there any web service to see the current ratio of v1 / v2? |
|
|
|
On the other hand, using the lower hash opens the door to new attacks: if I find a block with a super-low hash, I can just wait to broadcast it until someone else finds it with a higher hash, and instant-orphan them! If you find a block with a super-low hash, you can just broadcast it right away and you GET THE REWARD. There is no incentive to hold the block back, and play chances. The chances would be to have to compete against a later block, which could turn out to be an even lower hash. You can calculate those chances (based on difficulty and your super-low hash), but they never turn out favorably against the guaranteed reward. Also, how do you know that similar schemes are not already active? I assume your pool doesnt do it, based on what you write in the post I am replying to. But there is plenty of evidence that blocks are not just elected by arrival time (standard client). The two blocks mentioned here in this thread can serve as example. Blockchain.info RX timestamps were half an hour apart, yet based on same clock source. There was no 3rd block at this height, so we can safely assume that Deepbit has either not known, or voluntarily ignored the new block for half an hour. Do you really think that network propagation has caused this phenomena? Or rather it suggests that Deepbit used a different election criteria than arrival time ... Think about it. EDIT: The block in question is 183255. If you look at the preceding block 183254, you will notice that blockchain.info tags it as Deepbit too. The same goes for the superceding block 183256. We are looking at a chain of blocks from Deepbit, with a silenced attempt of interruption by someone else. But Deepbit "pokered" during half an hour, and eventually killed the competitor. What was the algorithm used? It isnt the standard client, so tell me. |
|
|
|
Another coding optimization would be if you receive a second block solution, to immediately discard the first and push out the newer one if it has a significantly smaller hash, of course still keeping track of both as valid work from miners.
Chain proof-of-work is calculated based on the hash target, so if you get another block at the same height there is no benefit to keeping the one with "the smaller hash". Maybe if you receive a second block solution, keeping the block that removes the most transactions from the memory pool would be the right "good for the entire ecosystem" policy. Using "the smaller hash" has a benefit: It is unambiguous! Orphans are the result of a network split (different portions of the network consider a different block as the best current block). If a client knows two blocks and has to decide, using the smaller hash will always lead to the same decision. This works towards the goal of reducing orphans (reducing the occurrance of differing decisions on distinct clients). Your proposal of using the "most beneficious block" does not necessarily fulfill this goal. Since transactions themselves suffer similar network split problems, two distinct clients can make differing decisions about the same set of blocks. Thus leading to the same result: orphans. In fact, your solution may possibly produce more orphans than before. In the past I have thought about the propagation problem as well, but refrained from posting a formal proposal so far. However, I came to a similar result. The single best solution is to use the "smaller hash" (as in "more work" or better: "more luck") which is universally testable for everyone who knows the same particular set of competing blocks. Also, in my thoughts, it makes sense to consider a maximum expected propagation time. A block will typically take no more than N seconds to propagate to most clients. I made calculations, extrapolated from number of hops, current network size, but dont remember the exact outcome. Whatever the best value of N is does not matter here. What matters is that when a client first receives a block of new height, it should open a "propagation curtesy window" of N seconds. When a competing block is received within that window, then it can be reasonably considered potential victim of network skew and a resolution can be made by prefering the "lower hash" block. If a competing block is received outside of the N seconds window, it can be disregarded(like now). It can't be victim of just network skew (unless N was poorly chosen). The advantage is obvious. Mostly everyone will work on the same block, even in situations that currently produce an orphan. AND, the proposal is completely voluntary and 100% compatible. Nobody would be able to tell whether or not you have implemented it (unless he is monitoring your network traffic and sees in which order you have really received the blocks). This is the best proof for compatibility. There is no disadvantage to the current system. The more miners implement it, the lower the orphan rate goes. And last not least, this approach doesn't open a security vulnerability either. It is more difficult to create a block with "lower hash" than to create a "just enough" block with better height. Therefore there is no benefit of trying to create "lower hash" blocks for already existing blocks. Since this method relies on nothing else but the block hash, is is "unhackable". Your proposal however does not have this property. It also depends on the transaction memory pool, which can easily be poisoned. I have thought about it since about 3 months, and I am absolutely convinced that it is the universally best solution. |
|
|
|
|
Again I'm looking for a reliable partner who can turn BTC into wire transfers (EUR or USD) on a regular basis. Specifically I'm interested in a solid, honest, long-term business relationship.
If you are interested, please send me a private message here on the forum.
|
|
|
|
|
The purpose of mining is to secure the blockchain.
Orphans are not part of the blockchain.
If there was a reward for producing orphans, it would draw resources away from the blockchain (main purpose of mining). At the very least, people would be lax about optimizing their setups and we would see more orphans as result. In the worst case, we could even suffer attacks.
Also, it adds unnecessary complexity to the software. An orphaned block is a block that does not follow the rules of bitcoin. Even if everything else is correct, it was not based on the latest valid block at the time of creation. But there might be more problems with the block. We would need a special (exceptional) verification function to find out.
And last not least: Properly verified, an orphan still represents "proof of work", although not for work towards the main blockchain. However, it wouldn't indicate any "speed of hashing" anymore as we have now. Even the slowest miner can produce an orphan, given enough time. Under your hypothetical proposal, we'd only know that work has been done. We wouldn't know whether it EVER had the slighest chance to be actually useful for the blockchain.
There is nothing to reward unless proof is shown that the blockchain is now more secure than before.
|
|
|
|
run it in gdb, and use the "bt" command when a segfault occurs. Make sure to enable thread tracing, if that is not default / built in.
Ok, so this is a crash with v0.6.0 release at around 6am today. I still dont know how to enable thread tracing, so I hope it was just enable by default (?). The backbuffer of -debug -printtoconsole looks quite normal: Added 1 addresses from 91.154.226.179: 3470 tried, 11409 new
04/08/12 04:06:56 sending: addr (31 bytes)
04/08/12 04:06:57 received: addr (31 bytes)
04/08/12 04:06:57 sending: addr (31 bytes)
04/08/12 04:06:59 sending: addr (31 bytes)
04/08/12 04:07:00 sending: addr (31 bytes)
04/08/12 04:07:00 sending: addr (31 bytes)
04/08/12 04:07:01 sending: addr (31 bytes)
04/08/12 04:07:03 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 new
askfor tx 46003e4d1f5d3985d710 0
sending getdata: tx 46003e4d1f5d3985d710
04/08/12 04:07:03 sending: getdata (37 bytes)
04/08/12 04:07:03 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 new
askfor tx 46003e4d1f5d3985d710 1333858023000000
04/08/12 04:07:03 received: tx (258 bytes)
Rate limit dFreeCount: 13149.2 => 13407.2
AcceptToMemoryPoolUnchecked(): size 132
AcceptToMemoryPool(): accepted 46003e4d1f
04/08/12 04:07:03 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:03 sending: inv (37 bytes)
04/08/12 04:07:03 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:03 sending: inv (37 bytes)
04/08/12 04:07:04 sending: inv (37 bytes)
04/08/12 04:07:04 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:04 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:04 sending: inv (37 bytes)
04/08/12 04:07:04 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:04 sending: inv (37 bytes)
04/08/12 04:07:04 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:04 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:04 sending: inv (37 bytes)
04/08/12 04:07:04 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:04 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:05 sending: inv (37 bytes)
04/08/12 04:07:05 sending: inv (37 bytes)
04/08/12 04:07:05 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:05 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:05 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:05 sending: inv (37 bytes)
04/08/12 04:07:06 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:06 sending: inv (37 bytes)
04/08/12 04:07:07 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:10 received: inv (37 bytes)
got inventory: tx 46003e4d1f5d3985d710 have
04/08/12 04:07:12 received: addr (31 bytes)
04/08/12 04:07:12 sending: addr (31 bytes)
04/08/12 04:07:16 sending: addr (31 bytes)
04/08/12 04:07:17 received: addr (31 bytes)
04/08/12 04:07:18 sending: addr (31 bytes)
04/08/12 04:07:19 received: addr (31 bytes)
*** glibc detected *** /home/btc/bitcoind: free(): invalid next size (fast): 0x0000000000d9ffa0 ***
Now comes a dump that was made automatically. It looks similar to what I mentioned that had happened already once to me: ======= Backtrace: =========
[0x7f346b]
[0x7f7516]
[0x40f013]
[0x40f2d8]
[0x40e0ee]
[0x40e3dc]
[0x46d2b4]
[0x470620]
[0x48e435]
[0x48e645]
[0x751edd]
[0x810329]
======= Memory map: ========
00400000-0099b000 r-xp 00000000 fd:02 181991 /home/USERNAME/bitcoind
00b9a000-00bab000 rwxp 0059a000 fd:02 181991 /home/USERNAME/bitcoind
00bab000-038dc000 rwxp 00bab000 00:00 0
038dc000-038dd000 rwxp 038dc000 00:00 0
038dd000-04cb9000 rwxp 038dd000 00:00 0
40000000-40001000 ---p 40000000 00:00 0
40001000-40a01000 rwxp 40001000 00:00 0
40a01000-40a02000 ---p 40a01000 00:00 0
40a02000-41402000 rwxp 40a02000 00:00 0
41402000-41403000 ---p 41402000 00:00 0
41403000-41e03000 rwxp 41403000 00:00 0
41e03000-41e04000 ---p 41e03000 00:00 0
41e04000-42804000 rwxp 41e04000 00:00 0
42804000-42805000 ---p 42804000 00:00 0
42805000-43205000 rwxp 42805000 00:00 0
43205000-43206000 ---p 43205000 00:00 0
43206000-43c06000 rwxp 43206000 00:00 0
43c06000-43c07000 ---p 43c06000 00:00 0
43c07000-44607000 rwxp 43c07000 00:00 0
44607000-44608000 ---p 44607000 00:00 0
44608000-45008000 rwxp 44608000 00:00 0
45008000-45009000 ---p 45008000 00:00 0
45009000-45a09000 rwxp 45009000 00:00 0
2aaaaaaab000-2aaaaaaae000 r-xp 2aaaaaaab000 00:00 0 [vdso]
2aaaaaaae000-2aaaae07c000 r-xp 00000000 fd:00 4475090 /usr/lib/locale/locale-archive
2aaaae07c000-2aaaae083000 r-xs 00000000 fd:00 8786 /usr/lib64/gconv/gconv-modules.cache
2aaaae083000-2aaaae085000 rwxp 2aaaae083000 00:00 0
2aaaae085000-2aaaae08b000 rwxs 00000000 fd:02 37965938 /home/USERNAME/.bitcoin/__db.001
2aaaae08b000-2aaaae281000 rwxs 00000000 fd:02 37965939 /home/USERNAME/.bitcoin/__db.002
2aaaae281000-2aaab01c3000 rwxs 00000000 fd:02 37965940 /home/USERNAME/.bitcoin/__db.003
2aaab01c3000-2aaab02e3000 rwxs 00000000 fd:02 37965941 /home/USERNAME/.bitcoin/__db.004
2aaab02e3000-2aaab08e9000 rwxs 00000000 fd:02 37965942 /home/USERNAME/.bitcoin/__db.005
2aaab08e9000-2aaab08f5000 rwxs 00000000 fd:02 37965943 /home/USERNAME/.bitcoin/__db.006
2aaab08fb000-2aaab0905000 r-xp 00000000 09:01 130597 /lib64/libnss_files-2.5.so
2aaab0905000-2aaab0b04000 ---p 0000a000 09:01 130597 /lib64/libnss_files-2.5.so
2aaab0b04000-2aaab0b05000 r-xp 00009000 09:01 130597 /lib64/libnss_files-2.5.so
2aaab0b05000-2aaab0b06000 rwxp 0000a000 09:01 130597 /lib64/libnss_files-2.5.so
2aaab0b06000-2aaab0c53000 r-xp 00000000 09:01 130565 /lib64/libc-2.5.so
2aaab0c53000-2aaab0e53000 ---p 0014d000 09:01 130565 /lib64/libc-2.5.so
2aaab0e53000-2aaab0e57000 r-xp 0014d000 09:01 130565 /lib64/libc-2.5.so
2aaab0e57000-2aaab0e58000 rwxp 00151000 09:01 130565 /lib64/libc-2.5.so
2aaab0e58000-2aaab0e5d000 rwxp 2aaab0e58000 00:00 0
2aaab0e5d000-2aaab0e79000 r-xp 00000000 09:01 130587 /lib64/ld-2.5.so
2aaab0e79000-2aaab1079000 ---p 0001c000 09:01 130587 /lib64/ld-2.5.so
2aaab1079000-2aaab107a000 r-xp 0001c000 09:01 130587 /lib64/ld-2.5.so
2aaab107a000-2aaab107b000 rwxp 0001d000 09:01 130587 /lib64/ld-2.5.so
2aaab107b000-2aaab117b000 rwxp 2aaab107b000 00:00 0
2aaab117b000-2aaab117f000 r-xp 00000000 09:01 130596 /lib64/libnss_dns-2.5.so
2aaab117f000-2aaab137e000 ---p 00004000 09:01 130596 /lib64/libnss_dns-2.5.so
2aaab137e000-2aaab137f000 r-xp 00003000 09:01 130596 /lib64/libnss_dns-2.5.so
2aaab137f000-2aaab1380000 rwxp 00004000 09:01 130596 /lib64/libnss_dns-2.5.so
2aaab1380000-2aaab1391000 r-xp 00000000 09:01 130606 /lib64/libresolv-2.5.so
2aaab1391000-2aaab1591000 ---p 00011000 09:01 130606 /lib64/libresolv-2.5.so
2aaab1591000-2aaab1592000 r-xp 00011000 09:01 130606 /lib64/libresolv-2.5.so
2aaab1592000-2aaab1593000 rwxp 00012000 09:01 130606 /lib64/libresolv-2.5.so
2aaab1593000-2aaab1595000 rwxp 2aaab1593000 00:00 0
2aaab2117000-2aaab272f000 rwxp 2aaab2117000 00:00 0
2aaab4000000-2aaab5e3d000 rwxp 2aaab4000000 00:00 0
2aaab5e3d000-2aaab8000000 ---p 2aaab5e3d000 00:00 0
7ffffffea000-7ffffffff000 rwxp 7ffffffe9000 00:00 0 [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vsyscall]
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x43c05940 (LWP 1393)]
0x000000000082ce95 in raise ()
When I use the bt command, I get this: #0 0x000000000082ce95 in raise ()
#1 0x00000000007cfb10 in abort ()
#2 0x00000000007eaaeb in __libc_message ()
#3 0x00000000007f346b in _int_free ()
#4 0x00000000007f7516 in free ()
#5 0x000000000040f013 in erase (this=0xbab918, __first=<value optimized out>, __last=...)
at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/ext/new_allocator.h:94
#6 std::_Rb_tree<CNetAddr, std::pair<CNetAddr const, int>, std::_Select1st<std::pair<CNetAddr const, int> >, std::less<CNetAddr>, std::allocator<std::pair<CNetAddr const, int> > >::erase (this=0xbab918, __first=<value optimized out>, __last=...)
at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:1281
#7 0x000000000040f2d8 in std::_Rb_tree<CNetAddr, std::pair<CNetAddr const, int>, std::_Select1st<std::pair<CNetAddr const, int> >, std::less<CNetAddr>, std::allocator<std::pair<CNetAddr const, int> > >::erase (this=0xbab918, __x=<value optimized out>)
at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:1215
#8 0x000000000040e0ee in erase (this=0xbab8a0, nUBucket=<value optimized out>)
at /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_map.h:461
#9 CAddrMan::ShrinkNew (this=0xbab8a0, nUBucket=<value optimized out>) at addrman.cpp:181
#10 0x000000000040e3dc in CAddrMan::Add_ (this=0xbab8a0, addr=<value optimized out>, source=<value optimized out>, nTimePenalty=<value optimized out>)
at addrman.cpp:346
#11 0x000000000046d2b4 in ProcessMessage (pfrom=0x2aaab4bb0450, strCommand=..., vRecv=...) at addrman.h:433
#12 0x0000000000470620 in ProcessMessages (pfrom=0x2aaab4bb0450) at main.cpp:2767
#13 0x000000000048e435 in ThreadMessageHandler2 (parg=<value optimized out>) at net.cpp:1516
#14 0x000000000048e645 in ThreadMessageHandler (parg=0x0) at net.cpp:1481
#15 0x0000000000751edd in start_thread ()
#16 0x0000000000810329 in clone ()
I have to leave for a few hours, but will keep the debugger open. If there are any commands that can extract more useful information from it, please post here and I will run them on it tonight. Edit: Added code tags (good idea). BTW, the box is still up, for if anyone wants to see the output of another gdb command, memory dump, etc. |
|
|
|
RE: filling addr.dat: that is one of the denial-of-service attacks fixed by the 0.6 release.
I am running both 0.6.0 release and the master from Apr-03 (which is shortly afterwards). Yet I get these addr.dat errors. There must be another bug to fix in addr.dat Today I got two other crashes, one of them in gdb. I will post it in a separate post, so that my point about addr.dat doesnt get drowned. |
|
|
|
Did you compile from source or are you using the binaries we compiled?
The "CBlock::ReadFromDisk() : OpenBlockFile failed" is very odd, that should never happen. You aren't running with a -datadir on a network drive or something are you? Compiled from source. The datadir is on the local disk (LVM volume on the same physical disk as the OS). run it in gdb, and use the "bt" command when a segfault occurs. Make sure to enable thread tracing, if that is not default / built in.
Thanks, I will do that. One doubt though. How can I enable thread tracing, or check whether it is enabled by default? Google tells me to use ptrace instead of gdb for thread tracing, but I suspect this is not what you want me to do. |
|
|
|
|
What about this one:
Bitcoin version 0.6.0.99-beta
Default data directory /home/USERNAME/.bitcoin
Loading addresses...
dbenv.open strLogDir=/home/USERNAME/.bitcoin/database strErrorFile=/home/USERNAME/.bitcoin/db.log
************************
EXCEPTION: NSt8ios_base7failureE
CDataStream::read() : end of data
bitcoin in AppInit()
Result code is 134 and it repeats like this until I delete addr.adt
Apparently addr.dat can also be filled with "poisonous data" from remote. Good way to take offline your competitors.
|
|
|
|
Look to me like it could be either disk corruption or someone flooding your node with an invalid tx. I think you mentioned that you have already blown away the block database once, but if you haven't that would be something to try.
Disk corruption is not likely. The two boxes have different hardware, different blockdevs, even different filesystems. Wipe database, yes I did this already. About your other suspicion: flood with invalid tx -> crash == DoS attack vector. The goold old 3.xx branch was rock stable, and now we are FORCED to use software which has less than a week of testing (and many obvious problems already visible). |
|
|
|
Another good one: ... version message: version 40000, blocks=174571
04/06/12 21:31:23 received: verack (0 bytes)
04/06/12 21:31:23 received: block (7123 bytes)
received block 00000000000008506c9e
SetBestChain: new best=00000000000008506c9e height=174572 work=286071818980138056873
ProcessBlock: ACCEPTED
04/06/12 21:31:23 received: inv (37 bytes)
got inventory: tx 2218b46d9523b7a39653 new
askfor tx 2218b46d9523b7a39653 0
sending getdata: tx 2218b46d9523b7a39653
04/06/12 21:31:23 sending: getdata (37 bytes)
04/06/12 21:31:23 received: block (7123 bytes)
received block 00000000000008506c9e
ERROR: ProcessBlock() : already have block 174572 00000000000008506c9e
04/06/12 21:31:23 sending: inv (37 bytes)
04/06/12 21:31:23 sending: inv (37 bytes)
04/06/12 21:31:23 sending: inv (37 bytes)
04/06/12 21:31:23 sending: inv (37 bytes)
04/06/12 21:31:23 sending: addr (31 bytes)
04/06/12 21:31:23 sending: inv (37 bytes)
04/06/12 21:31:23 sending: inv (37 bytes)
04/06/12 21:31:23 received: inv (37 bytes)
got inventory: block 00000000000008506c9e have
askfor block 00000000000008506c9e 0
04/06/12 21:31:23 sending: inv (37 bytes)
04/06/12 21:31:23 sending: inv (37 bytes)
04/06/12 21:31:23 sending: inv (37 bytes)
04/06/12 21:31:23 received: tx (620 bytes)
Rate limit dFreeCount: 728.562 => 1348.56
AcceptToMemoryPoolUnchecked(): size 5
AcceptToMemoryPool(): accepted 2218b46d95
04/06/12 21:31:24 received: inv (37 bytes)
got inventory: block 00000000000008506c9e have
askfor block 00000000000008506c9e 1333747883000000
04/06/12 21:31:24 sending: inv (37 bytes)
04/06/12 21:31:24 sending: inv (37 bytes)
04/06/12 21:31:24 received: inv (37 bytes)
got inventory: tx 2218b46d9523b7a39653 have
04/06/12 21:31:24 sending: inv (37 bytes)
04/06/12 21:31:24 sending: inv (37 bytes)
04/06/12 21:31:24 sending: inv (37 bytes)
04/06/12 21:31:25 received: inv (37 bytes)
got inventory: tx 2218b46d9523b7a39653 have
04/06/12 21:31:26 sending: inv (37 bytes)
04/06/12 21:31:26 Flushing wallet.dat
Flushed wallet.dat 19ms
04/06/12 21:31:26 sending: inv (37 bytes)
04/06/12 21:31:26 sending: inv (37 bytes)
04/06/12 21:31:26 received: addr (5851 bytes)
Segmentation fault
The returncode is 139 at this point. Note how at one point is sais received block 00000000000008506c9e, then it sais error, already have 00000000000008506c9e. Then shortly after it sais ask for block 00000000000008506c9e and shortly after it just segfaults. Edit: added code tags |
|
|
|
Please file bug reports on the github issue tracker. Include enough information so we can reproduce the problem (what platform? what seems to cause the problem? etc) and it might get fixed. Another crash happened today, same platform etc. This time it ran with -printtoconsole (no -debug). The scrollback buffer is filled with hundreds of received getdata for: tx 7680e65403ab1b258887
.. then: received getdata for: tx 7680e65403ab1b258887
received getdata for: tx 7680e65403ab1b258887
trying connection 81.176.229.178:8333 lastseen=-2.5hrs
connect() failed after select(): Connection refused
received getdata for: tx 7680e65403ab1b258887
received getdata for: tx 7680e65403ab1b258887
received getdata for: tx 7680e65403ab1b258887
received getdata for: tx 7680e65403ab1b258887
received getdata for: tx 7680e65403ab1b258887
received getdata for: tx 7680e65403ab1b258887
askfor tx 263d4ec0b5712e6e1b47 0
sending getdata: tx 263d4ec0b5712e6e1b47
trying connection 141.106.36.16:8333 lastseen=-3.9hrs
connect() failed after select(): Connection refused
received getdata for: tx 7680e65403ab1b258887
askfor tx 263d4ec0b5712e6e1b47 1333717043000000
askfor tx 263d4ec0b5712e6e1b47 1333717163000000
askfor tx 263d4ec0b5712e6e1b47 1333717283000000
askfor tx 263d4ec0b5712e6e1b47 1333717403000000
askfor tx 263d4ec0b5712e6e1b47 1333717523000000
askfor tx 263d4ec0b5712e6e1b47 1333717643000000
askfor tx 263d4ec0b5712e6e1b47 1333717763000000
askfor tx 263d4ec0b5712e6e1b47 1333717883000000
askfor tx 263d4ec0b5712e6e1b47 1333718003000000
askfor tx 263d4ec0b5712e6e1b47 1333718123000000
AcceptToMemoryPoolUnchecked(): size 22
AcceptToMemoryPool(): accepted 263d4ec0b5
received getdata for: tx 7680e65403ab1b258887
received getdata for: tx 7680e65403ab1b258887
trying connection 69.119.102.53:8333 lastseen=-2.9hrs
sending getdata: tx 35f44d3defc623e850d4
received getdata for: tx 89c54bace5d7221fb8e2
ERROR: AcceptToMemoryPool() : not enough fees
received getdata for: tx 7680e65403ab1b258887
Added 1 addresses from 74.58.231.130: 3415 tried, 8183 new
Added 1 addresses from 95.211.10.8: 3415 tried, 8183 new
received getdata for: tx 7680e65403ab1b258887
askfor tx fee32af70d821d823ba6 0
sending getdata: tx fee32af70d821d823ba6
askfor tx fee32af70d821d823ba6 1333717046000000
askfor tx fee32af70d821d823ba6 1333717166000000
askfor tx fee32af70d821d823ba6 1333717286000000
askfor tx fee32af70d821d823ba6 1333717406000000
askfor tx fee32af70d821d823ba6 1333717526000000
AcceptToMemoryPoolUnchecked(): size 23
AcceptToMemoryPool(): accepted fee32af70d
received getdata for: tx fee32af70d821d823ba6
Added 1 addresses from 91.95.240.5: 3415 tried, 8183 new
Added 1 addresses from 68.38.31.2: 3415 tried, 8183 new
askfor tx a817688a1f0463c40287 0
sending getdata: tx a817688a1f0463c40287
askfor tx a817688a1f0463c40287 1333717048000000
askfor tx a817688a1f0463c40287 1333717168000000
connection timeout
askfor tx a817688a1f0463c40287 1333717288000000
accepted connection 147.133.197.3:64460
askfor tx a817688a1f0463c40287 1333717408000000
askfor tx a817688a1f0463c40287 1333717528000000
askfor tx a817688a1f0463c40287 1333717648000000
AcceptToMemoryPoolUnchecked(): size 24
AcceptToMemoryPool(): accepted a817688a1f
version message: version 32300, blocks=174516
trying connection 83.101.77.156:8333 lastseen=-3.7hrs
connect() failed after select(): Connection refused
received getdata for: tx a817688a1f0463c40287
received getdata for: tx a817688a1f0463c40287
askfor tx 9258e72d561e900d9f43 0
sending getdata: tx 9258e72d561e900d9f43
AcceptToMemoryPoolUnchecked(): size 25
AcceptToMemoryPool(): accepted 9258e72d56
received getdata for: tx 8d0bb79790fb657abcf5
trying connection 80.109.36.181:8333 lastseen=-2.1hrs
connect() failed after select(): Connection refused
trying connection 75.71.123.118:8333 lastseen=-2.8hrs
askfor tx 92422eb05a06de269337 0
sending getdata: tx 92422eb05a06de269337
askfor tx 92422eb05a06de269337 1333717051000000
askfor tx 92422eb05a06de269337 1333717171000000
askfor tx 92422eb05a06de269337 1333717291000000
askfor tx 92422eb05a06de269337 1333717411000000
askfor tx 92422eb05a06de269337 1333717531000000
askfor tx 92422eb05a06de269337 1333717651000000
askfor tx 92422eb05a06de269337 1333717771000000
askfor tx 92422eb05a06de269337 1333717891000000
askfor tx 92422eb05a06de269337 1333718011000000
askfor tx 92422eb05a06de269337 1333718131000000
askfor tx 92422eb05a06de269337 1333718251000000
askfor tx 92422eb05a06de269337 1333718371000000
AcceptToMemoryPoolUnchecked(): size 26
AcceptToMemoryPool(): accepted 92422eb05a
askfor tx 4119e666abec78284fa8 0
sending getdata: tx 4119e666abec78284fa8
askfor tx 4119e666abec78284fa8 1333717053000000
askfor tx 1c7736165bd767d36f81 0
sending getdata: tx 1c7736165bd767d36f81
AcceptToMemoryPoolUnchecked(): size 27
AcceptToMemoryPool(): accepted 4119e666ab
AcceptToMemoryPoolUnchecked(): size 28
AcceptToMemoryPool(): accepted 1c7736165b
Added 1 addresses from 128.211.220.133: 3415 tried, 8181 new
connection timeout
trying connection 85.134.121.91:8333 lastseen=-2.7hrs
received getdata for: tx bc7df6ba49c3f73c67b5
received getdata for: tx 0824d52714585ec7b346
Added 1 addresses from 174.29.73.225: 3415 tried, 8180 new
askfor tx 4c999081f337a76825bb 0
sending getdata: tx 4c999081f337a76825bb
askfor tx 4c999081f337a76825bb 1333717059000000
askfor tx 4c999081f337a76825bb 1333717179000000
askfor tx 4c999081f337a76825bb 1333717299000000
askfor tx 4c999081f337a76825bb 1333717419000000
askfor tx 4c999081f337a76825bb 1333717539000000
askfor tx 4c999081f337a76825bb 1333717659000000
askfor tx 4c999081f337a76825bb 1333717779000000
askfor tx 4c999081f337a76825bb 1333717899000000
askfor tx 4c999081f337a76825bb 1333718019000000
AcceptToMemoryPoolUnchecked(): size 29
AcceptToMemoryPool(): accepted 4c999081f3
Added 1 addresses from 58.38.114.57: 3415 tried, 8180 new
Added 1 addresses from 86.171.229.45: 3415 tried, 8179 new
connection timeout
trying connection 24.199.159.83:8333 lastseen=-3.6hrs
Added 1 addresses from 71.125.32.246: 3415 tried, 8178 new
Added 1 addresses from 131.93.72.31: 3415 tried, 8179 new
connection timeout
Added 1 addresses from 76.117.220.29: 3415 tried, 8177 new
trying connection 78.159.58.51:8333 lastseen=-3.5hrs
connected 78.159.58.51:8333
Added time data, samples 200, offset -17 (+0 minutes)
Moving 78.159.58.51:8333 to tried
version message: version 32300, blocks=174521
trying connection 95.27.140.103:8333 lastseen=-3.3hrs
Added 8 addresses from 78.159.58.51: 3415 tried, 8170 new
connection timeout
Added 1 addresses from 98.182.22.232: 3415 tried, 8168 new
trying connection 194.226.8.27:8333 lastseen=-2.1hrs
received getdata for: block 0000000000000504f773
ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed
socket closed
disconnecting node 109.75.176.70:8333
... Added 1 addresses from 76.117.220.29: 3415 tried, 8128 new
accepted connection 86.47.17.210:10890
Added time data, samples 200, offset -4 (+0 minutes)
Added 86.47.17.210:8333 from 86.47.17.210: 3415 tried, 8127 new
Moving 86.47.17.210:8333 to tried
version message: version 60000, blocks=167425
connection timeout
trying connection 117.22.50.36:8333 lastseen=-2.2hrs
connected 117.22.50.36:8333
trying connection 84.232.230.105:8333 lastseen=-2.0hrs
connect() failed after select(): Connection refused
trying connection 82.170.160.25:8333 lastseen=-2.1hrs
getblocks 166650 to 000000000000027f4096 limit 500
ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed
ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed
.. and now I get literally hundreds of this: ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed
.. after which it continues like this: ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed
ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed
ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed
getblocks stopping at limit 167149 00000000000003251788 (40500 bytes)
received getdata for: tx 1b356369085657c7ace4
received getdata for: tx 8c50e82b2748528264cf
received getdata for: tx 2198ff40554b152b1a79
received getdata for: tx 828a38228f1721fece77
received getdata for: tx d4a4a2a23faebe9f6e62
received getdata for: tx 227eb66590575d626827
received getdata for: tx f3bc2efde58857ee9e66
received getdata for: tx 905f4ec6f080f66ffd0e
received getdata for: tx cc2fa59268afb6437f27
received getdata for: tx 8204e14270077c5cbf76
received getdata for: tx 5a3e47b43ce378aad707
received getdata for: tx 09a5d50c49714bafeaf8
received getdata for: tx 89c99876c87ccddea130
received getdata for: tx 16b0eedcbe030dc75129
received getdata for: block 0000000000000706fb4a
ERROR: CBlock::ReadFromDisk() : OpenBlockFile failed
received getdata for: tx a26d8f23d50b8ede2221
Added 1 addresses from 213.151.89.23: 3416 tried, 8123 new
connection timeout
socket closed
disconnecting node 68.12.223.12:8333
trying connection 77.93.86.5:8333 lastseen=-9.3hrs
connect() failed after select(): No route to host
trying connection 92.30.18.217:8333 lastseen=-2.7hrs
Added 1 addresses from 24.84.96.223: 3416 tried, 8119 new
Added 1 addresses from 68.53.153.158: 3416 tried, 8120 new
Added 1 addresses from 216.150.78.34: 3416 tried, 8120 new
connection timeout
trying connection 78.42.219.156:8333 lastseen=-2.2hrs
connected 78.42.219.156:8333
trying connection 86.93.165.82:8333 lastseen=-3.2hrs
askfor tx cc18e6dd56b2ac029bb1 0
sending getdata: tx cc18e6dd56b2ac029bb1
askfor tx cc18e6dd56b2ac029bb1 1333717155000000
askfor tx cc18e6dd56b2ac029bb1 1333717275000000
received getdata for: tx 7112939b80c44093c5cc
askfor tx cc18e6dd56b2ac029bb1 1333717395000000
askfor tx cc18e6dd56b2ac029bb1 1333717515000000
ERROR: CTransaction::ReadFromDisk() : OpenBlockFile failed
ERROR: FetchInputs() : cc18e6dd56 ReadFromDisk prev tx 803d7f1f5d failed
ERROR: AcceptToMemoryPool() : FetchInputs failed cc18e6dd56
storing orphan tx cc18e6dd56
Added 1 addresses from 90.214.173.163: 3416 tried, 8115 new
received getdata for: tx a26d8f23d50b8ede2221
received getdata for: tx a26d8f23d50b8ede2221
received getdata for: tx a26d8f23d50b8ede2221
received getdata for: tx a26d8f23d50b8ede2221
received getdata for: tx a26d8f23d50b8ede2221
connection timeout
received getdata for: tx ddb63a21608ada6d5a1d
trying connection 89.223.38.207:8333 lastseen=-4.3hrs
received getdata for: tx a26d8f23d50b8ede2221
received getdata for: tx a26d8f23d50b8ede2221
received getdata for: tx 4febb23f86ab4a0d6cc4
Added 1 addresses from 68.53.153.158: 3416 tried, 8105 new
connection timeout
trying connection 99.244.62.156:8333 lastseen=-4.0hrs
connected 99.244.62.156:8333
Added 1 addresses from 173.238.168.52: 3416 tried, 8106 new
Added 1 addresses from 192.75.95.253: 3416 tried, 8107 new
trying connection 90.129.138.126:8333 lastseen=-2.3hrs
trying connection 216.160.91.91:8333 lastseen=-4.5hrs
trying connection 75.94.171.54:8333 lastseen=-3.4hrs
trying connection 68.207.196.134:8333 lastseen=-2.2hrs
trying connection 80.199.31.74:8333 lastseen=-2.4hrs
trying connection 12.189.154.66:8333 lastseen=-3.1hrs
trying connection 188.47.5.13:8333 lastseen=-2.0hrs
trying connection 46.146.1.200:8333 lastseen=-2.8hrs
trying connection 74.60.78.73:8333 lastseen=-3.2hrs
trying connection 98.222.154.122:8333 lastseen=-2.8hrs
trying connection 77.255.5.179:8333 lastseen=-3.2hrs
socket recv error 110
disconnecting node 109.246.254.188:8333
trying connection 81.151.216.26:8333 lastseen=-4.3hrs
socket closed
disconnecting node 84.73.221.49:8333
terminate called after throwing an instance of 'DbRunRecoveryException'
what(): DbEnv::txn_checkpoint: DB_RUNRECOVERY: Fatal error, run database recovery
Aborted
.. and here bitcoind is dead. No more messages, nor a stackdump either. Resultcode is 134. I got the same behaviour on two different boxes. The earliest abnormal behaviour I could find in the scrollback buffer is transaction 7680e65403ab1b258887 (dont know if this identifier is meaningful after bitcoind has shutdown?). Then there is that sole "OpenBlockFile failed", which shortly extends into hundreds of the same error which take down all dependent operations very quickly. This happened around 7pm CET this afternoon. If necessary, I think I have full -debug -printtoconsole logs on the other box (not limited by scrollback buffer size). Let me know if you need them and I will recover them for you. Edit: added code tags |
|
|
|
Please file bug reports on the github issue tracker. Include enough information so we can reproduce the problem (what platform? what seems to cause the problem? etc) and it might get fixed. Github doesnt seem to accept new accounts: "There were problems creating your account." It gives no further details, so I dont know how to get on there. The platform is CentOS 5.6 x64. The cause of the problem is unknown. It started shortly after 2am CET this morning, and is probably related to whatever has been received around that time (because it worked for almost a day before). I have posted everything that I have, which is (-debug -printtoconsole). There was another piece of information which I didnt save unfortunately. It a crash report after the first crash, and it contained a call stack dump. The initial cause for the crash was a "free" of invalid memory. I have another similar box that also crashed tonight, but it did not dump the callstack and it did have less problems to start again. Therefore the other problems are probably caused by data that has been saved during the initial problematic event, and in fact the first box only came up again after deleting all cached data in .bitcoin/ and in particular the addr.dat file. So there must be at least three problems, one is that an invalid memory free can be triggered, another one is that the file parsers can bail out fatally when encountering corrupt file content, and the third problem is that normal operation can cause files be filled with such corrupt content. Let me know what else you need to know from me. |
|
|
|
|
Gavin Andresen,
Horrible work. Absolutely NOT impressed.
You have >100 bugs open and yet decide to release on 30-march and FORCE the update for 1-april. Just two days later.
This release is unstable as hell. I get crashes. I get unexpected exits. And I get failures to restart.
Crashes:
-----------
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::txn_checkpoint: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in ThreadMessageHandler()
Unexpected exits:
--------------------
04/05/12 11:38:48 sending: inv (73 bytes)
04/05/12 11:38:49 received: addr (31 bytes)
connection timeout
04/05/12 11:38:49 received: addr (31 bytes)
trying connection 200.74.242.32:8333 lastseen=-2.3hrs
04/05/12 11:38:50 received: addr (31 bytes)
04/05/12 11:38
--> Result code: 139
Failures to restart:
--------------------
Loading addresses...
dbenv.open strLogDir=/home/XXX/.bitcoin/database strErrorFile=/home/XXX/.bitcoin/db.log
************************
EXCEPTION: NSt8ios_base7failureE
CDataStream::read() : end of data
bitcoin in AppInit()
--> Result code: 134
What about good Q&A procedures? What about testing stuff before release ("compiles fine on Win7" is NOT testing)? What about establishing a stable status quo BEFORE forcing it on people, like for a month/year?
I get 80% orphans with the old version, and I get 95% downtime with the new version. Great choices, thanks a lot for that.
|
|
|
|
Or that is how I would do it.
Interesting theory, I didnt think of this. However, it does not address the fact that the blocks all come from the same IP (or small group of IPs). In your scenario, it would be a random one out of 1.8M IPs. |
|
|
|
|
The problem with delaying blocks is the following. As a simple user, you may feel personal satisfaction by not relaying the block and it may not affect you in any other way. But as a miner, you are in a difficult situation when you receive a block that you dont "like".
For as long as you plan to dislike it, you cannot mine on top of it - because your potential next block would be waste without the "evil" block. It is chained to it and eventually you will have to publish the "evil" block along with your own next block. To make things worse, your chances of success are higher when you relay the "evil" block as soon as possible. Otherwise you not only depend on your own luck (difficult enough), but also on the luck of the "evil" block (which you have tried to diminish).
Therefore, if you dont like the block, you must not mine on top of it.
This is a very risky strategy. Other miners may not be as picky as you are, and then your mining efforts may end up waste. You are intentionally mining on an old block, knowing that a newer block exists. This can only play out well, when you are absolutely sure that most other miners ignore the block too.
Every time an "evil" block appears, the chances of an orphan produced by (self-proclaimed) "legit" miners raises. It can be seen as a seed for orphans. And I mean an orphan of "legit" work, not only the "evil" work itself.
(Remember that I am talking all this under the premise of the poposed intentional relay delay)
Although the percentage of seeds is only 15%, the chance of an orphan arising from it may be much higher. It depends on the adoption of the protocol change and also on the individual configuration that each miner chooses. We could very well face a situation where everyones own mining effort has a 50% to be orphaned after each seed.
Effectively every miner would pay a very high price for a just slightly better service. At 15% seeds and 50% chance to orphan, EVERY "legit" miner would loose 7% income.
A high price to pay.
To pay for what? Well for the slightly better service quality I suppose. "Slightly better", because a TX can make it 15% faster into the chain. However, there is also a negative effect, which is the constant rate of orphans and reorganization of the blockchain. This could be seen as another kind of "Dos" or attack on bitcoin. It makes 1 or 2 confirm transactions very unreliable, and can also affect 3 confirm TX or higher.
People who rely on low-confirm transactions will now have to wait CONSIDERABLY longer, not just 15% longer for the first confirm and 0% longer for every subsequent confirms.
We have already seen runs of up to 4 or 5 consecutive blocks with no TX, all from the same source.
The higher price paid by miners (in form of extra electricity with less BTC reward) may actually make the overall service quality worse.
|
|
|
|
In a dumb miner - pool model the fact that the miner doesn't do the workload doesn't mean the workload doesn't exist.
One getwork is ~400 bytes. Some have speculated mystery has 1.8 million nodes. To use a traditional full pool server the bandwidth requirements alone would be 5.7Gb and 1.8 million connects every long poll. The getwork size is the same, whether transactions are included or not. The quantity of getworks is the same too, whether or not transactions are included. If your calculations prove anything, then that its not a botnet. "Because its too difficult to manage even a moderade sized botnet (ask Tycho)" - your own words paraphrased. The fact that transactions are not included does not add one single jota of support towards/against the botnet theory. |
|
|
|
|
