Would be kind of overkill to create a full lightning implementation just for testing :-)
|
|
|
Yes, `addfunds` was recently removed and we now rely on tracking the blockchain to tell us about incoming funds.
|
|
|
Lucky I was pointed here by someone who saw your message, I only occasionally check bitcointalk. Bug reports and help should go to the github, mailing list or IRC channel, to ensure we see them :-) Thanks for confirming that the patch worked ^^ Are you trying to connect the daemon to itself? Not sure why you'd do that, and pretty sure we close self-connections, try connecting to some other node on the network ( https://explorer.acinq.co/ for (id, ip, port)-tuples)
|
|
|
Hey mocacinno, thanks for giving c-lightning a shot. The value mismatch is actually important, no one has ever tried to give that many funds to a lightning wallet so far, and indeed you stumbled over a bug when reading back the funds from the DB. It is fixed in a PR and should be merged soon, at which point the true value of the output will show up :-)
As for the disconnection I don't really know. Are you trying to connect to yourself? `connect <myid> <myip> 9735` seems to suggest that.
|
|
|
We just published some results about the use transaction malleability in the Bitcoin network with a special focus on MtGox: The transaction malleability problem is real and should be considered when implementing Bitcoin clients.
However, while MtGox claimed to have lost 850,000 bitcoins due to malleability attacks, we merely observed a total of 302,000 bitcoins ever being involved in malleability attacks. Of these, only 1,811 bitcoins were in attacks before MtGox stopped users from withdrawing bitcoins. Even more, 78.64% of these attacks were ineffective. As such, barely 386 bitcoins could have been stolen using malleability attacks from MtGox or from other businesses. Even if all of these attacks were targeted against MtGox, MtGox needs to explain the whereabouts of 849,600 bitcoins. The complete results are here: http://bit.ly/1rCqKED
|
|
|
Single theft, two claims because 2 transactions were made. By the way the two lists of victim and thief should somehow be separated, as there can be multiple on either side. 2012-09-28 8,872 https://bitcointalk.org/index.php?topic=113775.0 1PwikEnt89thgsMVydpG9uAT1QKyoBLMjZ
1JLqF8kZ2w1Pv4ThX9YpxP3kvFsTyrxwXM 1U1jTCGkQYRaDVStZdDHMFWUMoSJi4HSc 1MQKhQhiRcJfv1X2G7ywgX1oWdVocqvQEw 1PHQKAGYKxDRxdpPL6fWNUwWQxEHGA5oxS
2012-09-28 350 https://bitcointalk.org/index.php?topic=113775.0 1PHQKAGYKxDRxdpPL6fWNUwWQxEHGA5oxS 1Q2YUKhDNGzFxtqLUGjozgcc1ALpfSer6i
1U1jTCGkQYRaDVStZdDHMFWUMoSJi4HSc
|
|
|
Yup, MtGox is managed bby Tibanne Co. Ltd.
|
|
|
r4gCHB6hEggLdGpsoB9oSWstPmALMgAv1X
|
|
|
I would still like to know if its possible, how the original theft of the OP took place exactly so that I can make sure that it doesn't happen. Looks like the ssh login occured on a non-standard port so the OP's PC must have been scanned. If that is the case, then the OP must have had a public facing computer with no firewall between him and the internet? Assuming the attacker located the correct ssh port, then in order to login either
attacker had private key to authenticate with ssh server on OP's pc or OP had a weak password that was brute-forced
The the OP says the attacker nicked his private key and then logged onto his work computer. htf did the attacker know to look on his work computer? I think that the OP's security environment must have been totally compromised somehow. Maybe something he said on an IRC channel perhaps? I worry that this can happen to anybody if some joe hacker decides he wants some bitcoin, he just breaks into some poor sod's non-standard ssh port and then navigates his way to his work pc in a space of a few minutes. what gives?
Still trying to figure that one out myself, will have more in a couple of days I guess.
|
|
|
Yup, just here to clean up misunderstandings: we are not mining, we are just doing some research on the network itself.
The reason we show up so often is that in order to do our measurements we are highly connected, and while we're at it we facilitate the information flow on the network by relaying information.
|
|
|
Did I miss a rant about my person? @vuce: yes, those semester-theses are just for ETH Students, but I see more and more Universities picking up the Topic and maybe your in luck and yours is open to new ideas. More theses will be made available, and I'm always open for new ideas.
|
|
|
Thanks mate, will add this to my gathered data for the police :-) He has since then disappeared (reconnect?)
|
|
|
Thanks caffeinewriter, any help is appreciated. I will file a report on Monday, and see what they say.
As for the cleaning up I think I'm OK. Just running clamscan over all the files, rkhunter had nothing to complain, but I don't know whether an eventual rootkit wouldn't be smart enough to fool them, any experience about that?
|
|
|
That ssh log message indicates they accessed using your public key. How on earth did they get that? Did you access from some other systems that they may have also got access to? This is pretty common. This means you need to check all other computers that previously you used to connect to your laptop. A public key is not more safe than a password if it's left laying around on various systems.
People often use a key for automated access (scripts etc). If you do that it should be for a different, limited user that can only do the very limited functions you intent to automate.
I don't understand it either, apparently they got first into my home machine (with password auth enabled), grabbed the private key for my work machine and logged in there. No idea as to how.
|
|
|
Well I'm not a security researcher, I'm researching Distributed Computing. And yes the errors were stupid.
|
|
|
Still reconstructing everything that happened, but it seems that broadband-178-140-220-181.nationalcablenetworks.ru [178.140.220.181] was able to log into my machine: Sep 28 20:45:36 nb-10391 sshd[19170]: reverse mapping checking getaddrinfo for broadband-178-140-220-181.nationalcablenetworks.ru [178.140.220.181] failed - POSSIBLE BREAK-IN ATTEMPT! Sep 28 20:45:37 nb-10391 sshd[19170]: Accepted publickey for cdecker from 178.140.220.181 port 28384 ssh2 Sep 28 20:45:37 nb-10391 sshd[19173]: subsystem request for sftp by user cdecker Same happened a few minutes later on my machine at home (my bash history must have told him were to find it), and from there he must have been able to find my wallet backup (which is really old, but was kept unencrypted, so any key that was in there is compromised). I'll write everything down and file a report, we'll see how open to technology the swiss police are
|
|
|
Few days ago I have seen someone complaining about snoopy constantly contacting him while not answering any requests. Good to know what it is and who's running it. Good luck in your research.
Could you show me the post, if it's a problem on my side I'll fix it.
|
|
|
Nevermind the other Thread, as I already explained it's part of my research, I myself am 82.130.102.160, and yes we developed BitThief, so that's not it.
I think showing up on blockchain.info actually put a huge target on my back. I see a few connection to my notebook from Russian domains and the big surprise: they are able to log in... They must have somehow gotten my password or
[...few minutes later ...]
sorry had to kill the network connection, whoever it was they were still logged in on my machine...
|
|
|
Can you at least tell us if you found any significant flaws in the system? There are no new flaws from my side, as a researcher it is my ethical duty to inform the developers of anything that I find. Otherwise I'd be unable to publish my research results
|
|
|
|