La parte de regenerar macaroons es fundamental! View quoted note →

Volvemos a estar ready. Pero con un ojo encima (más grande que el de Sauron)! Gracias!! View quoted note →

Si corres BTCPay Server, actualiza ya a 2.4.2. Vulnerabilidad crítica bajo explotación activa. Y ojo: tener 2FA activado NO te protege. El fallo: la API Greenfield aceptaba autenticación Basic (usuario + contraseña) sin comprobar el segundo factor.

GitHub

Release 2.4.2 · btcpayserver/btcpayserver

This release contains fix of a critical vulnerability that is being actively exploited. You need to update as fast as you can. We recommend integra...

Con tus credenciales, alguien entraba por API con permisos completos. El TOTP no pintaba nada. Muy recomendable, actualiza también NBXplorer a 2.6.10.

GitHub

Release v2.6.10 · btcpayserver/NBXplorer

2.6.10

Si usas docker es más sencillo de actualizar. Actualizar no cierra el incidente. Si alguien entró, se llevó lo que hubiera dentro. Antes de reconectar nada: - Audita usuarios: Busca cuentas admin que no reconozcas - Revoca TODAS las API Keys, el parche no invalida las emitidas - Contraseñas nuevas Si conectas BTCPay con un nodo LN: - el macaroon se ve en texto en los ajustes de tienda. En LND borra los .macaroon y macaroons.db, donde está la root key. Si solo borras los macaroons, los robados siguen validando. Si alguien generó una hot wallet on-chain desde BTCPay (pésima opción, pero factible), la semilla está en tu base de datos. Mueve esos fondos hoy a una wallet con semilla generada fuera. Sobre todo si compartes tu instancia. Avisa a quien conozcas que corra BTCPay.

Debido a esta advertencia, el BTC Payserver de @Wo_Bitcoin y el de cualquier tienda que este usando el BTCPay de dinerosinreglas esta desactivado hasta nuevo aviso. Si sabes de alguien que este usando BTCPay, avísale de inmediato. 👇👀🔥🔥🔥🔥👀👇 Lo siento pero no tengo tiempo de buscar el post para Nostr:

X (formerly Twitter)

BTCPay Server (@BtcpayServer) on X

There is a critical vulnerability being actively exploited on BTCPay Server, which can result in the loss of funds. Please update your BTCPayServe...

180 bloques y contando.....

BIP-110 Observer

BIP-110 signalling, measured against own Bitcoin nodes. Every number labelled by how much it can be trusted.

GM. What a week, isn't? It's Friday, let's go!!!

Muchas gracias a Silkpad, de la mano de @ChavoGnuGrowers por apoyarnos un año más. Es un lujo que nos apoye. Y dale un vistazo a la nueva web, totalmente alineada por los valores de la empresa

SilkPad - Privacy & Security by Default

Donde la privacidad no es una opción, es el estándar. Hardware auditable, software libre y pagos anónimos. Compra ordenadores seguros hoy.

Gracias ❤️❤️❤️ Nos vemos más pronto de lo que parece! View quoted note →

Lo que llevo de verano, y acaba de empezar. WTF!

A lot of things is happening, but .....

BIP-110 Observer

BIP-110 signalling, measured against own Bitcoin nodes. Every number labelled by how much it can be trusted.

👇👀👀😍😍👀👀👇 View quoted note →

El 31 de agosto termina el periodo mid-term y las entradas cambian de precio. 3 días donde la actualidad manda y seguramente tratemos muchos temas de relevante actualidad, tanto en los talleres y como en los debates. 📅 2-4 oct · Madrid Nos vemos en #WOB26, 👇⚡️⚡️👇 View quoted note →

Otra excelente opción para crear tu semilla. De esta hemos hablado mucho en los meetups de @npub1p2lh...l4ue , tuvimos un taller en @Watch out, Bitcoin! y creo que hay que repetir:

SeedSigner: Air-gapped DIY Bitcoin Signing Device

SeedSigner: Air-gapped DIY Bitcoin Signing Device

BUILD YOUR OWN BITCOIN SIGNING DEVICE using a raspberry pi zero (VERSION 1.3) You can build an offline, air-gapped Bitcoin transaction signing devi...

El 1 de agosto de 2017, la gente que usa Bitcoin le dijo a los mineros: "Si no aceptan la mejora, no aceptamos sus bloques." Los mineros la aceptaron. Ese día quedó claro quién manda en Bitcoin: los usuarios. 🧡 Más info:

Dinero sin reglas

Historia de Bitcoin

Un repaso por la historia de bitcoin, una vista a la línea de tiempo de los eventos más relevantes de su historia en el tiempo

An unpopular opinion, offered as exactly that, a personal one. A lot of people are saying this week that multisig is the answer. Let me concede the strongest version of that argument up front: multisig across different manufacturers would have protected every single person affected by this. That's true, and it matters. But here's what I keep coming back to. Multisig doesn't remove a single point of failure. It trades one for another. Lose your descriptor, the file holding every participant's xpub, the script type, the derivation paths, and your funds are gone even if all three seeds are sitting safely in your hands. Two of three seeds without a descriptor is not a recoverable wallet. Most people who set up multisig back up their keys religiously and their descriptor nowhere. So the honest question isn't "is multisig more secure?" It's "more secure for whom, set up by whom, recoverable by whom in five years?" For someone who has never done a full recovery, a well-generated seed with a strong passphrase, backed up in metal, split across locations, beats a multisig they don't fully understand. Not because multisig is worse, because a setup you can't operate isn't a setup, it's a liability with extra steps. And if you're going to use a passphrase: back it up physically, separately from the seed. Never rely on memory. A typo produces a valid, empty wallet, not an error message. The real lesson from this week isn't multisig. It's independent failure domains. Don't let one manufacturer's mistake reach all your keys. Dice-generated entropy does that. A passphrase does that. Multisig across vendors does that. Pick the one you can actually execute. Start at kilometre zero. Nobody walked a thousand in a second.

⚠️ Hay mucha info y confusión sobre un problema reportado sobre dispositivos de ColdCard OJO, según información de la propia empresa, parece que es así y afecta solo a COLDCARD Mk3 y sí, la cosa parece seria. Afecta a semillas generadas en un Mk3 con firmware 4.0.1 (marzo 2021) o posterior, hasta la 5.0.3, la última que soportó ese modelo. Mk4, Q y Mk5 no están afectados según el análisis preliminar de Coinkite. Si tu semilla no se generó en un Mk3, esto podría no ir contigo. Pero te invitaría a seguir leyendo, al final hay recomendaciones. Ha circulado una reproducción del fallo con una cifra que explica en gran parte el problema ~80.000 estados posibles. Mira este post, es muy revelador:

X (formerly Twitter)

instagibbs (@theinstagibbs) on X

Confirmed. Mk2/3 vuln, I don't think mk4 is but can't be certain

Sin meterme en tecnicismos, que tampoco soy experto. Lo que viene a mostrar la imagen del post anterior es que se usaban unos 16 bits de aleatoriedad real. Deberían ser 256. No es entropía un poco floja. Es un espacio que se recorre entero en segundos, en un portátil normal. Por eso el barrido vació 501 carteras en dos bloques, aparentemente usando un script en bucle para hacer el barrido Si tienes fondos en una cartera generada por Mk3 sin passphrase, asume que están expuestos. La excepción que salva a mucha gente: passphrase BIP-39 Sí PASSPHRASE, el passphrase es un must!!! Si sobre esa semilla usaste una passphrase BIP-39, el riesgo es ínfimo. Con 16 bits de semilla pero una passphrase fuerte, el atacante tendría que romper la passphrase. 🚨 Passphrase BIP-39 NO es el PIN del dispositivo. No son lo mismo. Si no estás seguro de cuál usaste, asume que no tenías passphrase. Recomendación sobre qué hacer. Primero, calma, nunca se actúa en pánico. Genera una semilla nueva en un dispositivo no afectado Verifica el backup antes de depositar nada. Solo entonces mueves fondos. Conserva el backup viejo hasta terminar Si el Mk3 es tu única opción ahora mismo: crea una passphrase BIP-39 fuerte y única y mueve los fondos ahí. Es un parche, no la solución. 🔒 Y MUY IMPORTANTE X Privacidad: mueve UTXO a UTXO, cada uno a una dirección distinta. NO consolides. Consolidar puede ocasionar que enlaces todo tu historial de forma permanente e irreversible. Las comisiones se pagan una vez; la privacidad no vuelve. Pero si el saldo que tienes es importante y eres usuario afectado y no tenías passphrase, sacarlo va primero. La privacidad perfecta no sirve si te vacían la cartera mientras la optimizas. OJO, mucho OJO. Va a haber estafas. Falsos "verificadores de Mk3" pidiendo tus 24 palabras. Nadie necesita tu semilla para decirte si estás afectado. Nunca se da la semilla! Y no ejecutes scripts de reproducción en una máquina donde tengas claves reales. Migra con calma, pero sobre todo con cabeza. Precipitar una migración crea un riesgo más inmediato que el que intentas resolver. Seguramente haya más información, mantente informado. Aviso oficial: blog.coinkite.com/coldcard-mk3-seed-generation-warning/

Sparrow Wallet @craigraw acaba de lanzar la versión 2.5.3. Vamos con un pequeño post para comentar algunas mejoras. Hay cambios que afectan directamente a cómo de seguro es tu proceso de firma y a tu privacidad en red. Puedes ver las notas en: 🔗 github.com/sparrowwallet/sparrow/releases/tag/2.5.3 - Añade soporte para el hardware wallet ERA. Un dispositivo muy interesante para quienes buscan custodiar sus llaves fuera de un ordenador. Más opciones, más soberanía. - En mi opinión una de las cosas que más importan de este release es que Sparrow ahora verifica que la transacción que cargas o escaneas corresponde exactamente al PSBT que tienes abierto, revisando todas las pestañas activas. Firmar algo diferente a lo que crees estar firmando es un vector de ataque real. - Para los que usan Tor en Sparrow, el proxy externo ahora soporta autenticación por "safe cookie". En la práctica, la conexión a tu nodo a través de Tor es más robusta y compatible con más configuraciones. La privacidad bien hecha no debería dar fricciones. - Dos mejoras sutiles pero que son muy buenas y como todo en Sparrow, alineadas con la privacidad: · Al importar o exportar tu wallet, los archivos temporales ahora solo son accesibles por tu usuario del sistema. Menos superficie de ataque. · Y han añadido verificación de dependencias con firmas SHA. El código que compilan es el que publican. Si usas Sparrow, una buena razón para actualizar. Si no la usas, no sé a qué estas esperando. Asegúrate de validar la descarga antes de actualizar, recuerda que el propio Sparrow te ayuda a realizar esa verificación:

Ayer publicaba, en inglés que estos días he recibido las mismas preguntas: sobre el tema de moda, el BIP-110 y que son: Qué pasa el 8 de agosto, si tengo que hacer algo, y si esto va a activarse. Las dos primeras, IMO, tienen una respuesta más o menos clara. La tercera no la tiene nadie, y desconfía de quien te diga lo contrario. He montado esto para ordenar lo que sí se puede saber y aclarar lo que no se puede:

BIP-110 Observer

BIP-110 signalling, measured against own Bitcoin nodes. Every number labelled by how much it can be trusted.

¿TENGO QUE HACER ALGO CON MI BITCOIN? No. Es lo primero de la página, antes de cualquier gráfico. Si guardas tus bitcoin en autocustodia, no tienes que mover nada, ni actualizar nada, ni elegir bando. ¿SE HA PARTIDO BITCOIN EN DOS? Esa pregunta no hace falta que te la conteste nadie. Se comprueba. Detrás del panel hay dos nodos propios. Uno sigue las reglas de hoy, el otro las del BIP-110. Mientras los dos vean los mismos bloques, hay una sola cadena. El día que dejen de coincidir, hay dos. Nadie tiene que anunciarlo. EL DATO QUE CASI NADIE ESTÁ MIRANDO El tiempo: Aviso a navegantes, en Bitcoin todo, TODO se mide en Bloques y no es lo mismo 20 bloques con una media de 10 minutos, que 5 bloques con media de 5 días cada uno (es un ejemplo), es algo que hay que saber y entender. Y UN AVISO QUE VA EN LA PROPIA PÁGINA El recuento de nodos no mide el apoyo al BIP-110. Nadie puede medirlo, este panel incluido. Los motivos están en pantalla. Ah, y las "fechas" son tres, no una. Ese es el error más extendido de todo el debate y está explicado allí en cristiano. Leído de nodos propios. Sin exploradores, sin APIs de terceros, sin analítica. Licencia MIT y metodología pública. Puede tener fallos en las métricas y los iré ajustando. El crawler es la parte más frágil, así que si detectas alguno, abre un issue: github.com/decentralizedb/bip110-observer

Y por cierto, estamos a 40.000 bloques de llegar al millón! Y con toda esta "movida" del BIP-110 Entérate de que va!

BIP-110 Observer

BIP-110 signalling, measured against own Bitcoin nodes. Every number labelled by how much it can be trusted.

View quoted note →

Three questions keep landing in my inbox: what happens on August 8th, whether I need to do anything, and whether this is going to activate. The first two have answers. Nobody has the third, and be wary of anyone who tells you otherwise. I built this to sort out what can actually be known:

BIP-110 Observer

BIP-110 signalling, measured against own Bitcoin nodes. Every number labelled by how much it can be trusted.

DO I NEED TO DO ANYTHING WITH MY BITCOIN? No. It is the first thing on the page, before any chart. If you keep your bitcoin in self-custody, you do not need to move anything, upgrade anything or pick a side. The real risk in these weeks is not the fork. It is the scams that come with it. HAS BITCOIN SPLIT IN TWO? Nobody needs to answer that one for you. It can be checked. Behind the panel there are two of my own nodes. One follows today's rules, the other follows the BIP-110 rules. While both see the same blocks there is one chain. The day they stop matching, there are two. Nobody has to announce it. And since the rules are already written, you can see today how that same page will look if the chain splits, and if it comes back together. Only the point marked NOW carries real data. The other two are an example, so the day it changes does not catch you off guard. THE FIGURE ALMOST NOBODY IS LOOKING AT Right now 2.33% of blocks signal and 55% is needed. But the percentage on its own says little. What says something is where it comes from: across the last five closed periods, 77 of the 78 blocks that signalled came from a single pool holding 3.2% of mining. That describes one operator, not a movement. AND A WARNING THAT LIVES ON THE PAGE ITSELF The node count does not measure support for BIP-110. Nobody can measure that, this panel included. The reasons are on screen, in full, not tucked away in a footnote. Every figure carries a label for how much it can be trusted, and none of them gets promoted. Also, the dates are three, not one. That is the most common mistake in the whole debate and it is explained there in plain language. Read from my own nodes. No explorers, no third party APIs, no analytics. MIT licensed and the methodology is public. github.com/decentralizedb/bip110-observer The metrics may have bugs and I will keep fixing them. The crawler is the most fragile part, so if you spot one, open an issue.

Good morning! Do your own research and make your own decisions. Don’t let anyone else tell you what to do or what’s best for you. Enjoy the journey and try not to get distracted by outside noise.