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

Yeah! I can be Guinea pig again, I love doing the beta testing if it helps.
As Italians say:"chi va piano va sano e va lontano". Small changes will bring us a strong platform.

We could have a motto:" One Credit at a time" or "Take a little Credit to go far". Sorry I'm rambling.

Test on latest, partly rollbacked version ongoing

Current sync, 250 000 blocks. Looks good so far but will give more info as soon as the sync has finished.

I will soon add yet another beta release (0.9.1.73) for those interested in testing.

Thank you for your patience.

Well, it's not wrong, but normally the system should add the newly mined coins as deposit automatically unless you disable it. If it isn't enough (which it actually isn't now, anyone mining without extra deposits will get a slight difficulty punishment), the miner will look for manually added deposit txs.

But there's nothing preventing someone from creating a large deposit tx and lock it all up. So you may have to wait a few months to get them back...

Did you create a deposit tx yourself with qt and run the miner? In that case the miner probably picked up the available deposit and added it. There's no warning if the deposit is "too" large.

To sum it up:
- If the miner doesn't have enough deposits to reach the requirement, it will look for manually created deposit txs to fill up to the required level.
- If reward as deposit is enabled, it will use the reward to get to an exact amount, and send the extra coins as deposit change.
- However, if a deposit tx is larger thatn the required amount, there's no way for the system to modify the deposit tx and send the extra amount as change. The deposit tx is not modifiable.
- The system can however modify the "reward deposit", since it creates it itself. Thereby it can add up to just the correct amount, and send the rest as change.

Example:
1. Required, 30 CRE, Reward 20 CRE, 1 manually created deposit tx with 25 CRE in it. The miner will then take the reward, add 5 CRE as deposit to fulfill the requirement, and add 15 CRE as change.

2. Required 30 CRE, Reward 20 CRE, 1 manually created deposit tx with 60 CRE in it. The reward is not enough to reach the requirement. The miner will then take the manually created deposit tx and add as deposit. Since the requirement is fulfilled it does not have to use the reward, which will be free for usage elsewhere. However, none of the 60 CRE added as deposit can be sent as change since the manually created deposit tx is unmodifiable.


Some modifications to the deposit system will be done to ease the deposit process in the near future.

Yes, I plan to do that, but spread out over time instead to ease the transition.

Yes, I will definitely pick some up myself soon btw. As soon as I'm done with dev in a few days I'm picking up some low sells.

When I put 500 credits as deposit in mining, all the 500 is taken as deposit, there is no change, is that normal? That is included in block 33338

I've been collecting coins where I can but I'm a bit worried it all goes in the same hands until actually people start to claim Credits against their BTC.
Signature would be nice but we need something simple that explains what Credits are and their use.
I think not many understand why it is so cheap now and will sell thinking it is useless and worthless.

Yes, was just about to pick myself up some cheap CRE
Take advantage while you can haha.

Also, movement on the development/bug fix front is great! Must be frustrating to have been stuck with that small speed issue but good to see things are moving forward now!

I was planning on setting up a new signature campaign as well, now that we have an exchange to trade on and a bit more stance in the crypto-sphere, so look out for that!

Maybe through various upgrades you will manage to eliminate the issue, i.e. moving to latest bitcoin core. Still, it is good to see an upgrade and some movement.
Are there any new functionalities being added as well?

On a separate note, anyone enjoying those ridiculously low prices?

Update on coming release

Due to the difficulties in getting the release correct with regards to speed on initial sync on Windows, I have decided to postpone parts of the updates, since these issues have stalled development long enough. Disk usage optimisations will however be included, to further shrink the size on disk. A beta release (0.9.1.73) will be done today. Further info to come.

Thanks for the input, good to hear that you do not consider it a rush.

And I agree, apart from that this has been holding me up for quite some time from further development, which I'd really like to get into. Instead of chasing esoteric bugs. At least we are not struggling with a discussion over block sizes, that is a problem to, I guess.

The -benchmark option is quite useful. Measures (mostly) the time it takes to read and write to and from the chainstate, or the UTXO set as it's called in other places.

Well it's good to know that you are working on it and have ideas how to best deal with it even though it might be short term until you find a better solution.
As you said it is not working, I was trying on a part synced folder and it was barely moving. Next time I'll use the benchmark option as I didn't know it.

Take your time to get it fixed, there is no rush at all.

Later test stages negative for version 0.9.1.71, continued investigations are ongoing.

Unfortunately what seemed to be a very large step forward with regards to syncing times turned out to slow down in later stages of chain block sync (approx at bitcoin block 330 000).

The upside is that I at this stage believe I have identified the specific commit that is causing the slowdown. I will have to ask you for a few more days of patience.

I am very concerned about these issues. Therefore I will re-prioritize the task list, to create a Bitcoin-decoupled version of the wallet as soon as I have this issue firmly under control. Such an update would sidestep the issue completely until I find a permanent solution.

Ok, are you running with a working dir that is synced/up to date or syncing from start?

You know that you can start with the parameter -benchmark=1 to get extra info about speed of block parsing in debug.log?

So far I can't see any speed improvement on Windows 10 but will give you an update tomorrow

Still syncing, unfortunately... I'll publish it as soon as it's done. Look here for more info.

Is there an updated blockchain torrent for this or do we need to synch from the beginning?

Thanks

Wow! This is extremely good news, I was kind of bummed seeing how I use Linux and thought the improvements weren't going to affect me... Great to hear that it's a boost on ALL operating systems! Wishing good luck to the beta testers, unfortunately I'm away and can't help! :/

Beta version 0.9.1.71 released for testing

A beta release with the separate messaging threads joined has been released for testing. Follow the link below to download. If you have been testing beta version 0.9.1.70 you will be able to just replace the binaries, otherwise, upgrade acording to instructions in download link.

http://credits-currency.org/viewtopic.php?f=23&t=17430&p=19594

Possible progress on performance issue

After merging the two processes that handles messaging for Credits and Bitcoin into one single thread, indications are VERY good so far. Chain download is ongoing, more reports will be given as soon as whole chain has synced.

- Sync from empty at block 316000 after approximately 10 hours. If this trend continues, syncing from empty working directory will be a whole lot faster.
- Block parsing times down with a factor of 10 to a factor of 100, depending on how thread competes for resources. If this trend continues until full sync, it is of course a huge performance boost. This performance issue has been haunting us since inception, although less pronounced in earlier versions. Do note that it will be not tested fully until whole chain have synced.
- These performance gains will not be limited to Windows, but will affect all operating systems.

Binaries for windows for beta testing will be published for Windows soon.

THESE ARE PRIMARY INDICATIONS! FULL VERIFICATION WILL NOT BE DONE UNTIL BOTH CHAINS HAVE BEEN FULLY DOWNLOADED. THE CRITICAL SECTION WHERE BOTH CHAINS DOWNLOAD SYNCHRONOUSLY HAVE NOT BEEN REACHED YET.

Release version 0.70 performance issue hunting progress

Three different completely similar Windows machines have been used for testing. Each one of the machines has been given a release build version with various levels of patches applied to them so that the updates ranging from the latest released version up to the coming version can be applied gradually. Each of the computers have then been allowed to sync from start.

Each computer is a simple desktop Win 8, 4 GB RAM, 3Ghz Pentium processor. In short, a very basic desktop PC.

The time to get each node synced have ranged from 25 hours up to 35 hours. No notable difference have been found between the different versions. The performance problem has only occurred late into the sync process and very intermittently.

However, the problem always have seemed to occurred when the Bitcoin blockchain and the Credits blockchain are syncing at the same time. This leads me to believe that it is a contention (https://en.wikipedia.org/wiki/Lock_(computer_science)#Granularity) problem between the two main message processing threads, where the threads are competing for the same resources. A new test is being setup where the two threads are merged into one.