Topic: ⚡[ANN]⚡ ▐░Espers [ESP]░▌▐░PoW/PoS░▌▐░HMQ1725 Algo░▌ ▐░New Features░▌ - page 706. (Read 924216 times)

Great job! We wait yobit.

Great job guys!

good to hear yobir will list this, there are some buys on nova already and its not a small amount too, it could be a boost to have yobit as 2nd exchanges

what are the chances that the addition yobit to give impetus to the growth of or even be enliven trade. On yobit no LTC Market and the last sale is in the region of 10 - 9 litoshi.

You can either:
Copy the wallet.dat file from %APPDATA%\Espers\wallet.dat on the old machine to the new one.  When doing this, close both Espers clients.  Once done and you open up the new wallet, you will see your address there.

Export and then import your private key(s) through the console in the debug window.

How can i import wallet date to another pc? downloaded updated client, but can't seem to find a way to fuse their data.

Make sure you start wallet from that new icon, not the old one which in my case would be pinned in to taskbar.

I did update but wallet still show 8.0.2 not 8.0.3??

Hey OCMiner,

Because i know a mining pool is a business in a sense, and i hate to see a business lose money at no fault of their own and earn a bad rep, im going to give you this bit of friendly advice because i saw it in the code and have since tested it to make sure i wasnt mistaken.

actually... this goes for all services/users that are running a daemon as opposed to a gui client.


Do NOT send a transaction of less than 0.01 from the daemon. there is NO check in the code for a lower limit free transaction that the miner will later consider too low of a priority and never send. you will lose all outputs from that missing input branch. if your services code does not automatically pay a fee to send a tx, then you might lose coins due to this bug.

what i mean by this is:
say you mine a block and get 50,000 coins. you then send 0.001 from the daemon to another wallet (for whatever reason) and it uses that 50k esper block you just mined as input. this is what will happen. it will take that 50k input. mark it as spent. and create a transaction that sends the 0.001 to another wallet and returns the 49999.999 to your wallet. this is the standard for every transaction ever, including bitcoin so dont think this is weird, this is how the system works. that part is normal.

what the problem is, is that the espers daemon (Espersd) will not warn you or preform a check to see if that makes the priority too low for the transaction to be passed into a block due to the way the min tx fee is structured (there isnt one, esp allows free transactions) and will in turn NEVER process that tx into a block. since the 0.001 transaction was not processed, the 49,999.999 is also never reconnected to your wallet and you lose those coins. (they will still show up in your wallet, but because the input for any transaction that includes those coins is now reliant on the 0.001 transaction that was never processed it is impossible to send them anywhere as they too will never be processed due to missing inputs).

until they fix this with the daemon (to be honest the gui client might also do this but i havent tested it and wont be testing it tonight) you should add

paytxfee=0.01

to your Espers.conf file so that this fee will stop you from accidentally losing coins by sending a too low priority transaction because a fee will raise the priority of the transaction causing it to be packaged. i did test it and it does ensure that all transactions down to the lowest sendable amount (0.00055) will be send and will be processed by the miners.

i would go over this in code but its 3:45 am, so you can test it if you'd like (although send coins, say 100 coins, to a NEW wallet on a SEPARATE MACHINE before testing it, you WILL LOSE COINS DURING TEST) or you can take my word for it because i already tested it.

[FULL DISCLOSURE: i originally thought this was a merkle building problem and that is why small transactions with no fee are never processed, but the addition of the fee, which i know for a fact raises the priority in the miner for that transaction, causes the small transactions to be processed leads me to believe it is more than likely a priority issue]

-Griffith


edit: i know from reading this the most obvious fix is just to check to see if the amount sent is below 0.01, which yes. does patch the issue for the future, but it doesnt fix the actual problem at heart. just covers it up, like the government on a tuesday (that last part is a joke for anyone who doesnt get it, its supposed to be funny)

Thanks for the assurance Crypto it is the first thing comes up to my mind when it said that there's some changes that is needed to be done its alarmed me because I still using the old wallet and after reading your answer with Bitwarrior question it make me more comfortable now, you are such a great dev always ready and firm to its answer, might need some tweet to spread your taught just let me know or tweet it to me much be appreciate to do some help to this community even I don't have financial capability. good luck dev team.

Definitely, they are a significant help.
Additionally, you may not be I  the dev team but you are certainly avery valued member of the community.
(Stop it, if you keep this up we might have to send you a promo shirt as hush swag... jk about the hush and stopping part)

This will have no affect on coin count or your coin balance.
We would never do something to risk that.

Great info and awesome job of all parties. It's amazing too see how this project gets support more and more. all the whining is gone now that people start seeing potential
and realize that those goals that been set will be achieved.

Even thou i'm not in the dev team i like to thank ocminer and Griffith for support.

this is cool crypto we will wait for this update and please let us know as well if we needed  to update our wallet or we can still use the same old one. good luck dev team.

Just checking if the implementation of this fork will not affect the amount of coins in our wallet once this has been implemented?

Wait to added to yobit.

Thanks! It's great to see support!



@everyone,

thanks to Griffiths in-depth explanation we will conduct some minor testing on a test chain and correct the withdrawal limit that is being caused to ocminer's pool for ESP.

Apparently through all the craziness of launching the daemon side of the system was not as refined as we would have liked even in the Alpha stage.


We thank you all for being with us through this alpha phase of development and want to give a shout out to ocminer for continuously supporting us and pointing out issues even though we haven't always been the kindest in our response.
Also thank you Griffith for taking the time to point out the specifics and practically write aguide for us. Honestly with your permission we would like to refine it some and even post it as aresource on our site. But we'll wait to hear back.

This update will more than likely require a fork and as such we recommend users to run the auto updating client to avoid any potential issues.
Anyone running the standalone client will need to upgrade to avoid experiencing any issues manually.

Before any major changes occur we will announce the correction to the transaction limit and the block height that the change will occur before applying anything.

Once more, thank you all for being a wonderful part of this journey and we hope to see you all enjoy what we have to offer.

so i am ready to pick esp on yobit nice to hear this ESP on yobit