Topic: Atascado! no, ¿atascado? si, no confirmado. - page 4. (Read 2206 times)

Ayer ya bajaron a las 251.515 inscripciones en TXs de la red de bitcoin, un todavía abultado 48,1% del total de las TXs procesadas, siendo un valor todavía elevado pero que ya causó un alivio en los fees de la red en las últimas horas.

Hay un par de bloques que han entrado a un mínimo de 200 sats/vByte y 180 sats/vByte recientemente, aunque parte de un lapso de tiempo de 44 minutos sin que se lograse minar un bloque, con el consiguiente aumento de la competencia para entrar en los bloques siguientes.
Es curioso que el último bloque minado tuviese varias TXs procesadas a razón de 23 sats/vByte, lo cual es un valor que rompe con la tónica del bloque precedente (232 sats/vByte) y el subsiguiente (183 sats/vByte por ahora). No sé si se debe a varios casos de CPFP o algo así, aunque son varias decenas de casos según veo.

Veo una luz al final del túnel, habrá que ver si es prematuro ...  

ORDI (cuyo listado en Binance causó toda esa segunda ola) bajó unos 25% desde su pico de 27,50 y falló de conseguir un nuevo ATH. RATS y SATS, que hace pocos días fueron listados en KuCoin aparentemente (ver aquí), no pudieron detener su caida. Y al menos las fees hoy ni ayer entraron significativamente al "territorio rojo".

Mi cuadro de mandos de Ordinals muestra que la cantidad de transacciones con contenido Ordinals tuvo un máximo de poco más de 500000 transacciones el 12 de noviembre. Sin embargo, el pico de la ola actual parece haber sido el 15 al 19 de noviembre, cuando se registraron en total casi 2 millones en 5 días, con un poco más de 470000 como máximo el día 18.

La "App" de Android también lo permite, es engorroso pero se puede establecer igual por monto o distancia (mbytes) en mempool. Jamás usaría esa estupidez de la "prioridad". Es al momento de enviar que está la opción.

Vale mencionar que electrum permite esa cualidad todavía, incluso el 1sat/B, pero en su versión escritorio, la App si o si va por el fee de mediana prioridad, y no hay opción si no a mejorar el fee. En cierta manera puede ser de gran utilidad cuando la relación de fee no excede el 3%.

Lo que hay que notar es que a veces, aun cuando hay espacio libre, por el efecto dominó de las wallet que compiten unas a otras en sus estimaciones, no se ven los azules. Hay momentos donde domina el amarillo y hasta rojo que es lo mas caro, y esos pasan primero siempre. Se tiene que desaparecer el rojo, el amarillo y el verde para que empiecen a pasar azules.

Pero lo otro que aveces ocurre es que los nodos directamente descartan las transacciones baratas. Si la wallet no auto-re-transmite, sencillamente se pierde la transacción (no ocurre). Esto pasa cuando llenan la mempool.

Es mas ahí se puede ver en el momento anterior los verdes copando la mempool lo que degeneró en la carrera de transacciones mas altas.

Y para mas enojo los causantes del spam al tener pool pueden pasar sus transacciones al momento que consiguen un bloque, no importa que valgan cero. Por eso sería muy bueno que la gente no usara mas ese pool y se alejara de esa compañía, así no tendrían como pasar basura barato a costa de las transacciones genuinas que están pagando una fortuna.

Ya que los desarrolladores no hacen nada, solo queda la opinión pública.

Mirando la web de mempool.space, aunque la tónica reciente sigue estado entorno a los 110-130 sats/vByte, hubieron un par de bloques relativamente reciente donde la tasa mínima que entró fue tan baja como 23 sats/vByte. Esto sucedió por ejemplo en este bloque que se minó dos minutos después de su bloque antecedente, o en este otro 12 minutos antes que su bloque predecesor. Supongo que estos pequeños alivios puntuales vienen auspiciados por el hecho de ser domingo.

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.

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.

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.

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.

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.

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.

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.

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.

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

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:




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.

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...

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.

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.

¿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.

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 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.

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).