Maybe, need just wait for minutes, until huge list of UTXOs will be load into cache?
For 1st glance, uint256HashMap must keep up to 1,000,000,000 records.
Your list much less. So, this is not it. What is it - I don't know.
as result, I see 2 possible ways:
1. You move funds into another wallet, and decrease TX qty by this way.
2. You will provide me access to your machine, and I will try to debug on your wallet.
after syncing from scratch, this didnt happen again. i'll post if i encounter it. |
|
|
|
> Once i see this in my logfile, 1 thread of emercoid (niced at 19) uses 100% cpu until i kill -9 it. emercoind is stuck. Is this always happening? Maybe, after restart, there is not deadloop? We cannot reproduce this bug on our wallets - on Linux, BSD and Windows everything seems OK. If you can repeat the bug, please note us, where it happening. To do this, run (without daemon mode): $gdb emercoind (gdb) r [wait till deadloop] CTRL/C (gdb) where This command shows us runtime stack. Another option - give us ssh-access to your machine, and we try debug ourself. > uint256HashMap:Set(517/1024) data=56 sz=57344 This is OK. This is just our new container created, used for caching minting. This code had been added into 0.3.3, and has not been changed in 0.3.4 For assistance, contact us: team@emercoin.comSo, I assume, problem isn't relevant to this container. However, need debug more deep. its running in gdb now (had to set args daemon=0 so it dosnt go into background) with debugging symbols. i also see lots of those CTxMemPool::accept, fCheckInputs = 1, fOnlyCheckWithoutAdding = 0
ERROR: FetchInputs() : 5c1f071caa46f05ba4f2addb175e5754675e693615300777381095ffd3f86e19 mempool Tx prev not found 45987e419fe23311e7260cbd2d126ae40438d1dbd02626b294241f6095a1a7a2
ERROR: CTxMemPool::accept() : nonstandard transaction type
i've used v2.2 before i tried 3.3 its a problem with minting... uint256HashMap:Set(327677/524288) data=64 sz=33554432
ThreadRPCServer method=listtransactions
Once the size/set is getting too big, it deadlocks. no more RPC commands are possible. The bt isnt helpfull either #0 0x00007ffff5c19f3d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1 0x00007ffff5c4b4a4 in usleep (useconds=<optimized out>) at ../sysdeps/unix/sysv/linux/usleep.c:32
ts = {tv_sec = 5, tv_nsec = 0}
#2 0x00000000004dc26a in Sleep (n=5000) at util.h:104
No locals.
#3 AppInit2 (argc=2, argv=0x7fffffffe258) at init.cpp:660
nStart = <optimized out>
fFirstRun = false
pindexRescan = <optimized out>
sa = {__sigaction_handler = {sa_handler = 0x4cfbe0 <HandleSIGTERM(int)>, sa_sigaction = 0x4cfbe0 <HandleSIGTERM(int)>}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = 0,
sa_restorer = 0xffff8000000020a1}
file = <optimized out>
lock = {m_file_hnd = 5}
strErrors = <incomplete type>
fTor = <optimized out>
pathLockFile = {static preferred_separator = 47 '/', m_pathname = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x8f5148 "/home/k1773r/.emercoin/.lock"}}}
nLoadWalletRet = <optimized out>
nameindexfile = {static preferred_separator = 47 '/', m_pathname = {static npos = <optimized out>,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x39326c8 "/home/k1773r/.emercoin/nameindexV2.dat"}}}
pszP2SH = 0x60b256 "/P2SH/"
#4 0x00000000004dd07a in AppInit (argc=<optimized out>, argv=<optimized out>) at init.cpp:132
fRet = false
#5 0x00000000004a50c9 in main (argc=<optimized out>, argv=<optimized out>) at init.cpp:118
fRet = false
the other threads dont show anything obvious (syscalls) i will resync from scratch in this case. |
|
|
|
> Once i see this in my logfile, 1 thread of emercoid (niced at 19) uses 100% cpu until i kill -9 it. emercoind is stuck. Is this always happening? Maybe, after restart, there is not deadloop? We cannot reproduce this bug on our wallets - on Linux, BSD and Windows everything seems OK. If you can repeat the bug, please note us, where it happening. To do this, run (without daemon mode): $gdb emercoind (gdb) r [wait till deadloop] CTRL/C (gdb) where This command shows us runtime stack. Another option - give us ssh-access to your machine, and we try debug ourself. > uint256HashMap:Set(517/1024) data=56 sz=57344 This is OK. This is just our new container created, used for caching minting. This code had been added into 0.3.3, and has not been changed in 0.3.4 For assistance, contact us: team@emercoin.comSo, I assume, problem isn't relevant to this container. However, need debug more deep. its running in gdb now (had to set args daemon=0 so it dosnt go into background) with debugging symbols. i also see lots of those CTxMemPool::accept, fCheckInputs = 1, fOnlyCheckWithoutAdding = 0
ERROR: FetchInputs() : 5c1f071caa46f05ba4f2addb175e5754675e693615300777381095ffd3f86e19 mempool Tx prev not found 45987e419fe23311e7260cbd2d126ae40438d1dbd02626b294241f6095a1a7a2
ERROR: CTxMemPool::accept() : nonstandard transaction type
i've used v2.2 before i tried 3.3 |
|
|
|
I've updated my node to the current git master. Once i see this in my logfile, 1 thread of emercoid (niced at 19) uses 100% cpu until i kill -9 it. emercoind is stuck. uint256HashMap:Set(517/1024) data=56 sz=57344
also this only happens when i unlock my wallet for minting! |
|
|
|
rm -rf cpuminer-multi git clone https://github.com/nicehash/cpuminer-multicd cpuminer-multi vi build.sh ----- Debian 7.7 / Ubuntu 14.04 (gcc 4.7+) extracflags="$extracflags -Ofast -flto -fuse-linker-plugin -ftree-loop-if-convert-stores -march=native -mno-avx2" ./configure --with-crypto --with-curl CFLAGS="-O2 $extracflags -DUSE_ASM -pg" make -j 4 ----- ./build.sh gcc -std=gnu99 -DHAVE_CONFIG_H -I. -fno-strict-aliasing -I. -Wno-pointer-sign -Wno-pointer-to-int-cast -O2 -Ofast -flto -fuse-linker-plugin -ftree-loop-if-convert-stores -march=native -mno-avx2 -DUSE_ASM -pg -Iyes/include -Iyes/include -MT crypto/cpuminer-mshabal.o -MD -MP -MF crypto/.deps/cpuminer-mshabal.Tpo -c -o crypto/cpuminer-mshabal.o `test -f 'crypto/mshabal.c' || echo './'`crypto/mshabal.c crypto/mshabal.c: In function ‘mshabal8_compress’: crypto/mshabal.c:44:3: error: unknown type name ‘__m256i’
__m256i data[16];
^Ups.... Change cpuminer-config.h /* Define to 1 if AVX2 assembly is available. */ //#define USE_AVX2 1 #undef USE_AVX2 make clean && make Error... Im not understund. Please help my step-by-step this is horrible. use git pull! |
|
|
|
Support the development of anoncoin. 5% of ANC trading fees at ExchangeD.I2P will be donated to anoncoin development fund.
First I think the community needs verification of who is actually developing the coin from the developers themselves I have visited IRC lately and have not seen any evidence of meeh or gnosis being present. The comments about about github, wiki page or irc prove nothing. I have seen no recent work proven to be from meeh or gnosis yet you claim the are back and active. It they are they need to post in this thread (or show see actual work in github) to prove it. Clearly some people believe you because at 60,000 satoshi ANC prices are still more than double (almost triple) what they were in late April and early May However people (including myself) believed what they were told about Zerocoin last fall. Look how that turned out. you need to go to IRC2P not freenode. |
|
|
|
i even contacted you about that bug months ago  was asking forrestv about it, but he didnt respond. created a hackish fix in my repo. It's limited to prevent DoS attacks on P2Pool by e.g. making a bunch of fake transactions and then forcing them to be relayed across the entire P2Pool network. With this limit, an attacker can only force every other P2Pool node to download, at most, 50kB per share the attacker mines. Given that 100kB transactions are possible, it should probably be 100kB, not 50kB, but it doesn't have much of an effect otherwise, since 50kB/share is comparable to the maximum transaction throughput allowed by Bitcoin (500kB/block). K1773R, your "hackish fix" will result in your shares being orphaned if it ever results in differing behavior. The contents of the generate_transaction function are used to determine consensus, so if your version acts different, other nodes will see your shares as invalid. Good that we talk about it now. When i was still mining BTC with p2pool, i wondered why not all of my (sometimes bigger than 100kB) would be included in p2pool blocks. It didnt really bother me back then, as some other pool would mine them. I think raising it (not as high as my hackish fix) would be a good addition to a future hardfork. Im absolutely aware that i would get my shares rejected. I wasnt using it for BTC. I wanted to mine the huge ANC stuck txs, so i had to create my own p2pool and set the limit higher. |
|
|
|
i even contacted you about that bug months ago was asking forrestv about it, but he didnt respond. created a hackish fix in my repo. Hehehe, I wasn't in a right "state of mind" back then...still questionable now. I see that you increased it to 500 kB in your fork and imagine it was the solution to mining those "stuck" ANC transactions. Like zvs said...probably done to avoid an orphan due to block size. the problem is, per default p2pool cant include a tx that is bigger than 50kB, which is a shame! usually the big txs pay very well (if they arent dust). when i was mining BTC on p2pool i was prefering big txs which paid more than smaller ones. i never included one of the big ones, but i didnt wonder back then. until i hit it again when mining ANC. |
|
|
|
i even contacted you about that bug months ago was asking forrestv about it, but he didnt respond. created a hackish fix in my repo. |
|
|
|
oclvanitygen has no working -P switch...
What makes you say that? Are you using the vanitygen repo I linked to? I just tried it and it works for me. also check --help
Thanks. I just added documentation for the -P flag to the --help text. ./oclvanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Invalid character '0' in prefix '048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB'
Difficulty: 888446610538
[32.19 Mkey/s][total 209715200][Prob 0.0%][50% in 5.3h]
Yeah, that looks like you're running the wrong version. The standard vanitygen program isn't able to make CLAM addresses. I made a fork here: https://github.com/dooglus/vanitygenwhich does. [...] Once you've built my fork of vanitygen, run it like this: ./vanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ I decided to check whether oclvanitygen really works with the -P flag, because nobody has yet posted a private key that works for me, so I rented a machine with a video card: $ ./oclvanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLA
Difficulty: 264104224
Pattern: xJDCLA
Address: xJDCLAE7QkEFsQe9jENL8KgNL8txiLRAdN
PrivkeyPart: LgeVmeaXv5gMETfs6q8CYJEB9W6UhooAnwXUb9c3nf5uor5u6QpX
[25.14 Mkey/s][total 260046848][Prob 22.4%][50% in 4.6s][Found 1]
When I combine LgeVmeaXv5gMETfs6q8CYJEB9W6UhooAnwXUb9c3nf5uor5u6QpX with my private key, I get a private key which gives me an XJDCLA address. So it is working. I'm searching keys at 26 Mkey/s, 50% in 6 hours. So you guys have some competition.  after a make clean && make, it works. tough i probably cant respond in time with the keys it finds... |
|
|
|
Ah - that Privkey you gave me is the actual privkey for an xJDC address. Did you specify the -P flag and the pubkey? It looks like either you didn't, or oclvanitygen is ignoring it.
yes, -P dosnt work for OCL  it was ignored. It isn't ignored for me. If I copy it wrong it complains, and if I get it right it accepts it and goes on to find that I don't have a suitable video card: $ ./oclvanitygen -CkP xx8F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Invalid base pubkey
$ ./oclvanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Difficulty: 888446610538
clGetPlatformIDs(0): Unknown code -1001
clGetPlatformIDs(0): Unknown code -1001
Available OpenCL platforms:
$
oclvanitygen has no working -P switch... also check --help ./oclvanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ
Invalid character '0' in prefix '048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD1897F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB'
Difficulty: 888446610538
[32.19 Mkey/s][total 209715200][Prob 0.0%][50% in 5.3h]
|
|
|
|
using OCL, is this correct? Pattern: xJDC
Address: xJDCQtZP9MTyDVhUwHeNX7HYhXqhDuZMN1
Privkey: LmGxCNahLoFuYHsFXoYbG8T3ggjK9dBud5V7JxW8fMs1WPYYMBPQ No. That gives me these two CLAM addresses (one's compressed, one isn't): xBhBpydGF9xduGRSBt3uSWENqaeKiZRzvX xMiZ42BzUjeRgpa45Q4tWkzdeMsHhyP2U5 Neither starts xJDC. Maybe my patch to oclvanitygen.c was bad. Ah - that Privkey you gave me is the actual privkey for an xJDC address. Did you specify the -P flag and the pubkey? It looks like either you didn't, or oclvanitygen is ignoring it. yes, -P dosnt work for OCL it was ignored. |
|
|
|
Bounty offer: I need two new CLAM vanity addresses. One for the hot wallet, and one for the staking wallet. I want them both to start with xJDCLAMZ, case sensitive. I want them both to use *compressed* public keys. The standard vanitygen program isn't able to make CLAM addresses. I made a fork here: https://github.com/dooglus/vanitygenwhich does. My public key for vanitygen is 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD18 97F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB Once you've built my fork of vanitygen, run it like this: ./vanitygen -CkP 048F08DCB868F3C22397BF5BAE1F19DE55F4D936AF66DC144E098F69A488FE3266A14FDCDAFBD18 97F034AA54CAE13D2AB9A9D96B487A263594F408100D6DCC0FB xJDCLAMZ -C to generate CLAM addresses -k to keep going after finding the first one -P to specify my public key I don't have a graphics card. You might find that oclvanitygen works better, but I've never even been able to check if it works at all. I made some changes to have it accept -C but don't know whether I did it right. If you want to check, generate an xJD address, post the privkey here and I'll tell you if it works for me. I'll pay 50 CLAM to the finder(s) of each of the first two working private keys posted here. Only unedited posts will count, so I can check the post timestamps. using OCL, is this correct? Pattern: xJDC
Address: xJDCQtZP9MTyDVhUwHeNX7HYhXqhDuZMN1
Privkey: LmGxCNahLoFuYHsFXoYbG8T3ggjK9dBud5V7JxW8fMs1WPYYMBPQ |
|
|
|
I've looked back many pages but I couldn't find anything. Has anyone created and compiled a Windows 7 version of Vanitygen that works with AMD 290's? You'll be my hero if you point me in the right direction The oclvanitygen offered here should be appropriate for your system. You might need to install OpenCL/AMD Parallel Processing drivers. I've attempted to use it in the past for newer AMD GPU's with no success. Have there been code changes? I can only get it to work with 5xxx & 6xxx GPU's. see nasty's post for an "how to fix" |
|
|
|
Anyone tried yet is Armory compatible with the 0.11 core with pruned blockchain?
Do they claim it works? In theory, it might work. You would have to sync first with pruning disabled and then run Armory until it is up to date. After that pruning should be OK, unless Armory falls far enough behind. nope. if you'd like to sweep coins from a privkey, your fsck'd. |
|
|
|
Any hints on the future of this coin?  Your signature says your an "expert"... |
|
|
|
This message was just posted by Mycelium on Twitter:-
"All the spam flood clogged our Tor server, so we're having to defrag the 160gig database it's on. Will take a while. Sorry"
I went into settings and stopped using Tor and was successfully able to make transactions. My past transactions that did not appear on the Blockchain, have disappeared and my balance is correct.
Twitter really does seem to be a very good place to get CS as no company wishes to give bad publicity in such a Public Forum.
defrag, really?! what horrible system did you build... |
|
|
|
Woohoo! Another centralized exchange.
Can we get a decentralized exchange already?
can you contribute something, rather than cry? i guess not... |
|
|
|
"dogecoindark" ? REALLY?! game over. mental issues... |
|
|
|
NEW ZETACOIN POOL IN OPEN BETA!
~http://zetacoin.latenightminers.ca~
-37 Blocks found so far
-MPOS with VARDIFF enabled 256-20560 (retarget every 30 secs)
-0% Mining Fees (any donation goes to server upgrades)
-Workers are auto-added on first connect.
(As pool is still in beta, interface updates/server upgrades/code tweaking may happen suddenly, ALWAYS have a backup pool set in your mining config)
Excellent, the more pools the better. Stronger network, more visibility, better distribution. Zetacoin is starting to really get noticed and will be reaching critical mass very soon. My only regret is not buying more when the price was under 1000k. Currently under a pretty heavy DDOS attack, server will be down untill i can add some mitigation software. BACK UP AND RUNNING WITH A DUAL LAYER FIREWALL AND SOME HEAVY DDOS PROTECTION HASH YOUR HEART OUT!!! game over... |
|
|
|
|
Show Posts
