I have encountered the same problem and lost more than 300,000 PASC Hi all ! There is a problem with the balance on the wallet, or rather, the balance has disappeared and I cannot restore it. Background: 1. This coin was mined about a year ago. The wallet was version 5.3 - 2020-03-12 (PascalCoinWalletB5.3.3.0_64b.exe). If you launch it now, there is a balance! 2. If you install the version (any of the above) - synchronization goes through, everything is ok, but - there is no balance, and most importantly - he does not see the wallet! The address is simply absent, and any actions such as importing a private key or slipping a backup copy of a wallet do not change anything! Actually the question is - what is it and how to fix it?  UPD And that's not all ... A few hours later, I looked into my wallet ... And again there is nothing !!!! There is no wallet number or balance. There are 28 messages about protocol change ... What's going on? Is this how it should be? |
|
|
|
|
Beware of the kucoin exchange, the DERO you deposited may not belong to your account, especially large transfers.
I have spent 4 days to communicate with the customer service, and was asked to provide a 30USDT processing fee.
No progress has been made, and the customer service is quite unprofessional.
|
|
|
|
|
good pump and good dump
95.2% unknown hashrate,is there a secret ASIC?
|
|
|
|
|
TestNet Bug report,
PascalCoinWallet_TESTNET_5.Beta.1_Windows and PascalCoinWallet_TESTNET_5.Beta.2_Windows have the same problem.
Miner sometimes doesn't work , debug，then found RPC info "part1" length is 89 bytes, the general case is 90 bytes.
both wallet and miner are running on WIN7 X64.
|
|
|
|
|
I revisited the URandomHash2 code, the problem with the nonce scan still exists, and I found a new flaw.
Too small memory requirements will make FPGAs easier to implement.
Suggest:
1. Do not use final round in the middle state, miner must calculate the full round
2. Increase the M size so that the final memory requirement reaches 2MB or more.
|
|
|
|
|
a bug in RandomHash2.
URandomHash2.pas
line 267
LParentOutputs := Hash(ABlockHeader, ARound - 1, AFoundLastRound);
if AFoundLastRound > 0 then
// Previous round was the final round, so just return it's value
Exit(LParentOutputs); //bug is here
There are 1/4 chances in round 2, returning results,without continue calculating the data behind,
Discarding some nones will result in hundreds of performance gains
|
|
|
|
|
When to upgrade to phi3 and kick FPGA out?
|
|
|
|
diff jump and price drop, It's obvious new FPGA/ASIC miner join in. Version Count Donators ES Percent Hashrate* Avg ccminer/2.3 488 - 218 18.82% 11.6 GH/s 23.7 MH/s CryptoDredge/0.10.0 199 - 196 5.43% 3.3 GH/s 16.8 MH/s CryptoDredge/0.9.3 141 - 140 5.24% 3.2 GH/s 22.9 MH/s CryptoDredge/0.8.3 137 - 134 3.47% 2.1 GH/s 15.6 MH/s CryptoDredge/0.9.7 124 - 124 5.57% 3.4 GH/s 27.7 MH/s CryptoDredge/0.9.5 99 - 99 3.66% 2.3 GH/s 22.7 MH/s ccminer/2.2.3 95 - 95 32.53% 20 GH/s 210.8 MH/s  ???what a fuck CryptoDredge/0.9.4 74 - 74 2.7% 1.7 GH/s 22.5 MH/s |
|
|
|
|
glad to see dev. I still mine hppcoin.
|
|
|
|
I forgot to say that I am using the latest 5.2.3 qt-win wallet. |
|
|
|
|
wallet crash after staking for hours
assertion failed
file:coins.cpp,line 204
expression:it->second.flags&CcoinCacheEntry::FRESH
|
|
|
|
now you will see the asic miners on https://bsod.pw/site/miners xvg lyra2v2 Miners Version (xvglyra) Version Count Donators ES Percent Hashrate* Avg cgminer/4.11.1 9 - - 108.24% 37 GH/s 4.1 GH/s CryptoDredge/0.9.1 2 - 2 0.21% 70.2 MH/s 35.1 MH/s Total 11 0 2 34.1 GH/s 3.1 GH/s |
|
|
|
next lyra2z ASIC?
XZC fork is coming ,the lyra2Z ASIC is useless |
|
|
|
|
lol, do you think BCU1525 can earn back the investment in its life time?
|
|
|
|
If you think the boards will lose their value then don't buy them. I definitely remember you from discord. FUD.
I'm not going to buy it. I'm going to make more people aware of the risks and they're being tested. |
|
|
|
A new risk, if the chip is locked by KEY, then the board is worthless unless you know the key, it have no second-hand value like GPU
The key doesn't prevent unencrypted designs from running. Keep in mind, if we didn't do this it would also open an attack vector where a developer could maliciously burn the efuse preventing any designs from operating but their own. I'm pretty sure you were already told this on discord? no, i did not talk on discord, i review it. also i found the pdf,xapp1267,eFuse is OTP,it can lock the chip to a key. So if you reviewed the documentation you would know that the chip can still load unencrypted bitstreams (assuming you use the correct options). Once the key is loaded, yes, the key cannot be changed. The ram key is wiped when the board loses power. The board doesn't have a battery. if you control the software,you can use another way to protect your work.NO EFUSE ,NO battery RAM needed. 1.when board begin to run ,it gen a random number,and append your secretive key1,then SHA2(or others algo) it 2.software read the hash message,send to a server,(the miner is online,so it is easy to connect the server) 3.the server append the hash with your secretive key2,then SHA2(or others algo) it ,send back 4.the board check the result,if match ,run miner,otherwise ,do nothing. so ,you just need two key, every new developer or new algo can have his own key, also the boards will not lose their value. |
|
|
|
|
Show Posts
