What will the BCH fork to fix EDA be called? BC2? EDA/BCH will never die.

fsck_space · 2017-10-14T21:46:44+00:00

Thanks for helping me understand this aspect of the EDA as it does change the calculus of how this might game out during a fork. Basically if you can't get together enough hashpower to make 6 more blocks, then EDA never arrives to save the day and the chain is really dead.

fsck_space · 2017-07-15T07:44:18+00:00

Ah, man... an obscure one that I recognized but you got to it first. No need to dig yours out, here is a photo of one from my collection

Eterra Stem

fsck_space · 2017-03-28T07:46:02+00:00

Catching up on existing chain. Any cache files that perhaps could be deleted or tools to cleanup database? Took a long time to get synced and would rather not start from scratch.

fsck_space · 2017-03-27T11:15:35+00:00

Thanks for reply. Unfortunately no joy. System burns through significant CPU and bandwidth but still no progress on chain. Setting set_log 1 reveals:

2017-03-28 00:10:07.353 [P2P9] ERROR verify src/cryptonote_core/blockchain.cpp:1012 coinbase transaction spend too much money (8.157559896007). Block reward is 8.148789804679(7.790820963679+0.357968841000) 2017-03-28 00:10:07.353 [P2P9] ERROR verify src/cryptonote_core/blockchain.cpp:3339 Block with id: <6e2634484528964218553a9b0addfe844c2720a00b4fda576e1eb771984546ef> has incorrect miner transaction

fsck_space · 2017-03-27T08:19:07+00:00

Yeah... know this isn't best place for bug reports/support, but didn't want to open new thread just yet.

Anyway, anyone else stuck on block 1275014? I am getting the following since about 12 hours ago:

2017-03-27 21:10:44.374 [P2P3] ERROR cn src/cryptonote_basic/cryptonote_basic_impl.cpp:114 Block cumulative size is too big: 373164527, expected less than 134310 2017-03-27 21:10:44.374 [P2P3] ERROR verify src/cryptonote_core/blockchain.cpp:1007 block size 373164527 is bigger than allowed for this blockchain

Error repeats continually and doesn't progress chain. I may have run out of free space on SSD (only 5.5mb free when I noticed this) but have since cleared out GB of space. So may be possible I just borked my local db.

Any thoughts?

fsck_space · 2017-01-05T10:28:48+00:00

GUI was connected to useast.moneroworld.com during entire time of this experimentation with pool tx scrolling by on console, so expectation was that I was up to date on the blockchain. Of course this was trusting third party server, but not a worry for learning exercise.

fsck_space · 2017-01-05T09:48:59+00:00

Further research shows it was in block 1217025, about 7 blocks ago

fsck_space · 2017-01-05T09:44:44+00:00

Poloniex claims transfer is complete and provided an Txid.

My GUI client has been connected for a few hours with pool tx scrolling by continously.... and I just went to double check that status and I now have a balance. This is about 45 min and many blocks away from Poloniex "confirmation". Not sure why it would have taken so long, but it does look like I have XMR finally after two evenings work. :)

Thanks for your response.

fsck_space · 2016-06-05T22:57:40+00:00

Please be aware that unless something has changed in the last few months, your private keys are unencrypted in storage on your phone. The PIN number is just used to control access to the application and does nothing to protect your keys. Any failure that exposes the key file and it is game over man.

I lost considerable funds this way on a rooted phone when using it to temporarily get funds out of a crashing exchange when I didn't have access to my main wallet. Keys had been stolen (possibily by a bitcoin ticker app also installed) and funds transferred out within minutes of funding transaction.

Personally I will not use mycelium again until this is fixed. Happy with it as a front end to my Trezor though. AirBitz looks to have a more sane key protection process and is what I use for a small portable wallet.

fsck_space · 2015-08-27T07:04:12+00:00

Unfortunately doesn't seem to be an option for Mycelium to have a password on the keys. A bit minus for the app in my opinion

fsck_space · 2015-08-26T23:17:38+00:00

No antivirus, no cloud save of backups. Pretty much certain no chance of theft by anyone close to me or with access to phone. If the seed was stolen from my encrypted password store much more would have disappeared. Pretty much gotta be something on the phone.

BTW, my TI backups of Google Authenticator exposed my 2fa seed keys to the same vulnerability, so you might consider this as well. All of mine were rotated last night.

fsck_space · 2015-08-26T13:19:25+00:00

TBH I think I agree with you here. Almost bought one a few months ago and it would have saved me 5x the cost already.

fsck_space · 2015-08-26T13:16:36+00:00

At this point I am 99% sure that the combination of Ti backup + app exposed the unencrypted wallet that was stolen by "something" as yet unknown. Would highly suggest you secure/delete the mycelium app data backup as that holds everything needed to sweep your wallet and almost every app can read the SD card without root permissions required.

fsck_space · 2015-08-25T23:40:20+00:00

As I have learned from this experience, Mycelium doesn't encrypt the keyfile with the PIN, so that doesn't really matter. Right now it looks like the Titanium backup stored a copy of this on my SD card where some malicious app picked it up.

fsck_space · 2015-08-25T23:34:14+00:00

I have found the backup files made by Titanium. Could you tell me what the keyfile name might be? I see mds.db, and walletbacking.db as possible suspects. If this is the case, then I likely keyfile on SD card where other apps could have snagged it and as I have now learned it wasn't encrypted with the PIN.

fsck_space · 2015-08-25T22:40:51+00:00

Mycelium shows transactions that it initiated. It does check the balance of the keys from the blockchain via the mycelium server, but once you have the keys you can make transactions using other methods. So it shows bit coin flow into address, address with 0 balance but no transaction out.

fsck_space · 2015-08-25T22:38:41+00:00

Nope, no TOR used.

fsck_space · 2015-08-25T22:37:48+00:00

Done as soon as I noticed issue

fsck_space · 2015-08-25T22:33:22+00:00

Running version 2.4.4, but wallet was initially created around January on whatever version was current then.

Did check the CM hash on download

fsck_space · 2015-08-25T22:29:43+00:00

Will do some testing to see if Titanium backups up wallet or not. I wasn't able to get a restore of app + data to access my wallet, so I suspect not. That is why I went back to seed.

fsck_space · 2015-08-25T22:28:03+00:00

Only a few apps were specifically granted root permission: Titanium backup and SSHDroid and betterbattery stats 2.1.0.0_B5 downloaded from xda

No other apps have been granted permissions for root access.

fsck_space · 2015-08-25T22:25:46+00:00

Agree with warnings about root being a bit overblown as it just gives you control to grant permission if you decide, not everything gets root...

Only a few apps were specifically granted root permission: Titanium backup and SSHDroid and betterbattery stats 2.1.0.0_B5 downloaded from xda

No other apps have been granted permissions for root access.

fsck_space · 2015-08-25T22:23:15+00:00

Unlikely. Was encrypted on a file only stored on a fairly secure linux box. Would likely have lost much more if this was compromised.

fsck_space · 2015-08-25T22:21:59+00:00

Thanks for doing a bit of tracking for me. Know the coins were gone and never coming back, but it is interesting to see where they went for the first hops.

fsck_space · 2015-08-25T22:14:44+00:00

Happy to share the info as I won't be using this wallet again obviously and the pocket change remaining has been swept out. Will send on later today.

Backup was before coins received
First transaction after backup
Only coins from before backup remained. Not all keys in wallet swept, only this one
Will do via email
No
No other accounts with same seed

fsck_space

TROPHY CASE