Hacker Newsnew | past | comments | ask | show | jobs | submit | greyface-'s commentslogin

Information wants to be free(d).

Any data center that is in the business of selling tokens rather than space, cooling, power, and connectivity is going to be in trouble eventually.

Of course there's a script; every bitcoin tx output has a script. These challenges use the standard P2PKH script, i.e.:

  scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
  scriptSig: <sig> <pubKey>
https://en.bitcoin.it/wiki/Script

Not every bitcoin tx output.

With taproot (P2TR), scripts are optional, and outputs can be based solely on Schnorr signatures.


P2TR outputs have a script that always starts with OP_1. That script may or may not commit to a tapscript.

You know what I mean, there's no clever on-chain reward script.

> taking away people's rights as [...] workers

I was recently reviewing a collective bargaining agreement (after being approached by a campaign to add my job category to an existing union at my employer), and was surprised to find that it forced arbitration for all employee disputes, with no opt out. It's not just employers that use binding arbitration to take away workers' rights.


It appears this commit actually introduced the bug the attacker exploited by adding additional flexibility for cache key confusion via scriptPubKey. https://twitter.com/mononautical/status/2096928595432374706

The mechanism reminds me of this classic AWS request signature forgery bug from 2008: https://news.ycombinator.com/item?id=401876


While moving the funds, the attackers left an OP_RETURN message with the text "we are whitehats. contact us on chain" https://mempool.space/tx/c103de95817b43f2df635ec6f35ff126ca2...


Further on-chain communications:

https://mempool.space/tx/91271efcbb5ab29abfc38ae635f0644e3ba... "Please contact security@blockstream.com"

https://mempool.space/tx/bd81219691eb1e22475c5985d847fa888c3... from Blockstream, unknown PGP message

https://mempool.space/tx/3a3eac4a26395b8c2563aaf1eb8b1b77798... from attackers, "sending most back to bc1qdlld6antmv4xug242ed83q7k4rqw50cwfns38szx4qu2f4jwaxxsuhwxxr, is that ok"

https://mempool.space/tx/8a444eed65c4584f138e08ee138f61490ef... from Blockstream, PGP-signed "Yes, thank you."

https://mempool.space/tx/83825b2135dd0abac12c9dfe17f29ab81b3... from attackers, "Please fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched. Then we will transfer the money back safely after confirming the fix. The detail is as follows (encrypted using https://blockstream.com/pgp.txt)." with unknown PGP-encrypted payload

As of writing, no response from Blockstream, and funds are still controlled by the attackers.


Adversaries don't always ask nicely. Sometimes they break in and silently take the data. These services centralize traffic flows and make it so that an adversary only needs to tap one or two circuits to get a full picture for all users of a service.


CIA is not stupid enough to break into a guarded data center in Switzerland or one of the less America friendly EU countries. They tell the NSA to look for security holes and spread narratives that only criminals use VPN hoping that a politician will notice and try to ban them, like what's happening in the UK.

Big tech services are less private than you think but almost every provider who cares about privacy is safer than you expect. Most of the people who work there are committed to their mission, and if they ever get a gag order someone will leak it in no time because they know exactly how to do it without exposing their identity.


Are you sure? Someone broke into a Hetzner data center and a Linode one, physically intercepted the Ethernet cables for jabber.ru, and got certificates signed on their behalf.

https://notes.valdikss.org.ru/jabber.ru-mitm/

https://news.ycombinator.com/item?id=37961166


dear sockpuppet =) I think the above commenter meant illegal physical access. The jabber.ru MitM situation was likely carried out by a cybercrime unit of the German police forces with a court order... and this is the adversary most people forget about.

Lesson to learn: Let's Encrypt does not protect against MitM by a state-level actor, unless you take precautions. *let's assume network admins won't MitM your server for personal vengeance reasons


> Lesson to learn: Let's Encrypt does not protect against MitM

But S in https stands for secure, or ? /s


Why would they serve a secret subpoena and gag order, when instead they can just drive to a secluded location 5km away from the super secure datacenter, dig a few meters down, passively tap a strand or two, facility and service operators none the wiser?


They’ve already done both. When they can get a cooperative party (AT&T, for example), they colocate their splitter equipment. When they can’t, they tap undersea and overland cables.

When it’s a hostile environment entirely, they hack and do secret operations and bribe.


The data would/should be encrypted; while the NSA did successfully tap Google's inter-datacenter traffic before the Snowden leaks, since then it is encrypted, too. Hopefully other providers won't fall for that trick anymore, either.


IIRC, Google addressed the incident you're referring to by adding E2E encryption to sensitive inter-DC RPC sessions, rather than by fully encrypting inter-DC traffic at the link level. It would be nice to be able to reasonably expect carrier/ISP backbones to be secure against this threat, but in our actual reality this seems like fantastical thinking.


> Google addressed the incident you're referring to by adding E2E encryption to sensitive inter-DC RPC sessions

And they don't provide the key to law enforcement because ... they care about your privacy. /s


> CIA is not stupid enough to break into a guarded data center in Switzerland

They don't need to break in guarded data centers. See Crypto AG

> or one of the less America friendly EU countries.

Besides Spain, there is no such country in EU. And even Spain might change its mind.


Sending every single query to a centralized third party is hard to square with "high privacy". I prefer to run my own local recursive resolver.


Please correct me if I am mistaken, but unless there’s a local resolver for every single one of your clients, aren’t the DNS requests sent in plaintext to the upstream of your local resolver?

That might not be an issue for your situation, but I recall the benefit of something like Quad9’s offering is the encryption between client and their endpoint(s), particularly for untrusted ISP or similar.


Yes, that's a real benefit in many situations. Everything on your lan can do normal DNS queries to your local forwarder, which talks DNS over TLS or DNS over HTTPS to Quad9.

Downside is Quad9 can see all your DNS traffic. But without it if you run your own recursive resolver your ISP sees all your queries, and many others see portions of them, unencrypted.


> But without it if you run your own recursive resolver your ISP sees all your queries, and many others see portions of them, unencrypted.

This hopefully shouldn't be an issue for long with stuff like RFC 9539 and OOTS/SVCB.


Courtesy link for HN readers

https://www.rfc-editor.org/info/rfc9539/


> I prefer to run my own local recursive resolver.

Used to be fine. I stopped doing it when average TTL dropped to 300 seconds and it takes far too long for my local recursor to get the answer >100ms, when 3rd party resolver delivers in <10ms.


You don't have to obey TTL. You can use Unbound options like:

    cache-min-ttl: 3600 // seconds
    cache-min-negative-ttl: 3600 // seconds
or

    serve-expired: yes
    serve-expired-client-timeout: 20 // milliseconds to wait for resolution before serving the old value to the client


Can also have unbound preemptively refresh cached values too...

    prefetch: yes
Tada, now your unbound serves records faster than the round trip out to anything off your own network in most cases.


It's still fine. I run my own recursive resolver and have no noticeable issues.


Good for you


> This isn’t how things are done these days

The old locality domains still exist, and in many localities you can still register them today by the same "email a request to some sysadmin" process. https://news.ycombinator.com/item?id=48122635

Your beach.santa-cruz.ca.us domain is still in DNS, just with a broken delegation chain. You could reclaim it right now by setting up a nameserver at reality.samiam.org.


I’m amazed beach.santa-cruz.ca.us is still around. I’ve given it some SSL certs and have reclaimed it:

https://beach.santa-cruz.ca.us/

Thanks for checking the zone files of the parent domain to verify it’s still there.


Wait what haha. Do you also own samiam.org?


Judging by his username (strenholme) and the contents of https://samiam.org/ (Sam Trenholme's webpage), he does indeed!


This one thinks LLMs should be trained and RLHF'd into illeists, as an experiment.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: