Topic: CREDITS [CRE] | SHA256 | SIDECHAIN | NEW BLOCK-DEPOSIT FEATURE | OFFICIAL THREAD - page 7. (Read 57384 times)

Very nice updates Greydon!

UPDATE:

Creditsdice.com chat is back, with a new update!



Change log

CreditsDice version 1.1:

Notes: This patch is the first in a set of updates to be released. This version does not include the invest feature, but it is added in the next release.

  Chat:

    - New chat system in place, following the "look and feel" of the previous chat update. (uses React, and Ratchet, for websocket handling)
        (This new chat engine is much more efficient, is easy to alter, and sets a good tone for future development)

    - All user messages are now the same color (Tips, PMs, and other system/special messages are colored accordingly)

    - Xss vulnerabilities patched

    - Getting chat history is redone with the new engine, to push messages from the chat server itself instead of grab from the DB. (This escapes user injected scripts which wouldn't show 'onMessage')


 Frontpage:

    - Chat window size adjusted 70% -> 85%
 
    - Invest tab added, to tease you.

  
  General:

    - Placing bet speed improved, as place.php no longer makes a $wallet->getbalance() call every time a bet is placed to check is against the max profit. That max profit is now static, updated by me.
  
    - Removed redundant functions and ajax methods, as well as clearing up the global scope of functions on setInterval at any given time.
       (basically, things are smoother overall)
    
    - Various minor bug fixes/tweaks




Thanks for sticking with us, and sorry for the delay. The new chat engine is by far the largest amount of code/work put into this update, and took a week of learning new libraries and implementations of websockets. However, learning is good!

Cheers,
Greydon

Greydon is doing a great job, having few delays but im sure he will do it , i cant wait to integrate the new graffitidice logo.

Hey, sorry about that I've just had multiple things I'm doing at once. I'm upgrading the chat as well as making the site more secure in general.

The website isn't down however, you can still place bets etc.. everything is functional. Just the user Chat is disabled at this point and under maintenance. I'll maybe add the old system back in meantime so we can all still talk!

Yeah that's good input. Still haven't been able to reproduce the problem but I'm working on it. I have a general idea of what the problem is.

I think that Greydon is working on it. Just talked to him.

What is happening with creditsdice.com website ?

It is always down for long time now 

When CPU mining was the only option I had no problem mining on an encrypted wallet so maybe something changed between those versions. Just saying if it helps to find the bug.

Improved disk usage report and simpler torrent initialisation

The size of the working directory has been reduced to only 5.7 GB, if running in trimming mode!

This means that initialisation from a torrent file will be simpler as well, with a significantly faster download. The zipped file is approximately 4.5 GB and will expand to 5.7 GB when unzipped! Download link for newly updated torrent file provided below.
http://credits-currency.org/viewtopic.php?f=18&t=517&p=766

Tests are currently ongoing. Hopefully I will have a clearer picture within a few days.

I have the same problem with a encrypted wallet file and mining simultaneously.

Ah ok I was close

Yes my credits_wallet.dat is encrypted.  Come to think of it,  I don't think I started having problems with these errors until after I encrypted my wallet.

My crystal ball says you will be able to replicate the problem once you encrypt the credits_wallet.dat

Yeah we can take this to PM's so peeps don't have to wade through all of this any longer

I must say that you have a firm grip on how the system works, I'm impressed!

Just one small correction to make things maybe even more clear:
The deposit change can only come from the deposit tx that the system creates by itself, and that deposit tx is only created to spend the reward. The deposit txs that you prepare manually yourself can never be modified, and hence can not have a deposit change. As mentioned, just a minor clarification.

However... I'm working on having the software automatically prepare deposits from everything that is available in a wallet to simplify the mining process. That way a miner could just start the miner, set some parameters, and watch the wallet content go into deposit block by block. I didn't want to enable this before, since software automated access to a wallet always poses a risk. But I think the time is right to introduce it now, with a switch to be able to disable it.

Aha ok. Are you by any chance running your miner with a locked (encrypted) credits_wallet.dat file? That would explain the part that you can not view the mined coinbase tx in your transaction history. The reason is as follows:
- If you have an unencrypted credits_wallet.dat file, then the mining software automatically and directly will spend the coinbase tx with the deposit tx if you are including the reward as deposit. You normally do this. If the credits_wallet.dat file is encrypted, this can not be done (the software does not have "spending access" to the coinbase tx output, it can not use the key, only view it). To get around this problem, the coinbase tx output spending key is instead stored into the deposit_wallet.dat file, where the software always can use it; the deposit_wallet.dat file is never encrypted. Since the coinbase output is spent directly, the coinbase output key is really just a "throw away key" and the reward from the coinbase ends up in the deposit tx. The key for the coinbase tx are however still hanging around in the deposit_wallet.dat file. BUT, when they are stored there, the transaction history extracted from the credits_wallet.dat file does not cointain the coinbase tx output key, and therefore does not show the coinbase tx. This could of course be remedied by merging the transaction history of the credits_wallet.dat and the deposit_wallet.dat files into one. This has not been done yet due to technical complexity and lack of time.

One other explanation, the deposit_wallet.dat file is ONLY used for temporary storage of prepared but not yet block included deposit txs. Except for the usage described above. It is NOT related to deposit txs in any other way. Deposit txs, like any other txs, lives in the blocks and the related keys for your own deposit txs lives in your credits_wallet.dat file. To repeat this; the deposit_wallet.dat file is ONLY a temporary working file, containing prepared but not yet used deposits, and as described above, "throw away" one time keys, used for coinbase txs that are spent by deposits txs when the coinbase tx output key can not be stored in credits_wallet.dat. That happens when credits_wallet.dat is encrypted. The deposit_wallet.dat can however be useful to save at the same time as backups of the other wallet files are done since it contains uniquely generated keys, and keys should in principle never be thrown away.

This makes me believe that a single backup option that backups all three wallets at the same time probably should be added.

Good to hear that you have found a way (mostly) around the error popup.

I'm working on simulating the problems that you are having, however, so far, haven't been able to reproduce them.

Maybe I should take this discussion in a PM and then just post the outcome here?

This windows popup is the initial thing that happens when I try to send a transaction.  Gives me 3 buttons (retry, ignore, and abort).  Hitting the "retry" button brings up another window titled Microsoft Visual C++ runtime library.  The messege in that window reads as follows: 

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

the "abort" button shuts down and closes the program.  If I hit the ignore key a few times (2-5 on average) the popup eventually goes away and I can send the transaction without kicking me out of the wallet.

1. Intermittently can't send a transaction. I should mention these are internal transaction where I am sending small amounts 5-6 cre to my personal receiving addresses to make prepared deposits.

2. after looking at this again I was incorrect on what is happening.  In version 9.1.60 when you mined a block you would have 4 transactions.  The first transaction was labeled "mined" with the pickaxe and the amount of the block (currently 45).  The second transaction was a "deposit" for the block.  The third transaction was a "deposit" from my prepared deposit.  The fourth transaction was labeled "deposit change" with any overage from my prepared deposit coming back to me.  In 9.1.74 I am no longer getting that first transaction labeled "mined" with the pickaxe and the value of the block mined.

3.  Yes, the wallet shuts down.

I was running two separate directories so nothing was mixing.

It's too low for what?
To buy them? No it's a nice price to get in.
To sell them? You shouldn't be considering it for now as Gabriel is developing constantly but it takes time.

The debug output that you added at the end of the message, is that the miner shutting down after a while?

Am I correct when I say that there are three errors here:

1. Not possible to send txs in server mode?
2. The mined column wrong (minor error)?
3. The miner (the whole wallet?) dying on this line: miner.cpp.Line 1021?

Well, a price can never be guaranteed, it is a free market after all.

But yes, I do expect the price to rise, impossible to say when. However, several groundbreaking features are planned for the mid-near term future.

But per the time of this writing a buy worth of 1-1.5 BTC would bring the price up to 0.001. Market is still too shallow to accurately give any price predictions.