Decentralized's avatar
Decentralized
decentralized@yakihonne.com
npub1qqqq...hrhr
#Bitcoin ₿ para aprender y educar. Co-Founder y Co-Organizador de @WoBitcoin Find me: https://nostree.me/decentralized@dinerosinreglas.com
Decentralized's avatar
Decentralized 1 month ago
Y mis canales de LN siguen vivos, menos lo que decidieron cerrar, está claro y por el momento, eso acaba de empezar!
Decentralized's avatar
Decentralized 1 month ago
Ya está. Se ha minado el bloque 961.632. ¿Bitcoin ha desaparecido? NOOOOO! Lo primero, porque es lo que importa a la mayoría: no ha pasado nada que te obligue a hacer nada. No hay dos Bitcoin. Si tienes tus bitcoin con tus llaves, no tienes que mover nada ni elegir bando. Lo que ha cambiado es lo que aceptan unos nodos concretos. Desde este bloque, los que aplican el BIP-110 solo dan por bueno un bloque si lleva la señal. El que no la lleve, para ellos no existe. Así que esos nodos (BIP-110) se han quedado ahí parados, esperado a por info BIP-110 mientras el resto de la red sigue. ¿Ahora qué? Dos caminos. Uno: que sigan parados. Cuantos más bloques pasen sin señal, más atrás se quedan. No se rompe nada, simplemente dejan de ver lo que ve todo el mundo. Dos: que alguien se ponga a minar desde donde ellos se quedaron y con la señal puesta. Ese día habrá dos cadenas de verdad, cada una con sus bloques. Y eso necesita potencia de minado detrás. Hoy señaliza el 2,5%. Es por lo que apuestán BIP-110. Iré contando lo que pase con datos, no con predicciones. View quoted note →
Decentralized's avatar
Decentralized 1 month ago
Cosquillas, para qué vamos a negarlo Muchas cosquillas o mariposas, escoge como llamarlas.
Decentralized's avatar
Decentralized 1 month ago
Lo importante del BIP-110 no es la activación. Es lo que pasa a partir del bloque 961.632. Hasta ahí señalizar es voluntario. A partir de ahí, y durante un periodo de reajuste completo (2016 bloques), los nodos que aplican el BIP-110 rechazarán como inválidos los bloques que no señalicen. Un detalle que no he leído en casi ningún sitio: aplicar el BIP-110 no se decide en el bitcoin.conf, se decide con el binario que ejecutes. Con los binarios oficiales de Knots, poner consensusrules=rdts o no ponerlo no desactiva nada: el nodo aplica las reglas igual. Ese parámetro es irrelevante. Quien ejecuta ese binario las aplica, lo sepa o no (un poco tricky en mi opinión). Y a partir de aquí algo importante en mi opinión. Los bloques van pegados unos a otros, como los vagones de un tren: no se pueden saltar. Un nodo con BIP-110 solo acepta los que llevan la señal "BIP-110"", así que en cuanto llegue uno sin ella, se planta ahí. Y a partir de ese momento los bloques van pegados unos a otros, como los vagones de un tren: no se pueden saltar. Un nodo con BIP-110 solo acepta los vagones que llevan la señal. En cuanto llegue uno sin ella, se planta ahí (se queda esperando). Y como todos los que vengan después van enganchados a ese, tampoco le valen, lleven la señal o no. Para volver a avanzar necesita que alguien se ponga a minar desde donde él se quedó, y con la señal puesta. Cuando eso ocurra habrá dos Bitcoin avanzando por separado. Ahí es donde se parte la cadena. Y mientras la señalización siga tan baja, esos nodos pueden pasar horas sin dar por bueno ni un bloque. Veremos online que sucede: image
Decentralized's avatar
Decentralized 1 month ago
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. 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. 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.
Decentralized's avatar
Decentralized 1 month ago
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:
Decentralized's avatar
Decentralized 2 months ago
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 →
Decentralized's avatar
Decentralized 2 months ago
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.
↑