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

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

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.

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

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.