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...

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

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.

28 sats \ 1 replies \ @Lumor 19 Jan

"Linux backdoors" as in programs/services that can execute on Linux, not kernel backdoors.

I think kernel backdoors are then called rootkits?

313 sats \ 13 replies \ @000 19 Jan

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.

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.

1000 sats \ 0 replies \ @adam3us 21 Jan

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

lukedash has noone to blame but himself.

21 sats \ 6 replies \ @000 19 Jan

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.

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.

45 sats \ 2 replies \ @000 19 Jan

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.

According to this site: https://www.investopedia.com/terms/s/segwit-segregated-witness.asp

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.

So I looked further and found this article: https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality

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.

As I understand it, he was the dev that figured out how to signal and activate it on the network as a soft fork rather than hard fork. (Despite being actually opposed to using segwit.)

Haven’t got my copy of The Blocksize War to hand to double check so open to be corrected.

20 sats \ 0 replies \ @000 19 Jan

You are correct. I had to download a copy of that book from a sketchy website to verify it. Would have been ironic if I got my butt hole pushed in by not sand boxing it.

A Florida-based Bitcoin developer called Luke Dashjr had figured out a hack, which made SegWit possible as a compatible (softfork) Bitcoin upgrade. Luke was regarded as one of the most extreme small blockers and was another hate figure in the large block community, alongside Gregory Maxwell. Luke was not at all scared of standing out from the crowd with his non-consensus opinions. To some extent, the committed Catholic and father-of-seven was the Cassandra of the technical community; exceptionally strident. However, Luke clearly had a very strong technical understanding of Bitcoin, and his apparent non-linear thinking, which made him see things differently from others, may have helped him conceive of this hack that the other developers couldn’t quite work out.

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.

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

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.

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.

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.

3 sats \ 1 replies \ @pi 19 Jan

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.

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.

Am I the only one that thinks that this can be a boating accident?

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.

He also said his bitcoin in cold storarage was also atolen. How can this be?


It cannot, don't worry. His setup could not be called cold by any stretch of the imagination.

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.

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.

21 sats \ 0 replies \ @pony 20 Jan

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

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

e.g. https://www.linode.com/docs/guides/use-luks-for-full-disk-encryption/