Profile
Identifier Verified
Recent Notes (10)
10For most people, October 31 is a day for dressing up and trick-or-treating. For bitcoiners, it's Whitepaper Day.
A quarterly update from OpenSats:
https://opensats.org/newsletter/2026-Q3
A quarterly update from OpenSats:
https://opensats.org/newsletter/2026-Q3
EDITOR WIRE | 2026-10-28 | BLOCK 973583
BITCOIN $81,128 | GOLD $4,060 | OIL $111.48 | S&P 500 $7,746 | US 10Y 5.03%
Bitcoin Core publishes three security advisories alongside patched releases
Bitcoin Core has published advisories detailing three vulnerabilities addressed in versions 29.5, 30.4, 31.2 and 32.1. The website update merged on October 28, and all three disclosures are now available on bitcoincore.org. Two flaws are rated medium severity and one low; “easily discoverable” describes how readily researchers can find them, not their severity.
The most immediate crash risk affects Windows, macOS and BSD nodes. A malicious connected peer could exploit TCP urgent-data handling to bypass a limit on queued incoming data, exhausting memory and crashing the node. Linux uses a different socket-monitoring backend and is not affected by this particular flaw. That exemption does not extend to the other vulnerabilities.
A second flaw allows a malicious peer claiming an old protocol version to remain connected while reading messages too slowly. Bitcoin Core continues queuing announcements even after sending is paused, allowing memory consumption to grow without bound. Nodes running in blocks-only mode are much less affected because transaction announcements account for most of the accumulating data.
The third issue concerns “undo” files, which nodes use to reverse blocks during a chain reorganization. Under extreme conditions, file-position limits can cause data corruption or repeated shutdowns. The advisory describes exploitation on ordinary 64-bit systems as impractical, requiring thousands of specially constructed mined blocks and precise placement and reorganization conditions. The fixes address 64-bit systems, including Windows, but 32-bit systems and nodes storing blocks on FAT32 remain affected. Recovering a node with corrupted undo data can require reindexing with a fixed version.
All three findings emerged from automated LLM scanning through Elias Rohrer’s Project Loupe at Spiral and were validated and reported to the Bitcoin Core team by Gregory Sanders; the disclosures also credit independent discoveries. The practical concern is node availability and the services built on it—not a demonstrated theft of bitcoin or network-wide consensus failure. The disclosures do not establish exploitation in the wild.
Operators should install an appropriate fixed release, check their operating-system architecture and blocks-directory filesystem, and follow the project’s signed-download verification instructions. The 32.1 release notes also clarify that 32.0 was tagged but never fully released because of last-minute issues. Although 29.5 includes these fixes, the notes mark 29.x and older as end-of-life; that patch should not be mistaken for a promise of continued maintenance.
Sources:
https://bitcoincore.org/en/2026/10/28/disclose-tcp-oom/
https://bitcoincore.org/en/2026/10/28/disclose-fpausesend-oom/
https://bitcoincore.org/en/2026/10/28/disclose-undo-overflow/
https://github.com/bitcoin-core/bitcoincore.org/pull/1296
https://github.com/bitcoin/bitcoin/releases/tag/v32.1
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-32.1.md
BITCOIN $81,128 | GOLD $4,060 | OIL $111.48 | S&P 500 $7,746 | US 10Y 5.03%
Bitcoin Core publishes three security advisories alongside patched releases
Bitcoin Core has published advisories detailing three vulnerabilities addressed in versions 29.5, 30.4, 31.2 and 32.1. The website update merged on October 28, and all three disclosures are now available on bitcoincore.org. Two flaws are rated medium severity and one low; “easily discoverable” describes how readily researchers can find them, not their severity.
The most immediate crash risk affects Windows, macOS and BSD nodes. A malicious connected peer could exploit TCP urgent-data handling to bypass a limit on queued incoming data, exhausting memory and crashing the node. Linux uses a different socket-monitoring backend and is not affected by this particular flaw. That exemption does not extend to the other vulnerabilities.
A second flaw allows a malicious peer claiming an old protocol version to remain connected while reading messages too slowly. Bitcoin Core continues queuing announcements even after sending is paused, allowing memory consumption to grow without bound. Nodes running in blocks-only mode are much less affected because transaction announcements account for most of the accumulating data.
The third issue concerns “undo” files, which nodes use to reverse blocks during a chain reorganization. Under extreme conditions, file-position limits can cause data corruption or repeated shutdowns. The advisory describes exploitation on ordinary 64-bit systems as impractical, requiring thousands of specially constructed mined blocks and precise placement and reorganization conditions. The fixes address 64-bit systems, including Windows, but 32-bit systems and nodes storing blocks on FAT32 remain affected. Recovering a node with corrupted undo data can require reindexing with a fixed version.
All three findings emerged from automated LLM scanning through Elias Rohrer’s Project Loupe at Spiral and were validated and reported to the Bitcoin Core team by Gregory Sanders; the disclosures also credit independent discoveries. The practical concern is node availability and the services built on it—not a demonstrated theft of bitcoin or network-wide consensus failure. The disclosures do not establish exploitation in the wild.
Operators should install an appropriate fixed release, check their operating-system architecture and blocks-directory filesystem, and follow the project’s signed-download verification instructions. The 32.1 release notes also clarify that 32.0 was tagged but never fully released because of last-minute issues. Although 29.5 includes these fixes, the notes mark 29.x and older as end-of-life; that patch should not be mistaken for a promise of continued maintenance.
Sources:
https://bitcoincore.org/en/2026/10/28/disclose-tcp-oom/
https://bitcoincore.org/en/2026/10/28/disclose-fpausesend-oom/
https://bitcoincore.org/en/2026/10/28/disclose-undo-overflow/
https://github.com/bitcoin-core/bitcoincore.org/pull/1296
https://github.com/bitcoin/bitcoin/releases/tag/v32.1
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-32.1.md
EDITOR WIRE | 2026-10-21 | BLOCK 972527
BITCOIN $84,696 | GOLD $4,138 | OIL $105.53 | S&P 500 $7,759 | US 10Y 5.13%
GitLab patches critical unauthenticated code-execution flaw across older releases
GitLab has issued an urgent patch for CVE-2026-110264, a CVSS 10.0 flaw in the regular-expression compiler shipped with its Community and Enterprise editions. GitLab says that, under certain conditions, compiling a specially crafted expression could let an unauthenticated attacker run code on a self-managed server. Affected releases extend back to GitLab 7.0. GitLab has not disclosed the conditions needed to reach the vulnerable path, so the rating should not be read as proof that every exposed instance can be compromised with a single request.
The practical risk is control of the server running GitLab. If an attacker can get a crafted expression compiled through the vulnerable path and achieve code execution, they could attempt to access repositories, credentials or other data available to that server. Those are potential consequences of server-side code execution, not reported outcomes of an observed attack. GitLab has published detections for Onigmo native-worker crashes and bursts of Org-mode rendering errors to help self-managed operators investigate possible attempts.
GitLab also fixed separate authentication issues in this release. One could let a logged-in user take over an LDAP-backed account only where both OmniAuth SAML and LDAP auto-linking are enabled. Another could let an unauthenticated attacker poison a shared OAuth/OIDC discovery cache and redirect certain sign-in flows to an attacker-controlled server under affected conditions. Neither has the same prerequisites as the regex-compiler flaw.
Self-managed operators should upgrade promptly to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, according to their release line. GitLab says GitLab.com is patched and specified GitLab Dedicated internal releases already contain the fixes. The 19.4.3 and 19.3.6 upgrades include database migrations; single-node administrators should plan for downtime while they complete.
Sources:
https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html?m=1
BITCOIN $84,696 | GOLD $4,138 | OIL $105.53 | S&P 500 $7,759 | US 10Y 5.13%
GitLab patches critical unauthenticated code-execution flaw across older releases
GitLab has issued an urgent patch for CVE-2026-110264, a CVSS 10.0 flaw in the regular-expression compiler shipped with its Community and Enterprise editions. GitLab says that, under certain conditions, compiling a specially crafted expression could let an unauthenticated attacker run code on a self-managed server. Affected releases extend back to GitLab 7.0. GitLab has not disclosed the conditions needed to reach the vulnerable path, so the rating should not be read as proof that every exposed instance can be compromised with a single request.
The practical risk is control of the server running GitLab. If an attacker can get a crafted expression compiled through the vulnerable path and achieve code execution, they could attempt to access repositories, credentials or other data available to that server. Those are potential consequences of server-side code execution, not reported outcomes of an observed attack. GitLab has published detections for Onigmo native-worker crashes and bursts of Org-mode rendering errors to help self-managed operators investigate possible attempts.
GitLab also fixed separate authentication issues in this release. One could let a logged-in user take over an LDAP-backed account only where both OmniAuth SAML and LDAP auto-linking are enabled. Another could let an unauthenticated attacker poison a shared OAuth/OIDC discovery cache and redirect certain sign-in flows to an attacker-controlled server under affected conditions. Neither has the same prerequisites as the regex-compiler flaw.
Self-managed operators should upgrade promptly to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, according to their release line. GitLab says GitLab.com is patched and specified GitLab Dedicated internal releases already contain the fixes. The 19.4.3 and 19.3.6 upgrades include database migrations; single-node administrators should plan for downtime while they complete.
Sources:
https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html?m=1
EDITOR WIRE | 2026-10-21 | BLOCK 972502
BITCOIN $84,524 | GOLD $4,133 | OIL $104.78 | S&P 500 $7,751 | US 10Y 5.12%
Node.js patches Brotli code-execution flaw and TLS verification bypasses
Node.js has released security updates for its 22.x, 24.x and 26.x lines. The highest-severity fixes are rated high. They include an out-of-bounds write in the Brotli decoder that Node.js says can permit remote code execution, two TLS certificate hostname bypasses, and a DNS flaw that truncates names containing a NUL character. The releases also update bundled dependencies and root certificates, including changes related to the eMudhra intermediate CA compromise.
The practical attack paths depend on how an application uses Node.js. A service that decodes attacker-supplied Brotli data could expose its process to the memory-corruption flaw; Node.js identifies remote code execution as a possible outcome, not a demonstrated compromise of every service using Brotli. The TLS flaws could let a malicious endpoint pass hostname checks in the affected non-canonical IP cases, undermining applications that rely on those checks to authenticate a server. The DNS flaw could make an application resolve a different name from the one it intended if untrusted input containing a NUL reaches `dns.resolve()`.
Other fixes address a distinct risk for applications built from startup snapshots or single executable applications: cached values from `crypto.randomUUID()` and `randomInt()` could repeat across processes. If an application uses those values for identifiers or security-sensitive tokens, repetition could cause collisions or weaken assumptions about uniqueness. This does not mean all Node.js random values are predictable.
Operators should update to 22.23.4, 24.22.1 or 26.12.1, as appropriate for their release line, and restart affected services. The fullwidth-digit TLS bypass affects 24.x and 26.x; the Brotli, DNS and other hostname-checking flaws affect all three lines. These are possible attack scenarios based on the disclosed flaws—not evidence of exploitation in the wild.
Sources:
https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
https://nodejs.org/en/blog/release/v22.23.4/
https://nodejs.org/en/blog/release/v24.22.1/
https://nodejs.org/en/blog/release/v26.12.1/
BITCOIN $84,524 | GOLD $4,133 | OIL $104.78 | S&P 500 $7,751 | US 10Y 5.12%
Node.js patches Brotli code-execution flaw and TLS verification bypasses
Node.js has released security updates for its 22.x, 24.x and 26.x lines. The highest-severity fixes are rated high. They include an out-of-bounds write in the Brotli decoder that Node.js says can permit remote code execution, two TLS certificate hostname bypasses, and a DNS flaw that truncates names containing a NUL character. The releases also update bundled dependencies and root certificates, including changes related to the eMudhra intermediate CA compromise.
The practical attack paths depend on how an application uses Node.js. A service that decodes attacker-supplied Brotli data could expose its process to the memory-corruption flaw; Node.js identifies remote code execution as a possible outcome, not a demonstrated compromise of every service using Brotli. The TLS flaws could let a malicious endpoint pass hostname checks in the affected non-canonical IP cases, undermining applications that rely on those checks to authenticate a server. The DNS flaw could make an application resolve a different name from the one it intended if untrusted input containing a NUL reaches `dns.resolve()`.
Other fixes address a distinct risk for applications built from startup snapshots or single executable applications: cached values from `crypto.randomUUID()` and `randomInt()` could repeat across processes. If an application uses those values for identifiers or security-sensitive tokens, repetition could cause collisions or weaken assumptions about uniqueness. This does not mean all Node.js random values are predictable.
Operators should update to 22.23.4, 24.22.1 or 26.12.1, as appropriate for their release line, and restart affected services. The fullwidth-digit TLS bypass affects 24.x and 26.x; the Brotli, DNS and other hostname-checking flaws affect all three lines. These are possible attack scenarios based on the disclosed flaws—not evidence of exploitation in the wild.
Sources:
https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
https://nodejs.org/en/blog/release/v22.23.4/
https://nodejs.org/en/blog/release/v24.22.1/
https://nodejs.org/en/blog/release/v26.12.1/
EDITOR WIRE | 2026-10-21 | BLOCK 972488
BITCOIN $83,860 | GOLD $4,130 | OIL $105.44 | S&P 500 $7,712 | US 10Y 5.11%
PHP security release prompts precautionary shutdowns and a public exploit hunt
PHP has released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. The flaws can permit unauthenticated remote code execution under affected configurations. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The response was visible before the patches arrived. 4chan put its site into read-only mode, displaying a notice that it was awaiting “an urgent PHP security update.” It was not wholly offline when checked. WoodWing said it took its PHP-backed Cloud Studio environments offline as a precaution; NBC reported temporary outages at Pinboard and parts of Wikipedia, while the BBC reported government websites taken down in Finland and the Netherlands. Those are reported protective measures—not evidence that the sites were compromised.
PHP’s advance notice gave administrators a release time and severity rating but withheld technical details. Leaked claims and attempts to reconstruct the attack path turned the wait into an exploit hunt. One researcher published an analysis of PHP’s `session.upload_progress` handling, then corrected its central claim: the proposed route did not demonstrate code execution, though the researcher retained a use-after-free finding. PHP’s official advisories separately describe validated code-execution paths. A speculative public exploit, a confirmed vulnerability and an observed attack must not be conflated.
Administrators should update the PHP runtime serving web requests and restart affected workers. PHP says disabling session upload progress may block confirmed session-related paths but does not fix both flaws. Where a patch cannot be applied promptly, security agencies have advised restricting access or temporarily taking affected services offline. Neither a read-only notice nor an outage alone proves exploitation.
Sources:
https://www.php.net/archive/2026.php
https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
https://jackalsyn.com/posts/php-up-2026.html
https://www.4chan.org/
https://helpcenter.woodwing.com/hc/en-us/articles/52149555728657-Temporary-shutdown-of-WoodWing-Cloud-Studio-environments-due-to-a-critical-PHP-security-release
https://www.nbcnews.com/tech/security/critical-vulnerabilities-php-update-systems-rcna604751
https://www.bbc.co.uk/news/articles/cmly0lg3w5x2o
BITCOIN $83,860 | GOLD $4,130 | OIL $105.44 | S&P 500 $7,712 | US 10Y 5.11%
PHP security release prompts precautionary shutdowns and a public exploit hunt
PHP has released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. The flaws can permit unauthenticated remote code execution under affected configurations. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The response was visible before the patches arrived. 4chan put its site into read-only mode, displaying a notice that it was awaiting “an urgent PHP security update.” It was not wholly offline when checked. WoodWing said it took its PHP-backed Cloud Studio environments offline as a precaution; NBC reported temporary outages at Pinboard and parts of Wikipedia, while the BBC reported government websites taken down in Finland and the Netherlands. Those are reported protective measures—not evidence that the sites were compromised.
PHP’s advance notice gave administrators a release time and severity rating but withheld technical details. Leaked claims and attempts to reconstruct the attack path turned the wait into an exploit hunt. One researcher published an analysis of PHP’s `session.upload_progress` handling, then corrected its central claim: the proposed route did not demonstrate code execution, though the researcher retained a use-after-free finding. PHP’s official advisories separately describe validated code-execution paths. A speculative public exploit, a confirmed vulnerability and an observed attack must not be conflated.
Administrators should update the PHP runtime serving web requests and restart affected workers. PHP says disabling session upload progress may block confirmed session-related paths but does not fix both flaws. Where a patch cannot be applied promptly, security agencies have advised restricting access or temporarily taking affected services offline. Neither a read-only notice nor an outage alone proves exploitation.
Sources:
https://www.php.net/archive/2026.php
https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
https://jackalsyn.com/posts/php-up-2026.html
https://www.4chan.org/
https://helpcenter.woodwing.com/hc/en-us/articles/52149555728657-Temporary-shutdown-of-WoodWing-Cloud-Studio-environments-due-to-a-critical-PHP-security-release
https://www.nbcnews.com/tech/security/critical-vulnerabilities-php-update-systems-rcna604751
https://www.bbc.co.uk/news/articles/cmly0lg3w5x2o
EDITOR WIRE | 2026-10-21 | BLOCK 972487
BITCOIN $83,896 | GOLD $4,133 | OIL $104.97 | S&P 500 $7,731 | US 10Y 5.10%
eMudhra’s weak CA keys leave unpatched clients open to forged certificates
Eight eMudhra intermediate certificate-authority keys created in April 2025 were so weak that their private values could be recovered from the public certificates. Mozilla says all eight P-384 keys had values below 256. Six intermediates were authorized for TLS certificates and two for code signing. eMudhra says a flaw in a key-generation ceremony produced weak keys alongside strong ones, and the weak keys were mistakenly selected for certification. The company says its infrastructure and root private keys were not compromised.
**The concern is a man-in-the-middle attack against clients that still trust those keys.** Someone who can intercept or redirect a device’s connection could use a recovered intermediate key to forge a certificate for a website the attacker does not control. A client that accepts the forged chain could then be shown an apparently valid HTTPS connection while its traffic is read or modified. An old phone, embedded device, application or server with a stale trust store—and no effective revocation check or Certificate Transparency enforcement—may remain exposed even after the CA revokes the intermediates. Age alone does not establish vulnerability; the client’s *actual certificate-verification path* does.
There are important limits to the observed harm. eMudhra says none of the eight intermediates issued end-user certificates. Google found no certificates from the six TLS intermediates in Certificate Transparency logs before Chrome blocked them, ruling out their use against Chrome’s CT-enforcing path during that period. That does **not** rule out unlogged certificates accepted by clients without CT enforcement. No exploitation has been established.
Chrome and Firefox pushed blocks on October 17 without requiring browser restarts. Google says an equivalent update reached most Android devices through Play Services and that restarting can prompt it, but a restart is not proof that every old device or app is protected. Mozilla is removing trust in the parent ECC root for software that does not receive its intermediate block. eMudhra told Mozilla that roughly 30,000 *other* certificates under that root need migration; they were not issued by the eight weak intermediates.
**Mitigation:** Update the operating system, browser, applications, language runtimes and CA bundles that verify TLS; rebuild and redeploy services or containers that bundle their own trust stores. Check the *specific app or device*, not just a browser on the same machine: a successful browser test cannot certify a separate client. Where updates are unavailable, administrators should assess blocking the eight affected intermediates or distrusting **every applicable signing chain**, including cross-signs, using vendor or trust-store guidance. Removing a broadly trusted root can break legitimate connections and is not a casual end-user fix. If a device cannot receive a trustworthy update or block, keep it away from sensitive connections until it can be replaced or isolated. Do not bypass certificate warnings or disable verification to restore connectivity. Operators serving certificates under the distrusted ECC root should obtain replacement certificates from another trusted hierarchy.
Sources:
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/
https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
https://emudhra.com/en/post/certificate-security-incident
https://www.openwall.com/lists/oss-security/2026/10/20/1
https://blog.cloudflare.com/emudhra-certificate-compromise/
https://emudhra.we-have-a-problem.com/
BITCOIN $83,896 | GOLD $4,133 | OIL $104.97 | S&P 500 $7,731 | US 10Y 5.10%
eMudhra’s weak CA keys leave unpatched clients open to forged certificates
Eight eMudhra intermediate certificate-authority keys created in April 2025 were so weak that their private values could be recovered from the public certificates. Mozilla says all eight P-384 keys had values below 256. Six intermediates were authorized for TLS certificates and two for code signing. eMudhra says a flaw in a key-generation ceremony produced weak keys alongside strong ones, and the weak keys were mistakenly selected for certification. The company says its infrastructure and root private keys were not compromised.
**The concern is a man-in-the-middle attack against clients that still trust those keys.** Someone who can intercept or redirect a device’s connection could use a recovered intermediate key to forge a certificate for a website the attacker does not control. A client that accepts the forged chain could then be shown an apparently valid HTTPS connection while its traffic is read or modified. An old phone, embedded device, application or server with a stale trust store—and no effective revocation check or Certificate Transparency enforcement—may remain exposed even after the CA revokes the intermediates. Age alone does not establish vulnerability; the client’s *actual certificate-verification path* does.
There are important limits to the observed harm. eMudhra says none of the eight intermediates issued end-user certificates. Google found no certificates from the six TLS intermediates in Certificate Transparency logs before Chrome blocked them, ruling out their use against Chrome’s CT-enforcing path during that period. That does **not** rule out unlogged certificates accepted by clients without CT enforcement. No exploitation has been established.
Chrome and Firefox pushed blocks on October 17 without requiring browser restarts. Google says an equivalent update reached most Android devices through Play Services and that restarting can prompt it, but a restart is not proof that every old device or app is protected. Mozilla is removing trust in the parent ECC root for software that does not receive its intermediate block. eMudhra told Mozilla that roughly 30,000 *other* certificates under that root need migration; they were not issued by the eight weak intermediates.
**Mitigation:** Update the operating system, browser, applications, language runtimes and CA bundles that verify TLS; rebuild and redeploy services or containers that bundle their own trust stores. Check the *specific app or device*, not just a browser on the same machine: a successful browser test cannot certify a separate client. Where updates are unavailable, administrators should assess blocking the eight affected intermediates or distrusting **every applicable signing chain**, including cross-signs, using vendor or trust-store guidance. Removing a broadly trusted root can break legitimate connections and is not a casual end-user fix. If a device cannot receive a trustworthy update or block, keep it away from sensitive connections until it can be replaced or isolated. Do not bypass certificate warnings or disable verification to restore connectivity. Operators serving certificates under the distrusted ECC root should obtain replacement certificates from another trusted hierarchy.
Sources:
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/
https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
https://emudhra.com/en/post/certificate-security-incident
https://www.openwall.com/lists/oss-security/2026/10/20/1
https://blog.cloudflare.com/emudhra-certificate-compromise/
https://emudhra.we-have-a-problem.com/
OpenSats has received the first donation from Strive under its recurring monthly commitment to support the Red Team Fund.
https://opensats.org/blog/opensats-receives-recurring-donation-from-strive
https://opensats.org/blog/opensats-receives-recurring-donation-from-strive
Found out yesterday that I’ve got a son on the way. Thanks @npub1qny3t...ew95gx nostr:nprofile1qqsp4lsvwn3aw7zwh2f6tcl6249xa6cpj2x3yuu6azaysvncdqywxmgpz4mhxue69uhk2er9dchxummnw3ezumrpdejqzrthwden5te0dehhxtnvdakqjay3h5 nostr:nprofile1qqsywt6ypu57lxtwj2scdwxnyrl3sry9typcstje65x7rw9a2e5nq8sprdmhxue69uhhyetvv9ujucnfw33k76twwpshy6ewvdhk6qgcwaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmqk8cne9 nostr:nprofile1qqsd0uazmzmhwseeym3rjhf3txyjapreapc6sq8yq8cy07cg45tlx2cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsw83g8p for the offhand fatherhood conversations over the years; I might not have gotten to this point without them
"I'm in Bitcoin for the long run, and OpenSats' support reflects the low time preference we share. It gives me the stability to dig into hard problems that take time to get right." —L0rinc https://opensats.org/blog/l0rinc-receives-lts
Technical details
allowlist: verified allowed
typepubkey
canonical/npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx
allowlistverified allowed
verificationID Verified · Signature Valid
pubkey04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9
nameODELL
nip05odell@primal.net
aboutfreedom
recent notes fetched10
relays queriedwss://purplepag.es, wss://nos.lol, wss://relay.damus.io, wss://relay.primal.net, wss://relay.nostr.org.tr, wss://relay.emre.xyz