Search results

Doing a bit more spewing. Max successful tx's per block so far is about 250. Need to set up more clients. :grin: http://test.explorer.darkcoin.fr/block/00000000bf9c37aeefd2e023d283132b01415b4ca9a470c9b488c9585d6897b6

Anyone seen a block transition lately? I'm stuck on 71844.

linux64 MN just crashed, end of debug.log: .darkcoin/testnet3# tail -f debug.log 2014-11-29 18:20:33 signing privkey 932ZyRKNcwwW7ijevLJGMQEEQJxz8cuSM7nig8P5MYTvoQX9uHq 2014-11-29 18:20:33 signing pubkey2 msK3EXq5V6NHthvYKSQCbcAkSdciaPzAxU 2014-11-29 18:20:33 verify strMessage...

At the sender end, yes.

That's not an IX. IX's show 1/confirmed at the receive end and txdepth/confirmed at the send end. Still trying to capture a successful one, grrr.

Hmm, haven't managed a successful IX in the last 20+ attempts, restarting client or not. Which is annoying, because I've been screenvidding each attempt.

Diff shouldn't affect either IX or DS mixing.

That's a fail I think. Relaunch your wallet with --instantxdepth=17 or something and you'll see it work properly. You get a green tick with the txdepth visible on mouse-hover straight away. When it stops working for me after a few go's, relaunching the wallet (with the instantxdepth switch set)...

Uh, pretty sure that's not the case, or at least shouldn't be. IX speed should be invariant with txdepth.

Eh, I think IX might be working, manually setting instantxdepth=20 just got me: Status: 20 confirmations, broadcast through 1 node - within about 20 secs. But only showing 1 confirm at the other end via listtransactions command. Yep, holy poop, it definitely seems to be working, it's just the...

No crashes yet on 17.2 but I don't think IX is working yet, at least not the way it did in Evan's youtube vid. People do understand that more hash isn't going to speed anything up, right? It's just going to raise the mining diff.

Local QT segfaulted for me too. stdout: stu@stu-laptop:~/.darkcoin$ ./darkcoin-qt --instantxdepth=6 init message: Verifying wallet... init message: Loading block index... init message: Verifying blocks... init message: Loading wallet... init message: Loading addresses... init message: Done...

Getting: 'Status: 0/unconfirmed, has not been successfully broadcast yet' when sending with IX box checked. Also couldn't DS 10DRK despite having 162 showing as available, with or without manually selecting the inputs.

I threatened my testnet i5 with a water pistol and told it, "Get a bloody move on, I know for a fact you can process ten bazillion FLOPS you lazy bastard!" but it called my bluff. :sad:

Heh a bunch of my earlier tx's turned up, a speedy 70 blocks later! 3 hours... service from miners is crap, can I get a refund? :mad:

I've tried inserting a delay of up to 5 secs between tx's but that makes no difference either. Some arrive, some arrive much later, some never arrive, and even the ones that arrive in good time in the receiving wallet often just sit there with no confirms and are nowhere to be seen in the...

0.1 DRK per tx, which is often larger than the actual sent amount.

testnet. I'm hoping it's just an artefact of the current testnet situation, but really, one solo miner should be able to process thousands of tx's per block.

There's a serious problem with miners completely failing to get tx's into the blockchain even when a fee is included. They turn up hours later or not at all if I send more than 20-30 tx's per block. Is this a deliberate restriction or are miners just useless?

Yes. Use a new masternodeprivkey. If you're seeing inbound port not open when you do a masternode start, either your server has that port shut or you've got errors in one or both of your conf files, double check them. You can check your server ports with 'sudo nmap -sT your.ip.address.here' or...