Atascado! no, ¿atascado? si, no confirmado.

[d5000]

Y recordar que fue por unos cambios relativamente recientes que se abrieron las puertas a estos abusos.

Entiendo tu enojo pero es incorrecto que "estos abusos" solo fueron posibles por Taproot (lo que probablemente quieres decir) y por ende una restricción de Taproot probablemente no tendrá el efecto deseado.

Ya lo hemos discutido varias veces: había varias formas de insertar NFTs en la blockchain, con métodos un poco más caros (en términos de fees) pero sin embargo posibles y la diferencia de precio no es tan grande, como lo que hizo Dogecoin con sus "Doginals" (Doge carece de Taproot y Segwit).

Pero mucho más importante: la congestión desde mayo es principalmente consecuencia de los tokens BRC-20. Y sistemas para comerciar tokens sobre Bitcoin existen desde al menos 2013 (EPOBC). Los RATS, PEPEs y GROKs se podrían haber implementado sin problemas con Omni, Counterparty y otros mecanismos.

Es discutible si la ola de Ordinals hubiera ocurrido si no se hubiera implementado Taproot. Visto desde la perspectiva "sociológica", es posible que Taproot abrió esta puerta causando una especie de "efecto cadena", porque (Paso 1) alguien (Rodarmor) se dio cuenta que con TR se podían "ordenar" satoshis, luego (Paso 2) encontró una forma para vincular estos satoshis con NFTs, y (Paso 3) esto fue tan popular que la gente empezó a experimentar y (Paso 4) alguien "descubrió" BRC-20 y (Paso 5) BRC-20 se hizo más popular que Counterparty, Omni etc., a pesar de ser claramente inferior. La explicación para el último paso es que la comunidad que se formó a partir del paso 2 vino de los NFTs de Ethereum y otros altcoins, no conocía las soluciones anteriores, y creyó haber descubierto algo nuevo, y se creó toda una dinámica de FOMO y esperanzas de "hacerse rico". Podríamos añadir un paso 6, que serían entidades que quieren dañar al Bitcoin, que pueden o no haber aprovechado la situación (esto es pura especulación, pero parece haber algunos indicios).

Pero como dije, esto es una causalidad creada por hechos "sociales" concretos, en realidad por casualidades. Tecnológicamente no hacía falta Taproot para este fenómeno. Tranquilamente se podría haber formado una moda similar con algo como Counterparty que usa OP_RETURN y no Taproot.

[1714493768]

1714493768

[1714493768]

1714493768

[1714493768]

1714493768

[DdmrDdmr]

<…>

Yo también me postilo claramente en el bando que los que ven los Ordinas sobre la red de Bitcoin como una aberración, que rompe el esquema base para lo cual fue concebido, generando problemas (por lo menos costes adicionales y saturación) precisamente para aquello que sí fue concebido.

Exagerando el asunto, y salvando las distancias, es como si las autopistas, concebidas para soportar el tráfico de vehículos en un rango de velocidades min/max, se llenasen de mesas para picnics en pro de la libertad de uso, y visto que hay zonas con unas magníficas vistas al mar o a la montaña, se plantasen allí ralentizando todo el tráfico tan ricamente.

[Hispo]

<…>

Yo también me postilo claramente en el bando que los que ven los Ordinas sobre la red de Bitcoin como una aberración, que rompe el esquema base para lo cual fue concebido, generando problemas (por lo menos costes adicionales y saturación) precisamente para aquello que sí fue concebido.

Exagerando el asunto, y salvando las distancias, es como si las autopistas, concebidas para soportar el tráfico de vehículos en un rango de velocidades min/max, se llenasen de mesas para picnics en pro de la libertad de uso, y visto que hay zonas con unas magníficas vistas al mar o a la montaña, se plantasen allí ralentizando todo el tráfico tan ricamente.

Aunque comprendo la comparativa que acabas de hacer, creo que una mejor sería algo así como si las autopistas más importantes de España (las cuales seguramente tienen una vistas muy hermosas en algunos de sus tramos) de repente de llenasen de personas que pretenden pintar sobre el asfalto sus obras de arte y en pro de la libertad, los conductores tienen que ir a velocidades más moderadas para poder esquivarles para no matarles o arruinar la pintura fresca, esto causando un atascamiento.

Aunque Artemis3 ya lo ha dicho. Es algo perturbadora la falta de acción de los desarrolladores, aunque por un lado también entiendo que quizá ellos quieran ahorrarse el tomar una acción que divida s la comunidad y genere más hard forks innecesarios.
Eso sería el escenario más ventajoso para el gran hermano, vernos divididos y discutiendo sobre NTFs, cuando la CBDCs cada vez más se acercan.

En ese aspecto yo admiro a la comunidad de monero, para ser honesto, tienen su norte claro sobre la privacidad y para ellos es un todo o nada. Ojalá nosotros tuviésemos el norte claro en lo que queremos.

[Artemis3]

¿Dónde está la solución técnica que se debería aplicar?
Para los usuarios, quizás es aceptar los tiempos de espera por factores conocidos y resignación. Si un experto dice lo mismo es confuso.

La solución técnica está en manos de los desarrolladores. Al común de los mortales les queda lo que tu has dicho, nada mas.

Hay proridades, los spammer pagan para inundar la cadena de bloques con cosas como esta:



Por supuesto que en el primer mundo van a pagar mas por eso que en el tercer mundo enviando remesas a casa, pagar por servicios básicos, alimentación y esas cosas de pobres. Anda que las nft, memes y juegos valen mas y por eso pasan, especialmente cuando hay una empresa detrás apoyándoles en enbasurar Bitcoin para sus fines de lucro.

Lo mas que podemos hacer es señalar y boycotear.

[d5000]

La solución técnica está en manos de los desarrolladores. Al común de los mortales les queda lo que tu has dicho, nada mas.

Hay proridades, los spammer pagan para inundar la cadena de bloques con cosas como esta:

¿Y cómo exactamente? ¿Hay algún BIP? ¿Has leido mi post? Espero que no tengas en mente el bloqueo "ingenuo" que quería implementar Luke-jr, es decir simplemente bloquear una parte del código de Ordinals ...

Lo más parecido a una solución es lo que hizo una altcoin, Peercoin, que intentó restringir Taproot en v0.12.3 (ver RFC-27) para evitar el uso de Ordinals para NFTs grandes. Pero el tamaño máximo allí es de 100 kB, esto bloquea a NFTs extremamente grandes, pero no tokens como BRC-20 o imágenes pequeñas como estas colecciones de monos que estaban tan de moda en algún momento. Además, en PPC la situación es diferente, no se implementó ninguna de las soluciones para tokens como Counterparty, el coin no es muy conocido, y encima el protocolo requiere una comisión mínima por kB.

No hay ningún mecanismo de restricción que yo conozca que evite que se cambie el protocolo (como BRC-20) ligeramente o directamente se pase a algo como Counterparty.

Es decir, si existe una solución: usar el protocolo de Grin (MimbleWimble). Pero esto cambiaría fundamentalmente el funcionamiento de Bitcoin, necesitaría una hardfork, y rompería compatibilidad con un montón de estándares útiles que se han creado con Bitcoin Script, entre otros, Lightning y Atomic Swaps.

La otra solución, la que veo más viable, es fomentar el desarrollo y uso de cadenas laterales (como Nomic) y rollups (ver Bitcoinrollups), como lo hizo Ethereum en los últimos años (recordemos que Ethereum tiene el problema de comisiones altas desde hace varios años). Y por supuesto, LN.

[Artemis3]

Hay un buen hilo en la sección en inglés con varias propuestas. Otra cosas es que nadie las quiere ni leer.
Yo no creo que se pueda detener, pero si se puede hacer mas costoso y tedioso a los spammer. Hay que tomar en cuenta de que cambios relativamente recientes permitieron esto, así que con algunos ajustes se puede mitigar o desincentivar.

Lo de Luke-Jr es mas que todo ahorrar espacio y ancho de banda en los nodos, y tendría que actualizarse constantemente.

Lo de Grin es buena idea pero ya eso es una solución de fondo y está difícil dada la apatía generalizada que se ve en el tema.

Lo de "fomentar" cadenas laterales es bastante inútil. Ellos ya saben que pueden hacer su spam mas barato en Ethereum, buena suerte tratar de convencerlos. Lo único que serviría es hacerles mas caro en Bitcoin todo a ver si deciden irse por ahí...

Pero tenemos un troyano que es uno o varios pool dispuestos a empujar su basura a bajo costo. Los pool al momento de conseguir un bloque pueden además insertar las transacciones que quieran, así que fuera de cadena perfectamente hicieron un negocio para spamming, y con eso tienen su fuente de ingreso adicional, a costa de, ya sabes... Bitcoin, que les va importar nunca les importó.

Solo queda señalarlos. Ojalá los mineros decidieran salirse de esos pool pero claro hay mucho minero que piensa igual que ellos, solo están para sacar una ganancia ni si quiera guardan los bitcoin lo venden todo, mente corto-placista. Menos mal que el futuro no es de ellos, se irán en la medida que la minería se hace menos y menos rentable.

Y con las cosas peligrosas que cierto pool está haciendo, no sería de extrañar que quiebre esa empresa por completo. ya veremos cuanto les duran sus juegos con dinero que debería permanecer en reserva. Por supuesto necesitan liquidez para tratar de impedirlo, y de ahí que como buenos mercenarios se presten a ensuciar Bitcoin con basura a cambio de dinero.

[d5000]

Hay un buen hilo en la sección en inglés con varias propuestas.

¿A cual te referís? Yo los que conozco son:
Time to roll-back Ordinals?
NFTs in the Bitcoin blockchain - Ordinal Theory
BRC-20 needs to be removed
On Ordinals: Where do you stand?

En varios de ellos estoy/estuve participando en la discusión, pero no encontré ninguna propuesta que me convenció. Quizá hay otro que no conozca.

Yo no creo que se pueda detener, pero si se puede hacer mas costoso y tedioso a los spammer. Hay que tomar en cuenta de que cambios relativamente recientes permitieron esto, así que con algunos ajustes se puede mitigar o desincentivar.

O sea, restringir Taproot. Pero nuevamente, el problema de fondo no se soluciona si hacen simplemente un swap de sus tokens a Counterparty, Omni, o los "Runes" propuestos por Rodarmor. Debido a que se trata en todos los casos de tokens 100% centralizados y 100% preminados, un swap de esta índole no representa ningún problema.

Lo de Luke-Jr es mas que todo ahorrar espacio y ancho de banda en los nodos, y tendría que actualizarse constantemente.

Lo del ancho de banda me parece un argumento válido. Sin embargo, yo estaría en contra que este parche se incluya en el código de Bitcoin-Core estándar, porque justo con las posibles actualizaciones el código se podría tornar complejo y difícil de mantener. Pensemos que puede haber otros tipos de transacciones controvertidos en el futuro, y que varios grupos de usuarios quieran usar el mismo método, no me quiero imaginar el lío que podría significar.

Lo de "fomentar" cadenas laterales es bastante inútil. Ellos ya saben que pueden hacer su spam mas barato en Ethereum, buena suerte tratar de convencerlos.

Las cadenas laterales no las tengo en mente principalmente para los spammers. Más que nada, proveerían mecanismos para realizar transacciones más baratas, como lo hacen actualmente las/los (?) rollups en Ethereum.

El pool al que te referís es Luxor (el que adquirió OrdinalHub), ¿no? ¿Incluyó nuevamente Ordinals no estándares?

Estoy totalmente de acuerdo que se puede señalar a estos pools y pensar en estrategias comunicacionales (=hacer propaganda contra Ordinals y estos pools), siempre y cuando esto no implique incluir tecnologías en Bitcoin Core que puedan posibilitar la censura. El que quiera aplicar un parche que lo aplique pero estoy en contra que un parche de este tipo sea "política oficial" del proyecto.

Mis mayores esperanzas con respecto a una solución integral del problema son las tecnologías que permiten validar la cadena sin los datos "brutos" de transacciones, lo que permitiría borrar todos los datos arbitrarios (como Ordinals, OP_RETURN ...) en la blockchain sin perder el estatus de "nodo completo". Es lo que está desarrollando ZeroSync, por ejemplo. Pero son tecnologías que necesitan un par de años más. Creo que las cadenas laterales están más cerca de ser implementadas (ya existiendo en Ethereum), y LN ya se puede usar (y es soportado por cada vez más exchanges).

[Artemis3]

En alguna de las respuestas dijeron que el método Counterparty/Omni es de hecho mas costoso, así incluso eso sería una pequeña ganancia a desincentivar el spam. Habrá que seguir leyendo a veces abren otros hilos y me pierdo, pero bueno.

[d5000]

En alguna de las respuestas dijeron que el método Counterparty/Omni es de hecho mas costoso, así incluso eso sería una pequeña ganancia a desincentivar el spam. Habrá que seguir leyendo a veces abren otros hilos y me pierdo, pero bueno.

Esto ya lo refuté en uno de los hilos ingleses

Creo que haría falta una explicación detallada (se un poco del tema, si bien nunca desarrollé nada para Counterparty/Omni, pero usé otro mecanismo similar para crear tokens experimentales para una altcoin que cuenta con la misma tecnología que Bitcoin).

Supongo que sabes que las transacciones que usan Segwit tienen un "descuento": es decir en una parte (la ScriptSig que contiene las firmas digitales o Signatures y la clave pública, el llamado "Witness" / Testigo) su peso "ponderado" en vBytes es de solo una cuarta parte de su peso real en Bytes (se estima que una transacción simple pesa aprox. un tercio menos en vBytes si usa Segwit, y por ende es más barata en cuanto a fees, pero siempre depende del porcentaje de la transacción ocupada por Witnesses).

Primero vamos al método OP_RETURN (Omni/Counterparty):

Counterparty/Omni almacenan metadatos en una salida (output) OP_RETURN cuando se crean y se transfieren tokens. Estos no cuentan con el descuento que ofrece Segwit. Es decir que su peso "ponderado" en vBytes es exactamente igual a su peso "real" en Bytes. Si este conjunto de metadatos es muy grande entonces esto puede encarecer bastante la transacción.

Las entradas (inputs) de las transacciones Counterparty/Omni pueden, sin embargo, beneficiarse del descuento, si se envían desde una dirección Segwit, es decir si cuentan con un witness que fue creado con los métodos de Segwit. Las transacciones que enlazó alani123 aquí no usaron Segwit en ninguna entrada ni salida. Por ende tuvieron un peso de 1 Byte=1 vByte para toda la transacción. Si hubieran usado Segwit, podrían haber sido significativamente (hasta 35% en el caso de CP y 31% en el caso de Omni) menos pesadas (en vBytes), como también figura en el explorador de bloques que visualiza estas transacciones.

Uno se puede preguntar por qué los que crearon estos tokens no usaron Segwit. Es posible que algunos software populares de Counterparty/Omni simplemente no cuenten con soporte para esta tecnología. Pero desde el punto de vista técnico no hay nada que impide usar direcciones Segwit para transacciones Counterparty/Omni. Las partes que no están en OP_RETURN son idénticas a transacciones que transfieren Bitcoins. (Edit: Finalmente encontré una transacción de Counterparty que usa Segwit, y tiene un "peso" similar a las transacciones de BRC-20 que enlazó alani123. Pero es verdad, la mayoría de las tx de Counterparty entre las últimas del explorador Xchain no usan Segwit. Muy extraño ...).

En general se necesita una transacción en Counterparty para crear un token, y otra, para transferir tokens de este tipo (a la address del creador y/o a otras direcciones). Cada vez que se transfiere el token se necesita solamente una transacción.

Ahora vamos a Ordinals / BRC-20:

En BRC-20, lo que se hace es que se crea primero un script en TapScript. Este script contiene los metadatos del token y las reglas. Luego se crea un hash de este script.

Este hash en Taproot funciona como el hash de la clave pública en transacciones de BTC comunes (P2PKH/P2WPKH), y se usa para una primera transacción (llamada "commit transaction"). En general es una transacción pequeña y se puede usar el descuento de Segwit para el Witness si se envía desde una dirección Segwit.

Ahora se crea una segunda transaccion, la "reveal transaction", con el script completo y la firma como Witness. Es decir: los metadatos también gozan del descuento Segwit.

Pero hay un gran PERO: Hasta ahora, solamente creamos los tokens sin distribuirlos, y ya hemos necesitado dos transacciones (commit y reveal transaction).

Ahora para transferir los tokens a otra address, tenemos que volver a realizar un proceso muy similar (solo con otros metadatos): crear ¡una commit transaction y una reveal transaction!

Y eso no es todo: para cada una de las addresses a la que queremos transferir tokens BRC-20, tenemos que repetir el proceso (otra vez 2 transacciones). En cambio, en el caso de Counterparty/Omni, si funcionan igual que el estándar con el que trabajé yo, se pueden transferir tokens, con una sola transacción, a decenas de addresses.

Conclusión

Es posible que un "mint" de BRC-20 sea más barato que un "mint" de Counterparty (u Omni), a pesar de necesitar dos transacciones, si el mint de Counterparty no se realiza desde una dirección Segwit. Pero para transferir los tokens (es decir, de hecho para venderlos y generar un beneficio) necesito siempre dos transacciones, mientras que en Counterparty solo necesito una. Es decir como mínimo tengo 117 vBytes más; y es difícil conseguir tanto descuento con el Witness Discount de la salida Taproot como para contrarrestar esto. Cuanto más transacciones se realizan con el token, mayor es el ahorro de espacio (real y también "ponderado", si se usa Segwit) que beneficia a usuarios de Counterparty.

A esto se suma que BRC-20 está tan mal hecho que usaron texto (en vez de un formato binario) tanto para el tipo MIME como para los metadatos (para los cuales se usa JSON, que es todavía más ineficiente). Los estándares como Counterparty en general usan formatos binarios que ahorran más de la mitad de los datos.

[Artemis3]

Eso es exactamente uno de los puntos claves entre Stratum V1 y Stratum V2, y mira como ha sido de lenta la adopción. Aparte de que va cifrado, es binario en lugar de texto claro json. Pero bueno, ahí siguen los mineros avisando a todo el mundo donde minan y cuanto...

[danadc]

Esto parece como si no terminara, solo queda poco tiempo para el halving de BTC y esto parece ser algo que están aprovechando los mineros para seguir ganando a lo grande ¿será que están aprovechando porque después del halving las ganancias no serán igual? el artículo no da muchas esperanzas que los fee bajen:

Del mismo modo que el pasado mes de mayo, las tarifas de Bitcoin suben motivadas por la actividad en los Ordinals. Como se puede apreciar en la imagen de abajo, en mayo, con el estallido de la fiebre de los tokens BRC-20, también hubo un pico en las comisiones por transacción.

Original de Cripto Tendencia: Tarifas de Bitcoin suben y benefician a los mineros  https://criptotendencia.com/2023/11/17/tarifas-de-bitcoin-suben-y-benefician-a-los-mineros-2/#google_vignette

La motivación de ser mineros aumentan,queda poco pero estan ganando mucho dinero,para estas fechas las cosas pueden ser bastante emocionantes ganar dinero,si se están haciendo su diciembre.


Yo no entiendo lo técnico,pero esto parece no terminar,y en el articulo dicen que con LN que es lo más barato están pasando esto,puede ser algo que seguira siendo duro para todos los que quieran retirar algo de BTC.

[DdmrDdmr]

Esto parece como si no terminara, solo queda poco tiempo para el halving de BTC y esto parece ser algo que están aprovechando los mineros para seguir ganando a lo grande ¿será que están aprovechando porque después del halving las ganancias no serán igual? <…>

La situación actual viene esencialmente provocada por la competencia de las TXs relativas a Ordinals. Los mineros, a priori, se aprovechas de manera pasiva debido a la competencia de las TXs para ser mimadas, pero no provocan la situación. Estaba viendo bloques ahora mismo por encima de los 300 sats/vByte, una aberración para el que ha de mover montos modestos y/o tenga prisa por pasar su TX. A todo eso faltaría añadir el efecto que pudiese traer la cercanía cada vez mayor del halving, y la aprobación de las spot EFTs.

Pero bueno, sigamos contemplativos con los Ordinals, que seguro que ayuda a ganar usuarios adeptos de Bitcoin para usos convencionales oiga …

Edit: En este artículo lo atribuyen a las ETFs, pero no es lo que hemos estado viendo en días pasados:
https://es.cointelegraph.com/news/bitcoin-fees-skyrocket-etf-hype

[Don Pedro Dinero]

La situación actual viene esencialmente provocada por la competencia de las TXs relativas a Ordinals. Los mineros, a priori, se aprovechas de manera pasiva debido a la competencia de las TXs para ser mimadas, pero no provocan la situación. Estaba viendo bloques ahora mismo por encima de los 300 sats/vByte, una aberración para el que ha de mover montos modestos y/o tenga prisa por pasar su TX. A todo eso faltaría añadir el efecto que pudiese traer la cercanía cada vez mayor del halving, y la aprobación de las spot EFTs.

Yo recientemente hice una transacción alrededor de 100 sats/vByte cuando mempool.space estimaba 170, y por debajo de 160 lo consideraba baja prioridad, lo que pasa es que uno ya pinta canas, miré la mempool por otros dos sitios y como no tenía prisa elegí esa tarifa. En un par de horas o tres ya tenía la primera confirmación.

[DdmrDdmr]

<…>

No sé si es un patrón común, pero con cierta lógica, las noches y madrugadas (que dependen del huso horario que miremos, pero bueno) son más propensas a tener bloques minados con fees algo más bajas, siendo altas ya de por sí.

El tema es precisamente cuánto podemos llegar a esperar para que la TX se procese sin mayores perjuicios. Para usos operativos como pagos in-situ en estos instantes no te puedes ir por menos de 300 sats/vByte, y eso teniendo el RBF activo y a la expectativa de lo que suceda. Como se atrase un poco el bloque (yo recuerdo algún caso de retraso de unos 50 minutos entre bloques), los 300 sats/vByte se quedarán cortos.

[Don Pedro Dinero]

No sé si es un patrón común, pero con cierta lógica, las noches y madrugadas (que dependen del huso horario que miremos, pero bueno) son más propensas a tener bloques minados con fees algo más bajas, siendo altas ya de por sí.

Sí que es un patrón común que yo vengo siguiendo hace tiempo. Cuando son las 00:00 en Portugal, son las 22:00 en el este de Europa , en las zonas más al este del continente americano son las 03:00 y en las más al oeste son las 08:00 (incluso la zona más al oeste de Alaska son las 09:00). O sea que más de medio mundo o está durmiendo o a punto de irse a dormir/acabado de levantar: África, Europa y América.

Si estás en Europa sobre las 21:00 y ves unas fees de 200 sats/vByte para una confirmación en un par de horas puedes hacer cálculos mirando la mempool y enviarla a 150 o menos porque sabes que va a haber un bajón durante la noche Euro/Africana/Americana y eso es una cosa que no tienen en cuenta los exploradores que estiman fees. Puedes incluso estimar más a la baja si es viernes o sábado noche.

Espero que este análisis os ahorre unos satoshis. A mí me los ha ahorrado.

[DdmrDdmr]

Mirando por curiosidad en mempool las TXs con RBFs que van realizándose con esperanzas de mejorar su prioridad para ser minadas (https://mempool.space/es/rbf), hay casos muy curiosos puntuales. He visto por ejemplo RBFs que pasan de 361 stats/vByte a … 361 sats/vByte. Otro caso pasa de 3266 sats/vByte a 3535 sats/vByte. Alguno se aventura de los 10 sats/vByte a los esperanzadores 11 sats/vByte.

Lo curioso es que, además, entre los casos que muestra la página, no veo que sean Taproot, luego no van a ser Ordinals (por lo menos en los que he visto). Lo interesante sería ver algún tipo de análisis que cruzase los casos de RBF con segmentos de sats/vByte y con si la TX es de Ordinals o no.

[danadc]

He tratado de seguirlos con lo uq están diciendo,como tengo dudas busqué qui en este artículo que ha ayudado mucho:

 Aprende a usar tu wallet de bitcoin Electrum  https://www.criptonoticias.com/tutoriales-guias/aprende-personalizar-cartera-bitcoin-electrum/

pero lo que hablan de sats/vBytes no me sale, solo me sale es : sat/byte y eso es algo que no sé donde cambiar,en las tools tengo BTC, para cambiar esos parámetros no sé par que pueda guiarme con ustedes, y espero una entrada de transferencia que dice: Unconfirmed [rbf, 25. sat/b, 42.75 MB], eso quiere decir que usaron un fee de 25 sat/byte? y si yo quiero hacer una transferencia,puedo poner en sat/byte =25 verdad y asi se envía.

[DdmrDdmr]

<…>

La guía no tiene mala pinta, aunque al ser del 2018 puede contener alguna imprecisión o pantalla que diste un tanto del formato vigente. Los datos de los fees parece que los está realmente mostrando en sat/vBytes (virtual byte) tanto en la versión desktop como en la versión Android, aunque la etiqueta ponga sat/byte. Lo he corroborado mirando una misma TX en Electrum y en un explorador de bloques, y observo exactamente el mismo número en ambos sitios pero con las unidades con un caption de sat/byte en uno y sat/vByte en otro (en este post sugieren que el problema persiste, por extraño que parezca).

Por lo que entiendo, estás esperando una transferencia realizada con una TX que aún no está confirmada, que tiene el flag de RBF, y que paga a razón de 25 sat/byte (25 sat/vByte realmente si lo vemos en Electrum, por lo del caption mal puesto). Si te la están enviando a ti, al tener, has de tener presente que:

- Al tener 0 confirmaciones y RBF, no puedes darla por buena hasta no ver cuanto menos 1 confirmación. Hay gente que aprovecha para engañar a otros diciéndole que le ha enviado la TX, pero luego va y usar el RBF para cambiar la TX y reenviarse los fondos a sí mismo, sin que te lleguen. Nunca hay que dar por válida una TX sin confirmaciones, aunque la veamos en curso.

- 25 sat/vByte es algo hoy por hoy muy bajo como fee (ver https://mempool.space/es/), y no está claro lo que tardará en procesarse. Puede tardar varios días e incluso semanas en procesarse a ese fee. Todo depende de cómo vaya la red y de lo que tarden en procesarse buena parte de esos 233K TXs todavía en cola. Podría incluso llegar a cancelarse eventualmente, aunque no lo podemos saber en estos momentos. Digamos que a ese fee hay incertidumbre de cuándo podrá procesarse.

[Artemis3]

O que haga crash de nuevo el mercado de las porquerías con las que están inundando la cadena de bloques. Pero eso es un mirar para otro lado como hicieron ya todo este año los desarrolladores. Mientras aprovechan los que quieren empujar sus altcoins o "negocios" con canales paralelos, etc, y los timadores que se aprovechan de la situación. Seguramente se pondrán de moda los robos en LN.

[Don Pedro Dinero]

<...>

No me suelo citar pero ayer justo envié una transacción a menos de la mitad de lo que mempool.space estimaba como una tarifa baja, y entre que era fin de semana y la noche, se ha confirmado. La verdad es que hoy han bajado bastante, se nota en domingo de normal. Veremos si sigue mucho la semana que viene el spam.