Wallet still doesn't sync... it's stuck at 204673 block...
FYI: Just download the CLI wallet version, and run citadeld.exe for a while. For whatever reason, the CLI version can sync up to date no problem. Then close citadeld.exe and open the GUI version again. Should be all good. |
|
|
|
Wallet still doesn't sync... it's stuck at 204673 block...
same here |
|
|
|
How is it possible this project is 3.5yrs old and no GUI wallet??
A stroke of luck, perhaps |
|
|
|
whats the status of this coin ? anonymous coins are going to be huge this year I mined a few aeon coins, but this coin has been out since 2014 but no GUI wallet (really hurting its mass adoption) ? I think the coin could really be the Litecoin of monero if it had some updates , Im watching Sumo concerned that it will surpass Aeon (nice wallet clear roadmap that's hitting its goals) and become what we thought Aeon was going to be come. Is the Dev working on this project still or is it abandoned ?
I believe the dev, smooth, is rebasing the code to bring Aeon's tech in line with the current state of Monero. There's isn't much activity on github though, so I'm hoping this development is happening on a private branch and we'll see the results one day. |
|
|
|
devs - please remember to update download links on the website  |
|
|
|
The reason payouts find yourself in trouble happens because the dev of the coin hasn't released any updated to repair the wallet "caught" problem like cash such at BCN and MRO he done.Around the swimming pools, when the daemon car saves, the pocket book times out and then will get Inchstuck," causing payouts to get caught before the pocket book is resynced.This can be a recognized problem, and was a known problem with other coins too, and the dev's for all those other cash have fixed this issue.I've informed the dev for Aeon of the issue along with the fix, publicly on this thread, but I have yet to see an update to fix it. Hopefully there is was soon. For now, like I stated several articles up, I simply got back to my computer and I will undergo and connect all impending repayments soon, should go out within the next hr.av
I just found out about AEON and was happy to have found it and wanted to invest, but there is a problem with the wallet that is not fixed yet am I understanding correctly? I dont understand all the tech talk, so please elaborate to me in plain words: when I buy AEON now, will I be able to transfer them from the exchange to a safe wallet and hold them there and eventually send them out again? Hope I get an answer! The wallet can send and receive OK. I don't know what issue Sm00thIy is referring to. |
|
|
|
|
Anyone aware of what happens if you try too many transfers in quick succession? I did two transfers last night, the second one being before my unlocked balance matched the balance.
Transactions in the second transfer do not appear in the AEON blockchain at all, yet my wallet balance is terribly low, so the wallet thinks those coins were spent.
Will the transfer time out eventually, and coins appear back in my wallet?
|
|
|
|
|
Is there a bootstrap available from someone on the good chain? This might help get more people up to speed with the latest wallet.
|
|
|
|
I see that aeon-pool(dot)com has put a notice to encourage miners to mine on other pools in order to help decentralizing the network and prevent a pool from having more than 50% of the entire network's hash. That's a really nice move.
One thing that discourage miners from moving to a different pool is the pending balance below the payment threshold (the so called 'dust'). Even 0.001 AEON will be worth something in the near future.
So, I have a suggestion to pool operators:
If a miner stops mining on your pool for, let's say, 24 or 48 hours then all the pending balance (no matter how small) should be paid to the miner.
Just my 2 satoshis
I agree that this is a problem, and I like your solution. The only consideration is that the solution should not cost the pool transaction fees. Provided the dust owed to the miner is more than the tx fee, should be good! |
|
|
|
5) You are a shop owner, and have registered a Monero address with the IRS as your official retailer address. You use this address for receiving payments from all of your customers. At the end of the year, the tax man uses the view key you provided them with to check how much you received, so that you pay the appropriate taxes....
Good stuff, but seriously, the IRS using your viewkey? The IRS forms are ancient, they have nothing for that sort of thing, so how will that ever work in this day and age? I understand it and agree, but I don't see the IRS actually giving any shits about that kind of thing. It's hard enough to claim BTC on tax forms, let alone any other crypto!  Monero is doing pretty well. Great to see ongoing developement.
Monero is so undervalued it's crazy. I'd still buy more if I could.  I suppose it's likely the IRS will barely have Bitcoin on their radar, never mind Monero, but I was simply pointing out to chilly2k the fact that if the day comes when people are using Monero, they can prove their income and pay relevant taxes with the use of a viewkey. The IRS will need to figure out crypto soon enough. |
|
|
|
Monero Privacy is NOT a crime or something to feel guilty about: https://www.reddit.com/r/Monero/comments/6uldp2/monero_privacy_is_not_a_crime_or_something_to/1) You are traveling through parts of a country with a medium to high violent crime rate. You need to use some of your Bitcoin to pay for something. If every person you transact with knows exactly how much money you have, this is a threat to your personal physical safety. 2) You are a business that receives a payment from a supplier. That supplier will be able to see how much money your business has, and therefore can guess at how price sensitive you are in future negotiations. They can see every single other payment you’ve ever received to that Bitcoin address, and therefore determine what other suppliers you are dealing with and how much you are paying those suppliers. They may be able to roughly determine how many customers you have and how much you charge your customers. This is commercially sensitive information that damages your negotiating position enough to cause you relative financial loss. 3) You are a private citizen paying for online goods and services. You are aware that it is common practice for companies to attempt to use ‘price discrimination’ algorithms to attempt to determine the highest prices they can offer future services to you at, and you would prefer they do not have the information advantage of knowing how much you spend and where you spend it. 4 You sell cupcakes and receive Bitcoin as payment. It turns out that someone who owned that Bitcoin before you was involved in criminal activity. Now you are worried that you have become a suspect in a criminal case, because the movement of funds to you is a matter of public record. You are also worried that certain Bitcoins that you thought you owned will be considered ‘tainted’ and that others will refuse to accept them as payment. Monero solves these privacy issues by automatically applying privacy techniques to every single transaction made. You can have confidence that it is not possible to own ‘tainted’ Monero. This is a concept in economics known as ‘fungibility’ and is historically considered an important characteristic for any currency to have. Regards, So Monero is kind of like not showing your tax returns. Should be one big supporter in the US white house.... 5) You are a shop owner, and have registered a Monero address with the IRS as your official retailer address. You use this address for receiving payments from all of your customers. At the end of the year, the tax man uses the view key you provided them with to check how much you received, so that you pay the appropriate taxes.... |
|
|
|
After patch it should be apparent if exploit was taken advantage of, right? Anyway care to chime in? I haven't synced in almost a year probably...
Due to this logic, key image validity will not be checked below the highest checkpoint. So if you want to see if there are any exploits you will need to remove the newly added checkpoints hereGiven that there would be little other reason to add those checkpoints now when there were never checkpoints in bitcedi before, I have a suspicion that there were key image exploits, but that is just a guess. EDIT: I also noticed an explicit block height condition here. That would need to be removed as well if you want to check for earlier exploits. My assumption then is that the exploit has been used, and this code hides it. lulworm, Is there another reason for these checkpoints? |
|
|
|
Good point. I should have looked there myself I notice from luigi and fluffy's post that there was code run to check whether the exploit was used on the Monero blockchain, and this found it had not been exploited in Monero. Out of curiosity, do you know if this code has been used to check other blockchain's? |
|
|
|
|
How often does pool.projectwyvern.com pay miners?
|
|
|
|
- Windows version
- Driver version and where you obtained it
- Video card bios version
Thanks, I'd appreciate it. Windows 10 Driver version in 17.4.4, obtained directly from AMD. I've tried a few other versions too, but I forget them all. BIOS version is the latest from MSI 015.050.000.000 (the card came installed with this BIOS - I've not changed it) Forgot to ask which version of sgminer you're using (if you're not using 5.6.1 from https://github.com/nicehash/sgminer/releases, give it a try. If you are, try the previous version). I was using 4.1.0, linked in the OP. I've tried 5.6.1 now, same issue though unfortunately. Seems the nicehash miner isn't working for the team member either (he's using Crimson ReLive 17.1.1 drivers though). Try this config with sph-sgminer: "intensity" : "18",
"worksize" : "256",
"kernel" : "nist5",
"lookup-gap" : "2",
"thread-concurrency" : "8192",
"shaders" : "0",
"gpu-threads" : "2",
"gpu-engine" : "0-0",
"gpu-fan" : "0-0",
"gpu-memclock" : "0",
"gpu-memdiff" : "0",
"gpu-powertune" : "0",
"gpu-vddc" : "0.000",
"temp-cutoff" : "95",
"temp-overheat" : "85",
"temp-target" : "75",
"api-mcast-port" : "4028",
"api-port" : "4028",
"expiry" : "28",
"failover-switch-delay" : "60",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "7",
"tcp-keepalive" : "30",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin" That works with sph-sgminer. Will play around on the newer version later, but looks like something in my conf was the issue. Thanks very much! You're very welcome. FWIW: we also tried this config with the newer versions and continued to have bluescreens, so something is definitely funky. Out of curiosity, would you mind following the instructions at https://github.com/nicehash/NiceHashMiner/issues/873 and attaching your debug log? I too get a blue screen when I use the same config with the nicehash miner. I've run the check_all_AMD.bat as requested. It didn't give much output. Is this all you need, or is it the sgminer log you'd like? If so, could you give me the switches to use to get log output? [
{
"PlatformName": "AMD Accelerated Parallel Processing",
"PlatformNum": 0,
"Devices" : [
{
"DeviceID" : 0,
"AMD_BUS_ID" : 2,
"_CL_DEVICE_NAME" : "Ellesmere",
"_CL_DEVICE_TYPE" : "GPU",
"_CL_DEVICE_GLOBAL_MEM_SIZE" : 8589934592,
"_CL_DEVICE_VENDOR" : "Advanced Micro Devices, Inc.",
"_CL_DEVICE_VERSION" : "OpenCL 2.0 AMD-APP (2348.3)",
"_CL_DRIVER_VERSION" : "2348.3"
}
]
}
] Cheers. |
|
|
|
- Windows version
- Driver version and where you obtained it
- Video card bios version
Thanks, I'd appreciate it. Windows 10 Driver version in 17.4.4, obtained directly from AMD. I've tried a few other versions too, but I forget them all. BIOS version is the latest from MSI 015.050.000.000 (the card came installed with this BIOS - I've not changed it) Forgot to ask which version of sgminer you're using (if you're not using 5.6.1 from https://github.com/nicehash/sgminer/releases, give it a try. If you are, try the previous version). I was using 4.1.0, linked in the OP. I've tried 5.6.1 now, same issue though unfortunately. Seems the nicehash miner isn't working for the team member either (he's using Crimson ReLive 17.1.1 drivers though). Try this config with sph-sgminer: "intensity" : "18",
"worksize" : "256",
"kernel" : "nist5",
"lookup-gap" : "2",
"thread-concurrency" : "8192",
"shaders" : "0",
"gpu-threads" : "2",
"gpu-engine" : "0-0",
"gpu-fan" : "0-0",
"gpu-memclock" : "0",
"gpu-memdiff" : "0",
"gpu-powertune" : "0",
"gpu-vddc" : "0.000",
"temp-cutoff" : "95",
"temp-overheat" : "85",
"temp-target" : "75",
"api-mcast-port" : "4028",
"api-port" : "4028",
"expiry" : "28",
"failover-switch-delay" : "60",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "7",
"tcp-keepalive" : "30",
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin" That works with sph-sgminer. Will play around on the newer version later, but looks like something in my conf was the issue. Thanks very much! |
|
|
|
|
Show Posts
