hyc specifically said x86, as in 32 bit arch, not x86_64. From reading the IRC, the 64 bit ones still need those libs, as you found out. This may soon be done with as well, but for not yet now.
Thanks for explanation, I think that then those dlls should be included in x64 archive, obviously they merely forgotten by mistake. |
|
|
|
I removed previously copied from 0.0.3 dlls and without them simplewallet doesn't work, it sais: The program can't start because libwinpthread-1.dll is missing from your computer. Try reinstalling the program to fix this problem. So I put them back. Ah, and I have monero.win.x64.v0-9-4-0 |
|
|
|
I took dlls form 0.9.3. And it seems to be working  |
|
|
|
Concerning sweep_dust errors, it can be due to tiny inputs for which there is no enough inputs to mixin with. Trying to sweep_dust, daemon says: Tx <...> has too low mixin (0), and more than one mixable input with unmixable inputs. For example, when I am trying to send some xmr that left on my hot wallet, most of which consists of dust gives me an error: Error: not enough outputs for specified mixin_count = 4:
output amount = 0.003811120000, found outputs to mix = 1
output amount = 0.007507490000, found outputs to mix = 1
output amount = 0.007723640000, found outputs to mix = 1
output amount = 0.003594340000, found outputs to mix = 2
output amount = 0.003064900000, found outputs to mix = 1
........ and so on....
There is enough 278.475450179850 xmr including unlocked dust 1.247663779850 I wonder why balance differs after two digits after comma where dust begins. I am not good at math [edit]: I am OK with that unusable dust, just hope everything works correctly. From IRC: <moneromooo> I think the <1e-2 part should be the same, yes. Maybe I'm missing a case. <moneromooo> The sweep_dust failure is likely because it's dust that's too small, that is it's less than amount needed to send itself. <moneromooo> Nothing can be done about those, except wait to see if fees go down later. <moneromooo> One *could* pair a large output with a tiny dust one, and send, but you'd lose the dust and more of the large output than the dust, so rather pointless. Thank you for your time. I'll just leave it as it is. It's a 'hot wallet' anyway. I just wanted to try this command sweep_dust and found this error interesting. OK, now after fork I decided to try again. Now it lets me sweep_dust
Sweeping 1.256077939850 for a total fee of 0.060000000000. Is this okay? (Y/Yes/N/No)Y
Error: transaction <143fafd751ccc6f1530e608f5db7acc393590651deb559c2d965df976ecc6f71> was rejected by daemon with status: Failed
daemon says 2016-Mar-24 09:19:14.124499 [RPC1]Tx <143fafd751ccc6f1530e608f5db7acc393590651deb559c2d965df976ecc6f71> has too low mixin (0), and more than one mixable input with unmixable inputs
2016-Mar-24 09:19:14.127498 [RPC1]tx used wrong inputs, rejected
2016-Mar-24 09:19:14.128999 [RPC1]Transaction verification failed: <143fafd751ccc6f1530e608f5db7acc393590651deb559c2d965df976ecc6f71>
2016-Mar-24 09:19:14.130499 [RPC1][on_send_raw_tx]: Failed to process tx
I must have screwed up something Gonna live with dust forever. OK, upgraded to 0.9.4 and managed to get rid of all dust in one of my old hot wallet: Balance: 0.531154229850, unlocked balance: 0.531154229850
[wallet 4AiWeK]: sweep_unmixable
Sweeping 0.299509959850 for a total fee of 0.060000000000. Is this okay? (Y/Yes/N/No)Y
Money successfully sent, transaction: <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e> Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.005397810000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.002935140000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.009024460000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.007789970000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.007684660000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.008264040000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.009665350000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.005714300000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.009685820000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.002667030000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.003594340000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.001224010000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.005082780000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.007507490000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.006756420000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.004659400000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.003106460000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.001332320000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.001449250000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.003811120000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.009560550000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.004146089850
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.002069510000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.000213280000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.009228280000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.006245180000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.007455200000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.007627150000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.007723640000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.006968980000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.000279470000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.002074560000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.004257230000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.008872500000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.007165050000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.004618300000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.007095450000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.002615000000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.057786400000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.005139050000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.003064900000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.001927850000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.002227010000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.007512200000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.006918700000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.004425180000
Height 1016789, transaction <d63c0dd5a5c813ac675f10eca0f5d509d97b254d8a7c8827944e8ab65753695e>, spent 0.004941080000 Now it works!!!! Like a charm!  |
|
|
|
Protect them from being stolen. If the pubkey is revealed quantum computing is able to steal his coins. If you move them to a new address it won't reveal the pubkey of that address, unless you reuse it.
OK, I went and read about it. So, they can't break new 'unused' address, but still they will know that money were moved and now lay at that address. Am I right? Yes that's right. Also the protection only exists while the address are sitting unspent on the blockchain. When you try to spend you have to reveal the public key so QC could still be used to break it during the interval until it is confirmed. That greatly narrows the time window (from years to minutes) and would require a faster QC to be effective. The comments about moving to Monero (maybe in jest?) are off-base. Monero would also be broken by QC and we don't have the protection of publishing hashes of public keys either. Of course we were jocking. I read an article by Vitalik Buterin concerning QC and there were mentioned Lamport Signatures as a solution. And thank you for explanation! I wonder how do you guys have so much time and patience answering all this and that here and on reddit and elsewhere. That's amazing. |
|
|
|
Supposedly this is a 5-qubit bitslice processor, hence scalable, although not yet proven by scaling in practice: http://arxiv.org/abs/1603.04512QC is coming, gradually at first, then quite suddenly. It really is time to panic, before the suddenly phase. What effect does quantum computing have on ECDSA and EdDSA is the question. Both will be broken by it as far as I know. Interestingly, since Satoshi's pubkey is revealed, he has to move this coins in order to "protect" them (i.e. quantum computing will make it possible to steal them). Since they are traceable, how moving them will protect them?  He will have to move them into Monero of course. That's what I wanted to hear  |
|
|
|
Protect them from being stolen. If the pubkey is revealed quantum computing is able to steal his coins. If you move them to a new address it won't reveal the pubkey of that address, unless you reuse it.
OK, I went and read about it. So, they can't break new 'unused' address, but still they will know that money were moved and now lay at that address. Am I right? |
|
|
|
Concerning sweep_dust errors, it can be due to tiny inputs for which there is no enough inputs to mixin with. Trying to sweep_dust, daemon says: Tx <...> has too low mixin (0), and more than one mixable input with unmixable inputs. For example, when I am trying to send some xmr that left on my hot wallet, most of which consists of dust gives me an error: Error: not enough outputs for specified mixin_count = 4:
output amount = 0.003811120000, found outputs to mix = 1
output amount = 0.007507490000, found outputs to mix = 1
output amount = 0.007723640000, found outputs to mix = 1
output amount = 0.003594340000, found outputs to mix = 2
output amount = 0.003064900000, found outputs to mix = 1
........ and so on....
|
|
|
|
Supposedly this is a 5-qubit bitslice processor, hence scalable, although not yet proven by scaling in practice: http://arxiv.org/abs/1603.04512QC is coming, gradually at first, then quite suddenly. It really is time to panic, before the suddenly phase. What effect does quantum computing have on ECDSA and EdDSA is the question. Both will be broken by it as far as I know. Interestingly, since Satoshi's pubkey is revealed, he has to move this coins in order to "protect" them (i.e. quantum computing will make it possible to steal them). Since they are traceable, how moving them will protect them? |
|
|
|
Concerning sweep_dust - I transfered those coins to another wallet but had to split in many transactions and most of the 1 XMR said being dust transfered. But total fee was quite big ~ around 5 XMR fee for sending 280 XMR. There were a lot of tiny inputs that's the reason. Today I caught another interesting error. After PC crash (I guess electricity surge) daemon refused to start: 2016-Mar-25 08:59:38.650014 Initializing core...
2016-Mar-25 08:59:38.652014 Loading blockchain from folder C:\ProgramData\bitmonero\lmdb ...
2016-Mar-25 08:59:38.653514 option: fastest
2016-Mar-25 08:59:38.654514 option: async
2016-Mar-25 08:59:38.655014 option: 1000
2016-Mar-25 08:59:38.698525 Error attempting to retrieve a hard fork version at height 1010595 from the db: MDB_NOTFOUND: No matching key/data pair found
2016-Mar-25 08:59:38.700025 ERROR C:/msys64/DISTRIBUTION-BUILD/src/daemon/daemon.cpp:144 Uncaught exception! Error attempting to retrieve a hard fork version at height 1010595 from the db: MDB_NOTFOUND: No matching key/data pair found
2016-Mar-25 08:59:38.702526 Deinitializing rpc server...
2016-Mar-25 08:59:38.703026 Deinitializing p2p...
2016-Mar-25 08:59:38.707527 Deinitializing core...
2016-Mar-25 08:59:38.709528 Closing IO Service.
2016-Mar-25 08:59:38.741036 Deinitializing cryptonote_protocol... I restored and synced from backup made day earlier and now it works. Maybe this info will be somehow useful to the devs. |
|
|
|
|
So net hash dropped because of botnets gone after fork? Can it be the reason?
|
|
|
|
There is enough 278.475450179850 xmr including unlocked dust 1.247663779850 I wonder why balance differs after two digits after comma where dust begins. I am not good at math [edit]: I am OK with that unusable dust, just hope everything works correctly. From IRC: <moneromooo> I think the <1e-2 part should be the same, yes. Maybe I'm missing a case. <moneromooo> The sweep_dust failure is likely because it's dust that's too small, that is it's less than amount needed to send itself. <moneromooo> Nothing can be done about those, except wait to see if fees go down later. <moneromooo> One *could* pair a large output with a tiny dust one, and send, but you'd lose the dust and more of the large output than the dust, so rather pointless. Thank you for your time. I'll just leave it as it is. It's a 'hot wallet' anyway. I just wanted to try this command sweep_dust and found this error interesting. OK, now after fork I decided to try again. Now it lets me sweep_dust
Sweeping 1.256077939850 for a total fee of 0.060000000000. Is this okay? (Y/Yes/N/No)Y
Error: transaction <143fafd751ccc6f1530e608f5db7acc393590651deb559c2d965df976ecc6f71> was rejected by daemon with status: Failed
daemon says 2016-Mar-24 09:19:14.124499 [RPC1]Tx <143fafd751ccc6f1530e608f5db7acc393590651deb559c2d965df976ecc6f71> has too low mixin (0), and more than one mixable input with unmixable inputs
2016-Mar-24 09:19:14.127498 [RPC1]tx used wrong inputs, rejected
2016-Mar-24 09:19:14.128999 [RPC1]Transaction verification failed: <143fafd751ccc6f1530e608f5db7acc393590651deb559c2d965df976ecc6f71>
2016-Mar-24 09:19:14.130499 [RPC1][on_send_raw_tx]: Failed to process tx
I must have screwed up something Gonna live with dust forever. |
|
|
|
|
Shapeshift is disabled too. I guess just in case, until network calms down.
|
|
|
|
Minergate shows Network hashrate 27.01 MH/s, divided by two it gives hashrate 13.51 shown by my bitmonerod |
|
|
|
Dunno, I have Height: 1009843/1009843 (100.0%) on mainnet, mining at 150 H/s, net hash 13.51 MH/s, v2, up to date, 8+3 connections One node was blocked by daemon, for returning unknown top block, obviously it was not updated. So it works smoothly. Congrats to the devs! |
|
|
|
|
Post here if you find any solution for sweep_dust.
|
|
|
|
For example, I started there because of convenient and nice looking software and site. Migrated when I grew up |
|
|
|
They demand my passport and proof of residence even to be able to fund and trade there at all  |
|
|
|
|
Excuse me if I am asking stupid questions, but can I withdraw those USDT for real world USD?
|
|
|
|
There is enough 278.475450179850 xmr including unlocked dust 1.247663779850 I wonder why balance differs after two digits after comma where dust begins. I am not good at math [edit]: I am OK with that unusable dust, just hope everything works correctly. From IRC: <moneromooo> I think the <1e-2 part should be the same, yes. Maybe I'm missing a case. <moneromooo> The sweep_dust failure is likely because it's dust that's too small, that is it's less than amount needed to send itself. <moneromooo> Nothing can be done about those, except wait to see if fees go down later. <moneromooo> One *could* pair a large output with a tiny dust one, and send, but you'd lose the dust and more of the large output than the dust, so rather pointless. Thank you for your time. I'll just leave it as it is. It's a 'hot wallet' anyway. I just wanted to try this command sweep_dust and found this error interesting. |
|
|
|
|
Show Posts
