can't go past block 14, closed an relaunched, same thing and on block overview only block 0 is validated.
ok deleted all the files in chain folder , seem to work now
kk synced
Topic: [PoS+PoW] eXocoin [EXO]-gen 2.0- dev. from scratch! Give-Away | Open Beta - page 164. (Read 415654 times)
May 22, 2014, 05:13:05 PM
May 22, 2014, 04:59:22 PM
exocoin, please also remember that you wanted to have a non-linear mining revenue. is this alreaddy build in? 
Something like a root function maybe.
Also: Please upload it also on mega, your server is to slow. It takes 30 minutes to download the client.
What are your plans with a new website?
Something like a root function maybe.
Also: Please upload it also on mega, your server is to slow. It takes 30 minutes to download the client.
What are your plans with a new website?
May 22, 2014, 04:20:31 PM
Good news after some abstinence from me.
We decided to totally reorganize the udp and udp reliable part. That took of course time to thoroughly investigate after coding was done.
Anyway we come up now with 150 lines less code than before and - more important - it is more straight forward and cleaner than before. We also improved the logging speed (if many transactions per seconds appear this is somewhat not irrelevant, however, the logging will be reduced once it will have to deal with more people). We cleared one memory waste but we will seek for not freed memory with 0.6 more thoroughly.
If 0.59.3 runs stable until the planned eta of 0.6 (to be announced) then the next version will be 0.6 instead of 0.59.4
Also, if it runs stable for the next days then the launch early june seems realistic to us. No major feature is missing, however, we need the proxy part to be done to be more safe against early DDoS attacks. But that is no rocket science so we should get in ready early enough. Features like standing orders can be implemented later on without major troubles as well as the decentral inclient marketplace.
Just created 500 transactions in ~2.5 minutes which translates to 3.3 transactions per second (but note: this speed is not limited by the network but it is limited by my local computer's speed). More important here is not the speed but: all 500 transactions got confirmed and integrated in the block. Then, a new client, was able to download that big block without problems. And that's the major difference to 0.59.2: Even with 0.59.2 we were able to create 2000 transactions (should be still possible
) _but_ a new client was not always able anymore to get that block because of its size. Not always translated to: "a node with very good connection to the network had a good chance to get that block, others not". A block with 500 transactions will be splitted to roughly 250 single udp packets/ethernet frames and if one of them was lost on the way then the 0.59.2 client requested all parts again.
With 0.59.3 we not only split those big blocks into small *reliable* packets - if any packet gets dropped then only that one will get queried again - but with our redesign every udp message in the program that is considered to be too big will automatically splitted into reliable ones. So the reliability aspect moved completly into the inner-udp class. But enough said ---
Right now 4 nodes are up, running and synced. Please report if you have troubles syncing beyond block #14 or #15 (but wait to get it synced first). It should not but who knows....
I'd just like to make a final check on all nodes and make a final test in the other chain.
So I will come back here in about ~2hours and I really hope that we can deliver the update then to you
best regards exocoin
We decided to totally reorganize the udp and udp reliable part. That took of course time to thoroughly investigate after coding was done.
Anyway we come up now with 150 lines less code than before and - more important - it is more straight forward and cleaner than before. We also improved the logging speed (if many transactions per seconds appear this is somewhat not irrelevant, however, the logging will be reduced once it will have to deal with more people). We cleared one memory waste but we will seek for not freed memory with 0.6 more thoroughly.
If 0.59.3 runs stable until the planned eta of 0.6 (to be announced) then the next version will be 0.6 instead of 0.59.4
Also, if it runs stable for the next days then the launch early june seems realistic to us. No major feature is missing, however, we need the proxy part to be done to be more safe against early DDoS attacks. But that is no rocket science so we should get in ready early enough. Features like standing orders can be implemented later on without major troubles as well as the decentral inclient marketplace.
Just created 500 transactions in ~2.5 minutes which translates to 3.3 transactions per second (but note: this speed is not limited by the network but it is limited by my local computer's speed). More important here is not the speed but: all 500 transactions got confirmed and integrated in the block. Then, a new client, was able to download that big block without problems. And that's the major difference to 0.59.2: Even with 0.59.2 we were able to create 2000 transactions (should be still possible
) _but_ a new client was not always able anymore to get that block because of its size. Not always translated to: "a node with very good connection to the network had a good chance to get that block, others not". A block with 500 transactions will be splitted to roughly 250 single udp packets/ethernet frames and if one of them was lost on the way then the 0.59.2 client requested all parts again.With 0.59.3 we not only split those big blocks into small *reliable* packets - if any packet gets dropped then only that one will get queried again - but with our redesign every udp message in the program that is considered to be too big will automatically splitted into reliable ones. So the reliability aspect moved completly into the inner-udp class. But enough said ---
Right now 4 nodes are up, running and synced. Please report if you have troubles syncing beyond block #14 or #15 (but wait to get it synced first). It should not but who knows....
I'd just like to make a final check on all nodes and make a final test in the other chain.
So I will come back here in about ~2hours and I really hope that we can deliver the update then to you
best regards exocoin
added to changelog of this version:
- update: completly reworked udp class
- a connected miner will automatically stop mining the current block if his parent node (==wallet client) quits and will resume once he connects again
- slightly improvement in miner code
download link is available now on our homepage: http://exocoin.org
linux build will be available tomorrow.
please don't spam transactions yet. Just use it "normally" as for now
We would like to ensure that the mining part will be ok before maybe transaction flooding crashes everything. best regards
eXocoin
May 22, 2014, 04:16:35 PM
Good news after some abstinence from me.
We decided to totally reorganize the udp and udp reliable part. That took of course time to thoroughly investigate after coding was done.
Anyway we come up now with 150 lines less code than before and - more important - it is more straight forward and cleaner than before. We also improved the logging speed (if many transactions per seconds appear this is somewhat not irrelevant, however, the logging will be reduced once it will have to deal with more people). We cleared one memory waste but we will seek for not freed memory with 0.6 more thoroughly.
If 0.59.3 runs stable until the planned eta of 0.6 (to be announced) then the next version will be 0.6 instead of 0.59.4
Also, if it runs stable for the next days then the launch early june seems realistic to us. No major feature is missing, however, we need the proxy part to be done to be more safe against early DDoS attacks. But that is no rocket science so we should get in ready early enough. Features like standing orders can be implemented later on without major troubles as well as the decentral inclient marketplace.
Just created 500 transactions in ~2.5 minutes which translates to 3.3 transactions per second (but note: this speed is not limited by the network but it is limited by my local computer's speed). More important here is not the speed but: all 500 transactions got confirmed and integrated in the block. Then, a new client, was able to download that big block without problems. And that's the major difference to 0.59.2: Even with 0.59.2 we were able to create 2000 transactions (should be still possible ) _but_ a new client was not always able anymore to get that block because of its size. Not always translated to: "a node with very good connection to the network had a good chance to get that block, others not". A block with 500 transactions will be splitted to roughly 250 single udp packets/ethernet frames and if one of them was lost on the way then the 0.59.2 client requested all parts again.
With 0.59.3 we not only split those big blocks into small *reliable* packets - if any packet gets dropped then only that one will get queried again - but with our redesign every udp message in the program that is considered to be too big will automatically splitted into reliable ones. So the reliability aspect moved completly into the inner-udp class. But enough said ---
Right now 4 nodes are up, running and synced. Please report if you have troubles syncing beyond block #14 or #15 (but wait to get it synced first). It should not but who knows....
I'd just like to make a final check on all nodes and make a final test in the other chain.
So I will come back here in about ~2hours and I really hope that we can deliver the update then to you
best regards exocoin
We decided to totally reorganize the udp and udp reliable part. That took of course time to thoroughly investigate after coding was done.
Anyway we come up now with 150 lines less code than before and - more important - it is more straight forward and cleaner than before. We also improved the logging speed (if many transactions per seconds appear this is somewhat not irrelevant, however, the logging will be reduced once it will have to deal with more people). We cleared one memory waste but we will seek for not freed memory with 0.6 more thoroughly.
If 0.59.3 runs stable until the planned eta of 0.6 (to be announced) then the next version will be 0.6 instead of 0.59.4
Also, if it runs stable for the next days then the launch early june seems realistic to us. No major feature is missing, however, we need the proxy part to be done to be more safe against early DDoS attacks. But that is no rocket science so we should get in ready early enough. Features like standing orders can be implemented later on without major troubles as well as the decentral inclient marketplace.
Just created 500 transactions in ~2.5 minutes which translates to 3.3 transactions per second (but note: this speed is not limited by the network but it is limited by my local computer's speed). More important here is not the speed but: all 500 transactions got confirmed and integrated in the block. Then, a new client, was able to download that big block without problems. And that's the major difference to 0.59.2: Even with 0.59.2 we were able to create 2000 transactions (should be still possible
) _but_ a new client was not always able anymore to get that block because of its size. Not always translated to: "a node with very good connection to the network had a good chance to get that block, others not". A block with 500 transactions will be splitted to roughly 250 single udp packets/ethernet frames and if one of them was lost on the way then the 0.59.2 client requested all parts again.With 0.59.3 we not only split those big blocks into small *reliable* packets - if any packet gets dropped then only that one will get queried again - but with our redesign every udp message in the program that is considered to be too big will automatically splitted into reliable ones. So the reliability aspect moved completly into the inner-udp class. But enough said ---
Right now 4 nodes are up, running and synced. Please report if you have troubles syncing beyond block #14 or #15 (but wait to get it synced first). It should not but who knows....
I'd just like to make a final check on all nodes and make a final test in the other chain.
So I will come back here in about ~2hours and I really hope that we can deliver the update then to you
best regards exocoin
Very nice! Honestly I would like to see the decentralized marketplace to be ready on release day. Well, can't have everything I guess.
May 22, 2014, 03:05:55 PM
Nice see major update! Thx to the devs!
May 22, 2014, 02:58:56 PM
Good news after some abstinence from me.
We decided to totally reorganize the udp and udp reliable part. That took of course time to thoroughly investigate after coding was done.
Anyway we come up now with 150 lines less code than before and - more important - it is more straight forward and cleaner than before. We also improved the logging speed (if many transactions per seconds appear this is somewhat not irrelevant, however, the logging will be reduced once it will have to deal with more people). We cleared one memory waste but we will seek for not freed memory with 0.6 more thoroughly.
If 0.59.3 runs stable until the planned eta of 0.6 (to be announced) then the next version will be 0.6 instead of 0.59.4
Also, if it runs stable for the next days then the launch early june seems realistic to us. No major feature is missing, however, we need the proxy part to be done to be more safe against early DDoS attacks. But that is no rocket science so we should get in ready early enough. Features like standing orders can be implemented later on without major troubles as well as the decentral inclient marketplace.
Just created 500 transactions in ~2.5 minutes which translates to 3.3 transactions per second (but note: this speed is not limited by the network but it is limited by my local computer's speed). More important here is not the speed but: all 500 transactions got confirmed and integrated in the block. Then, a new client, was able to download that big block without problems. And that's the major difference to 0.59.2: Even with 0.59.2 we were able to create 2000 transactions (should be still possible ) _but_ a new client was not always able anymore to get that block because of its size. Not always translated to: "a node with very good connection to the network had a good chance to get that block, others not". A block with 500 transactions will be splitted to roughly 250 single udp packets/ethernet frames and if one of them was lost on the way then the 0.59.2 client requested all parts again.
With 0.59.3 we not only split those big blocks into small *reliable* packets - if any packet gets dropped then only that one will get queried again - but with our redesign every udp message in the program that is considered to be too big will automatically splitted into reliable ones. So the reliability aspect moved completly into the inner-udp class. But enough said ---
Right now 4 nodes are up, running and synced. Please report if you have troubles syncing beyond block #14 or #15 (but wait to get it synced first). It should not but who knows....
I'd just like to make a final check on all nodes and make a final test in the other chain.
So I will come back here in about ~2hours and I really hope that we can deliver the update then to you
best regards exocoin
We decided to totally reorganize the udp and udp reliable part. That took of course time to thoroughly investigate after coding was done.
Anyway we come up now with 150 lines less code than before and - more important - it is more straight forward and cleaner than before. We also improved the logging speed (if many transactions per seconds appear this is somewhat not irrelevant, however, the logging will be reduced once it will have to deal with more people). We cleared one memory waste but we will seek for not freed memory with 0.6 more thoroughly.
If 0.59.3 runs stable until the planned eta of 0.6 (to be announced) then the next version will be 0.6 instead of 0.59.4
Also, if it runs stable for the next days then the launch early june seems realistic to us. No major feature is missing, however, we need the proxy part to be done to be more safe against early DDoS attacks. But that is no rocket science so we should get in ready early enough. Features like standing orders can be implemented later on without major troubles as well as the decentral inclient marketplace.
Just created 500 transactions in ~2.5 minutes which translates to 3.3 transactions per second (but note: this speed is not limited by the network but it is limited by my local computer's speed). More important here is not the speed but: all 500 transactions got confirmed and integrated in the block. Then, a new client, was able to download that big block without problems. And that's the major difference to 0.59.2: Even with 0.59.2 we were able to create 2000 transactions (should be still possible
) _but_ a new client was not always able anymore to get that block because of its size. Not always translated to: "a node with very good connection to the network had a good chance to get that block, others not". A block with 500 transactions will be splitted to roughly 250 single udp packets/ethernet frames and if one of them was lost on the way then the 0.59.2 client requested all parts again.With 0.59.3 we not only split those big blocks into small *reliable* packets - if any packet gets dropped then only that one will get queried again - but with our redesign every udp message in the program that is considered to be too big will automatically splitted into reliable ones. So the reliability aspect moved completly into the inner-udp class. But enough said ---
Right now 4 nodes are up, running and synced. Please report if you have troubles syncing beyond block #14 or #15 (but wait to get it synced first). It should not but who knows....
I'd just like to make a final check on all nodes and make a final test in the other chain.
So I will come back here in about ~2hours and I really hope that we can deliver the update then to you
best regards exocoin
\o/ great news!!
May 22, 2014, 02:50:02 PM
Good news after some abstinence from me.
We decided to totally reorganize the udp and udp reliable part. That took of course time to thoroughly investigate after coding was done.
Anyway we come up now with 150 lines less code than before and - more important - it is more straight forward and cleaner than before. We also improved the logging speed (if many transactions per seconds appear this is somewhat not irrelevant, however, the logging will be reduced once it will have to deal with more people). We cleared one memory waste but we will seek for not freed memory with 0.6 more thoroughly.
If 0.59.3 runs stable until the planned eta of 0.6 (to be announced) then the next version will be 0.6 instead of 0.59.4
Also, if it runs stable for the next days then the launch early june seems realistic to us. No major feature is missing, however, we need the proxy part to be done to be more safe against early DDoS attacks. But that is no rocket science so we should get in ready early enough. Features like standing orders can be implemented later on without major troubles as well as the decentral inclient marketplace.
Just created 500 transactions in ~2.5 minutes which translates to 3.3 transactions per second (but note: this speed is not limited by the network but it is limited by my local computer's speed). More important here is not the speed but: all 500 transactions got confirmed and integrated in the block. Then, a new client, was able to download that big block without problems. And that's the major difference to 0.59.2: Even with 0.59.2 we were able to create 2000 transactions (should be still possible ) _but_ a new client was not always able anymore to get that block because of its size. Not always translated to: "a node with very good connection to the network had a good chance to get that block, others not". A block with 500 transactions will be splitted to roughly 250 single udp packets/ethernet frames and if one of them was lost on the way then the 0.59.2 client requested all parts again.
With 0.59.3 we not only split those big blocks into small *reliable* packets - if any packet gets dropped then only that one will get queried again - but with our redesign every udp message in the program that is considered to be too big will automatically splitted into reliable ones. So the reliability aspect moved completly into the inner-udp class. But enough said ---
Right now 4 nodes are up, running and synced. Please report if you have troubles syncing beyond block #14 or #15 (but wait to get it synced first). It should not but who knows....
I'd just like to make a final check on all nodes and make a final test in the other chain.
So I will come back here in about ~2hours and I really hope that we can deliver the update then to you
best regards exocoin
We decided to totally reorganize the udp and udp reliable part. That took of course time to thoroughly investigate after coding was done.
Anyway we come up now with 150 lines less code than before and - more important - it is more straight forward and cleaner than before. We also improved the logging speed (if many transactions per seconds appear this is somewhat not irrelevant, however, the logging will be reduced once it will have to deal with more people). We cleared one memory waste but we will seek for not freed memory with 0.6 more thoroughly.
If 0.59.3 runs stable until the planned eta of 0.6 (to be announced) then the next version will be 0.6 instead of 0.59.4
Also, if it runs stable for the next days then the launch early june seems realistic to us. No major feature is missing, however, we need the proxy part to be done to be more safe against early DDoS attacks. But that is no rocket science so we should get in ready early enough. Features like standing orders can be implemented later on without major troubles as well as the decentral inclient marketplace.
Just created 500 transactions in ~2.5 minutes which translates to 3.3 transactions per second (but note: this speed is not limited by the network but it is limited by my local computer's speed). More important here is not the speed but: all 500 transactions got confirmed and integrated in the block. Then, a new client, was able to download that big block without problems. And that's the major difference to 0.59.2: Even with 0.59.2 we were able to create 2000 transactions (should be still possible
) _but_ a new client was not always able anymore to get that block because of its size. Not always translated to: "a node with very good connection to the network had a good chance to get that block, others not". A block with 500 transactions will be splitted to roughly 250 single udp packets/ethernet frames and if one of them was lost on the way then the 0.59.2 client requested all parts again.With 0.59.3 we not only split those big blocks into small *reliable* packets - if any packet gets dropped then only that one will get queried again - but with our redesign every udp message in the program that is considered to be too big will automatically splitted into reliable ones. So the reliability aspect moved completly into the inner-udp class. But enough said ---
Right now 4 nodes are up, running and synced. Please report if you have troubles syncing beyond block #14 or #15 (but wait to get it synced first). It should not but who knows....
I'd just like to make a final check on all nodes and make a final test in the other chain.
So I will come back here in about ~2hours and I really hope that we can deliver the update then to you
best regards exocoin
May 22, 2014, 10:25:01 AM
I don't know it, but I would say that is the normal result for an IPO like this.
reddit: reddit.com/r/eXocoin
reddit: reddit.com/r/eXocoin
May 22, 2014, 10:11:01 AM
How is the promotion going, is there already a facebook page, reddit?
Maybe we can already start doing something for the promotion.
Maybe we can already start doing something for the promotion.
May 22, 2014, 10:09:04 AM
I want sell my 1.5 btc first ipo exo, sell 15btc who want can pm me.
my offer is 5btc.anyone interested can PM me.
maybe u can buy when it lanch.
At launch the 1,5 BTC will be worth about 50 BTC. So I would not sell.
Why do you think that?
How much will it be after a month and after 3 months?
May 22, 2014, 09:58:33 AM
i agree with this, look at qora which has *30 of its ipo cost, and exo deserve at least *20—*50 it's ipo cost.
so 1.5btc first period ipo may reach at least 20btc after launch.
btw total qora 10 000 000 000/total exo 100 000 000=100/ exo price *100.why not?so 1.5btc first period ipo may reach at least 20btc after launch.
May 22, 2014, 09:52:39 AM
i think devs took an all-nighter and are sleeping!
i love you guys!
i love you guys!
maybe, have a nice sleep. still wait...
May 22, 2014, 09:49:40 AM
i think devs took an all-nighter and are sleeping!
i love you guys!
i love you guys!
May 22, 2014, 06:58:38 AM
Dont understand why on earth someone would sell their stakes at this point... EXOcoin gonna rock !
because qora make some success on their ipo.
personal think exo is better.
May 22, 2014, 05:43:03 AM
Dont understand why on earth someone would sell their stakes at this point... EXOcoin gonna rock !
May 22, 2014, 05:31:31 AM
please do not talk about prices now, talk about wanted features, things to do.
more cool features, more successfull the eXocoin!!
waiting BIG news from the devs!!!
more cool features, more successfull the eXocoin!!
waiting BIG news from the devs!!!
May 22, 2014, 05:16:24 AM
I want sell my 1.5 btc first ipo exo, sell 15btc who want can pm me.
my offer is 5btc.anyone interested can PM me.
maybe u can buy when it lanch.
At launch the 1,5 BTC will be worth about 50 BTC. So I would not sell.
i agree with this, look at qora which has *30 of its ipo cost, and exo deserve at least *20—*50 it's ipo cost.
so 1.5btc first period ipo may reach at least 20btc after launch.
May 22, 2014, 04:58:37 AM
I want sell my 1.5 btc first ipo exo, sell 15btc who want can pm me.
my offer is 5btc.anyone interested can PM me.
maybe u can buy when it lanch.
At launch the 1,5 BTC will be worth about 50 BTC. So I would not sell.
May 22, 2014, 04:43:47 AM
I want sell my 1.5 btc first ipo exo, sell 15btc who want can pm me.
my offer is 5btc.anyone interested can PM me.
maybe u can buy when it lanch.
May 22, 2014, 04:37:34 AM
I want sell my 1.5 btc first ipo exo, sell 15btc who want can pm me.
my offer is 5btc.anyone interested can PM me.
Jump to: