pull down to refresh

He just seen very stingy with his money and didn't wanted to have a proper provider for his setup on DC. Someone saw that weak spot and take the oportunity. Then you can discuss about it soft setup but it doesn't seem that bad for dev...
reply
Suddenly everyone is an experienced sysadmin and Bitcoin expert...
Luke knows his stuff, and I'm sure if he was basically not known by the public his 200 BTC would still be there.
This was a specific attack against him. Yeah, his setup wasn't perfect, but it was by no means extremely sloppy:
the attack was originating from direct physical access to his server
reply
What evidence is there that someone with physical access to the server rebooted it?
There are many fewer people with physical access to that machine than remote access.
reply
"Linux backdoors" as in programs/services that can execute on Linux, not kernel backdoors.
reply
I think kernel backdoors are then called rootkits?
reply
I have some questions. This article documents how a server got infected that was hosted in a facility. This is literally the worst thing you can do as a Bitcoiner for custody short of tattooing your seed phrase on your arm.
Why did Luke have that much Bitcoin sitting on a server?
Couldn't moving all his legacy BTC to a hardware wallet solve his problem with some of the old coin being on private keys that existed before some BIPS? It feels like he just completely neglected to maintain this through the years. Why?
This also feels like a case of excessively complicated security practices. How does he create such a complicated security model to address threats for himself and completely skip the fundamentals?
I just don't understand. I don't think it is a psyop or anything. I genuinely believe this guy has no business being a Bitcoin core developer. Completely bizarre. I don't think this is a matter of oversight. I think this is a matter of this guy put way too much faith in whatever he put his faith in. Was he trying to prove something???
I don't understand.
reply
Has it been confirmed that the bitcoin was on his server or are you making that assumption?
believe this guy has no business being a Bitcoin core developer
Well glad you're not a gatekeeper or core dev yourself then. Be a dev or help out in the codebase, that's literally the only requirement to participate. You're gate keeping like someone needs to be perfect to contribute. Newsflash, anyone can be hacked.
reply
Has it been confirmed that the bitcoin was on his server or are you making that assumption?
no he did not have his bitcoin on this hosted server. this was nov 2022 hack, and only (speculative) possibly related if they managed to "hack-back" to his home systems to get behind his router and firewall and stay undetected for a month or so
reply
lukedash has noone to blame but himself.
reply
I agree. I hate that for him, I cannot rationalize this any other way. Anyone can be a core dev. I get that. But I also believe that if you decide to take that path, you should understand you no longer represent yourself. You represent Bitcoin.
So if someone who represents Bitcoin in such a privileged capacity cannot be bothered to think rationally about their OPSEC then they should distance themselves from the public view as much as possible and do something else. This is not the path for them.
I do hope to see more Bitcoiners call for Luke to step down as a core dev, if he has not already. What example are you setting for your fellow Bitcoiners, who you have volunteered to be a figurehead in some capacity for? That is part of the territory, like it or not.
reply
Honestly, I just see this as the flip side of Luke’s incredibly lateral mind.
The same brain that figured out segwit is also going to be one that tries unconventional security methods.
His skill is still extremely valuable to bitcoin.
reply
This is not true. I don't know too much about Luke because I don't keep up with things to that level of detail with Bitcoin. So I looked this up.

SegWit was formulated by Bitcoin developer Pieter Wuille. Wuille is also the co-founder of Blockstream, a software company specializing in digital security for financial services.

Luke had discussed some of the issues before segwit came along that segwit would eventually solve and appears to have gotten involved again after Pieter kicked the discussion up and came up with a proposal. The most contribution Luke appears to have is that he suggested segwit be a soft fork.

The Intolerant Minority
While the BIP148 UASF seemed to have lost a lot of steam in favor of BIP149, not everyone had given up on this first UASF proposal completely.
Shaolinfry had proposed the concept under the assumption that it would be backed by an economic majority and thought it should be aborted before the flag day otherwise. But a group of users on the UASF Slack channel had a different idea. Some of them — including Bitcoin Core and Bitcoin Knots developer Luke Dashjr — were contemplating activating the soft fork regardless of what the rest of the Bitcoin ecosystem would do. Even if they were a minority, and even if they’d effectively spin themselves off into a new altcoin, they would move forward with the upgrade.

I attempted to find any mention that would explain why you are attributing him with such regard, but I cannot find anything that aligns. There is no "lateral mind" at play here.
Valuable skillet is debatable at best in my opinion, but even if that is the case his skillet is not rare.
figured out segwit may be a stretch, i know he was a part of it, but FIGURED OUT i think is strong wording.
he was vital in the segwit process and working it out so it could be softfork rather than hardfork but there were others he was collaborating with.
reply
He figured out segwit in the sense that it didn't need to be a hardfork. In a nutshell the signatures that used to be stored within a block (and count towards the 1 megabyte limit) are now stored "outside" the block so that old nodes simply ignore the signature part of segwit transactions.
One consequence is that pre-segwit nodes consider segwit transaction outputs as "can be spent by anyone" because they don't require a signature.
As long as most people use post segwit nodes, this is no problem of course, but it's funny at least that in theory anyone can create valid transactions to spend literally any and every single segwit UTXO
reply
There was the November attack on his server at his hosting facility. That's what the article is describing.
Then there was the December 31st/Jan 1st discovery that funds had just moved. These two events are likely related, but the funds stolen were not kept on that exploited server.
It is still unclear how the attackers jumped from Luke server [at hosting facility], to Luke Workstation [at his home] (or vice versa).
Luke confirmed that his Workstation [at his home] was likely compromised,
This article only addresses the server compromise, not how the funds kept on his workstation/device(s) [at his home] were accessed.
reply
More likely that these coins had been there since they were worth 100 USD. Luke has been a Bitcoin dev since 2011 if I'm not mistaken.
Also, being a good developer says nothing about being responsible about storing your wealth.
reply
Why did Luke have that much Bitcoin sitting on a server? he did not have his bitcoin on the server this hack happened a month before his bitcoins were stolen off home systems. it's possibly related if the hackers were somehow able to "hack-back" to his home systems and keep the compromised undetected a month or two. but that's speculation only so far.
reply
So, Luke was hodling 200 BTC on a remote server hosted by a third party, in a wallet secured by a single key? Is that correct?
Sincerely sorry for his loss, though.
reply
no this was a november 2022 hosted server back. his bitcoins were not on that server. it's (speculative) possibly related if they found a way to "hack-back" to his home systems to get inside his router and firewall.
reply
Am I the only one that thinks that this can be a boating accident?
reply
I was thinking the same thing. I mean are people not even using LUKS encryption?
If it is not a yachting related accident I'm very sorry for his loss.
reply
This reminded me of what Saifedean Ammous said in his book "The Bitcoin Standard", regarding bitcoin security. Anyway, the good thing is that it has nothing to do with the kernel.
reply
He also said his bitcoin in cold storarage was also atolen. How can this be?
reply
It cannot, don't worry. His setup could not be called cold by any stretch of the imagination.
reply
as the attacker can mount the file system and copy any file to any location when booting from external media.
Another mega fail: not using an encrypted file system on his server.
reply
The problem with Full Disk Encryption (FDE) on remote managed servers is that FDE significantly lengthens server outages. Every scheduled outage by the facility now requires your input to bring up your server.
This is especially problematic if your hosting facility does not provide remote admin tools like Dell iDRAC or HP iLO.
So effectively for every scheduled and non-scheduled outage your server experiences you would need to drive over to the remote facility to input your FHD password. That is an annoyance most would rather live without.
tl;dr FDE is great for mobile devices and VMs in public cloud, but a pita for physical servers in remote colo. Remember: There is no perfect security. There are only tradeoffs.
reply
He possesses the technical acumen to create a boot partition that remains unencumbered by encryption, while concurrently crafting another partition that is safeguarded by cryptographic means, which can then be accessed through the utilization of the cryptsetup utility
reply
Most providers have some sort of KVM you can use without needing to drive over there.
Granted - I don't know what Luke was running on this "server", but it sounds like it was an old school single machine setup and not some ephemeral k8s cluster or anything, so IMO I'd still like to know why he wasn't using FDE. Perhaps his hosting company doesn't have FDE, but that's a good reason not to use them IMO
reply
deleted by author
reply