Voy a empezar con un “disclaimer”. Yo estoy a favor del IFP (“Infraestructure Fund Proposal”) o propuesta de fondos para invertir en desarrollo de infraestructura en Bitcoin Cash (BCH).

Desde el anuncio inicial con la primera forma de la propuesta esta ha resultado muy polémica con personas a favor y en contra y con un fuerte debate en las redes sociales principalmente twitter, telegram, Reddit y esta misma plataforma read.cash.

El debate, muy legítimo e interesante, no ha conseguido acercar posturas sino más bien radicalizar las posiciones de cada una de ellas. Buena parte de este desenlace tiene que ver con las tácticas que tengo intención de desenmascarar en este artículo.

En este artículo no voy a argumentar las ventajas del IFP, aunque algunas se puedan inferir, pero las que el lector deduzca pueden no ser la totalidad de ellas.

Para una referencia temporal completa a lo sucedido relativo al IFP recomiendo la parte final de https://coinspice.io/news/bitcoin-cash-developers-fork-abc-reference-implementation-client-create-bch-node/ que permitirá al lector acudir a las fuentes de los anuncios presentados. Es muy importante acudir a las fuentes, no a la opinión que sobre esa fuente otros tengan.

Este artículo recoge muchos de mis argumentos utilizados por mí inicialmente en el debate que se lleva a cabo en el canal de telegram en español “Bitcoin es Cash | BCH”. Para aquellos que quieran unirse https://t.me/BitcoinEsCashBCH

Como es lógico cada parte acusa a la otra de falta de “fair play”. Con cada critica al IFP voy a responder con mis pensamientos y mis denuncias.

Críticas al IFP.

1.       La primera crítica que escuché fue: el IFP no es una propuesta, es una imposición de impuestos.

Utilizar los términos imposición e impuestos son una táctica torticera para inclinar el pensamiento inicial en contra del IFP por el rechazo que dichos términos generan en el subconsciente de cada uno de nosotros. No es casualidad el uso de dichos términos.

Yo puedo argumentar que no es una imposición porque en primer lugar la propuesta ha pasado por diferentes modificaciones de sus términos como puede verse en la referencia temporal que recomendé.

En segundo lugar, no es una imposición porque tiene que pasar por un proceso de ratificación estandarizado y ya usado en otras ocasiones conocido como el BIP-9. Este proceso establece que para que dicha propuesta se active, es decir, pase a formar parte de las reglas de consenso que rigen en BCH, los mineros deben señalizarla a favor en los bloques que minen con una mayoría de 2/3. Por supuesto muchos critican este umbral de 2/3 por considerarlo bajo, pero he de decir que es mucho mayor que el umbral del 51% que se necesita para que fuese una imposición por las malas.

También puedo argumentar que no es un impuesto nuevo, porque el impuesto ya existía, es decir, la recompensa que reciben hasta ahora los mineros por encontrar el bloque es un impuesto en forma de inflación (controlada, pero inflación al fin y al cabo) a todos los usuarios en posesión de BCH. Lo que cambia es en que se gasta dicho impuesto que a partir del IFP pasa a ser un 95% para el minero y un 5% para los proyectos de infraestructura que elige el minero agraciado.

2.       La siguiente critica tiene que ver con el hecho de que la recompensa vaya a parar a más de un destinatario. Si bien es verdad que hasta ahora lo más habitual es que toda la recompensa fuese a parar a una única cuenta, no es ni mucho menos la única opción, ya que por ejemplo el pool de minería completamente distribuido conocido como p2pool (con muchos años de operación a sus espaldas tanto en BTC como en BCH) reparte, proporcionalmente al trabajo aportado, la recompensa entre todos sus miembros y nadie ha acusado al proyecto p2pool.

3. Otra crítica al IFP es que la nueva distribución de las recompensas disminuye la seguridad de la red. Esta es una crítica válida, ya que en teoría los mineros aplicarán un 5% menos de sus recursos a asegurar frente a ataques de doble gasto la red de BCH. Lo que esta crítica no reconoce es que ese mismo argumento es válido para cada variación del precio de BCH, es decir si BCH sube un 5% frente a sus competidores con el mismo algoritmo, los recursos dedicados subirán el mismo 5% y viceversa. En mercados tan volátiles como el de las criptomonedas, una variación de un 5% momentánea después de sufrir otra variación momentánea previa del 50% (el halving) no es tan relevante, lo relevante es como se tome el mercado el IFP.

Criticas a Bitcoin ABC.

El siguiente grupo de críticas las he oído por parte de personas que no están inicialmente en contra del IPF en el fondo, pero si en las formas de cómo se lleva a cabo. En este caso las críticas se dirigen ya no tanto hacía el cartel de mineros impulsores de la propuesta sino hacía la implementación del IFP realizada por Bitcoin ABC (Adaptable Blocksize Cap) y en muchos casos contra la persona que lidera dicho grupo, Amaury Sechet. A modo de contexto, Amaury lleva mucho tiempo solicitando fondos para llevar adelante la hoja de ruta publicada. El cartel de mineros propulsor del IFP también lleva tiempo reconociendo que ellos tienen que pagar por el esfuerzo de los equipos de desarrollo ya que son beneficiarios directos de dicho trabajo. El problema que se planteaba es que, si los mineros optaban por las donaciones voluntarias, esto les debilitaba frente a sus competidores que optasen por no realizar donaciones en un entorno muy competitivo como es el de la minería de doble hash sha256. Por lo tanto, los mineros del cartel lanzan esta propuesta donde el principal beneficiario directo es el mismo ABC. Pero ojo, los mineros no quieren darle parte de sus ganancias a ABC, lo que quieren es invertir parte de sus ingresos para asegurar unas ganancias mayores en un futuro. Este cartel de mineros ha demostrado en ocasiones pasadas y con esta propuesta que se preocupan por el correcto desarrollo de BCH (que finalmente redundaría en su propio beneficio) y hay que sentirse orgullosos de contar con mineros con esa predisposición y entendimiento de la situación en el mundo de las criptomonedas.

1.       La nueva versión de bitcoin ABC 0.21.0 señaliza por defecto a favor del IFP. Es completamente cierto, pero en una votación que se rige por el BIP-9 el voto es emitido por el valor de un bit, que solo admite 0 o 1, que significan voto en contra o a favor. Un minero no puede abstenerse. Todas las implementaciones que no incluyan IFP van a votar con un no por defecto y además sin opción de cambiarlo. En la implementación de ABC por defecto van a votar que sí al IFP pero podrán optar a cambiar su voto con una opción de configuración (-enableMinerFund=0 creo recordar). Pedirle a ABC que implementase estar en contra del IFP en las opciones por defecto sería pedirle actuar en contra de sus propios intereses.

2.       ABC nos conduce a la activación del IFP que nos puede provocar un Split en BCH. En este argumento/crítica de nuevo volvemos a la práctica torticera de aludir a términos que generan rechazo inicial en el subconsciente, ya que nadie queremos pasar de nuevo por un Split como por desgracia sucedió con BSV en el pasado. Aunque es cierto que un Split puede aparecer, en todos los hard forks siempre aparecen splits fruto de mineros despistados que por ejemplo no han actualizado a tiempo su software, pero son splits con escaso recorrido en la comunidad. Voy a intentar demostrar porque este riesgo, que sí que existe, es muy pero que muy bajo.

Primero necesitamos un poco de contexto. Actualmente existen múltiples implementaciones de software de nodo cliente de BCH, la mayoritaria entre los mineros es ABC, mientras que en los nodos no mineros hay un posible empate entre el cliente ABC y el cliente BU (Bitcoin Unlimited), seguidos a mucha distancia por bchd que a día de hoy reconoce no ser apto para minería y Bitcoin Verde que le ocurre lo mismo que a bchd. Todas estas implementaciones no incorporan de momento nada de código referente al IFP, pero esto no es problemático porque no son usadas por los nodos mineros y el IFP si se aprueba será un SF (Soft Fork) que permite a los nodos no mineros seguir los bloques que los mineros con IFP generen en la cadena. A partir de esta polémica un grupo de desarrolladores ha decidido hacer un fork del código de la versión de ABC que incluye el IFP (la versión 0.21.0), denominado Bitcoin Cash Node (BCN en adelante), eliminando tanto el código de activación del IFP como el propio código de validación de bloques que incorpora IFP. El cliente de nodo BCN si aspira a ser ejecutado como nodo por parte de los mineros. Como ya dije antes los clientes que ejecuten este código van a votar en contra del IFP durante el proceso de aprobación del BIP9 y no podrán cambiar su voto, pero estoy de acuerdo en que el que elige este nodo ya sabe porque razón lo hace que es principalmente señalar su decidida repulsa al IFP. Durante varios periodos de tiempo de aproximadamente 2 semanas, los mineros votarán y si en alguna de esas votaciones se sobrepasa el valor de 2/3 a favor el IFP se considerará activado por parte de los clientes de nodo que ejecuten el software de ABC. Si finalmente se activa el IFP tras un periodo transitorio que se da de margen para que todos los nodos se actualicen a las nuevas reglas, las reglas del IFP se incorporan a las reglas de consenso que hasta ahora regían esa cadena de bloques.

Tras una activación del IFP tendremos 4 tipos de mineros, mineros que ejecutan el software de ABC y señalizaban a favor del IFP, mineros que ejecutan el software de ABC y señalizaban en contra del IFP, mineros que ejecutan el software de BCN y obviamente están en contra del IFP, y el último tipo lo reservo para los mineros que señalizaban cualquier cosa pero que cambian completamente de opinión.

Los mineros del tipo 1 se congratulan de que su elección haya sido adoptada y no tienen que hacer nada más. Los mineros del tipo 2 se lamentarán de que su elección no fuese finalmente elegida pero tampoco tienen que hacer nada para seguir minando bloques y quedarse con su recompensa. Los mineros del tipo 3 también se lamentarán de que su opción no ha sido elegida, pero tienen de tiempo el periodo transitorio de gracia para cambiar su nodo por el de ABC, ya que si no es así los bloques que generen con el software de BCN el resto de nodos los rechazará como inválidos. Los del grupo 4 en primer lugar espero que sean pocos, la decisión es muy importante y deberán de hacer los deberes desde el principio. Por supuesto todos podemos cambiar de opinión, pero si por ejemplo habíamos votado a favor del IFP y el IFP se activa, aunque hayamos cambiado de opinión debemos esperar al siguiente ciclo de hard forks programados para plantear la batalla de nuevo en ese punto y siempre dependerá del nuevo equilibrio de fuerzas.

En todos estos escenarios no se produce ningún split con el suficiente recorrido, tan solo como en todos los hard forks podrán aparecer algunos bloques de algún minero despistado del tipo 3 que no haya actualizado su software de nodo a ABC.

3.       Si que existe un riesgo de split si apareciese una implementación de software de nodo que expresamente identificase como inválidos los bloques que cumplen con la especificación del IFP. Esto se podría conseguir convirtiendo la whitelist de direcciones del IFP en una blacklist. Este tipo de software de nodo estaría diseñado desde un principio para provocar un split si el IFP es finalmente aprobado y como digo de momento no existe ninguna implementación que haga esto, pero ha llegado a mis oídos que esta practica está siendo considerada por muchos seguidores anti IFP. Esta practica sería tan sumamente torticera que espero y deseo no tuviese ningún eco en la comunidad, pero si finalmente aparece con respaldo y el IFP se aprueba el split es inevitable y en mi opinión esta nueva implementación sería la única responsable de dicho split.

Críticas a los que están en contra del IFP

Miembros de la comunidad de BCH, otrora muy respetados por mi parte, se han manifestado en contra del IFP. Su manifestación es completamente legítima, pero yo voy a exponer aquí algunas de las malas prácticas que utilizan en sus argumentos.

1.       El anónimo imaginary_username en su cuenta de twitter dice “I think a point needs to be made: The side implementing unwanted soft forks is the aggressor and instigator of any possible chain split. Never let anyone blame the defenders.” https://twitter.com/im_uname/status/1230421695845949440

Me gustaría que su autor explicase como se mide el grado de “unwanted”, si se mide por lo que el o los que opinan como el piensan tiene toda la razón, pero es muy común apoderarse del pensamiento de la mayoría de la comunidad. Es como cuando en una final de un partido de futbol las dos aficiones piensan que su equipo va a resultar ganador. Las opiniones son como el culo todos tenemos uno. Cuando su grupo de seguidores le aplauden sus declaraciones corre el riesgo de percibir que todo el mundo piensa igual que el.

En este caso además se puede ver como se responsabiliza a ABC de posibles splits futuros.

2.       La gran campaña de acoso y derribo en las redes sociales en contra del IFP tiene como objetivo que los mineros del cartel retiren su propuesta, como se pide en innumerables ocasiones, lo cual me recuerda a otra campaña parecida que he vivido en el pasado, la del #No2X que además consiguió su objetivo. Creo que yerran el tiro. Pero reconozco que aquí puedo equivocarme y que finalmente se salgan con la suya consiguiendo la retirada del IFP antes de la batalla de hash que supone el proceso de activación mediante el BIP9. Pueden para el IFP, pero tendrán que convencer a los mineros para que dediquen su potencia de hash votando en contra del IFP.

Desenlace final del IFP

Todo lo que resta del artículo sobre el recorrido del IFP son obviamente elucubraciones mías, pero quiero empezar resaltando que la toma de decisiones sobre que reglas de consenso rige una comunidad es un apartado perfectamente explicado en el whitepaper que Satoshi Nakamoto nos legó sobre Bitcoin. En ella se especifica que los conflictos se resuelven a través de la potencia de hash y no con las opiniones de personas en las redes sociales o con votos por direcciones IP ya que todos estos son manipulables.

En un ecosistema donde se nos llena la boca cuando hablamos de las ventajas de la descentralización, el estamento mas descentralizado es el de los mineros, donde todos ellos compiten entre sí, pero los incentivos les conminan a actuar conforme al bien para BCH y es en ellos y sus acciones donde recaen la toma de las decisiones más relevantes.

Como decía el resultado de la votación del proceso del BIP9 nadie puede adivinarlo, pero podemos intentar ver como está el marcador en cada momento con dos herramientas, una es la señalización propia del BIP9 y otra los bloques minados por cada pool de minería y las declaraciones de sus responsables sobre si están a favor o en contra.

La señalización la podremos seguir en la página https://cash.coin.dance/blocks en el apartado “Proposal activation spotlight” y su barra de progreso con la marca en el valor umbral. El problema actual con esa información es que todavía es demasiado temprano para que los mineros incorporen la última reléase de ABC (acaba de salir y tiene que pasar por muchas pruebas en la testnet), pero conforme avance el proceso será la información más fiable.

En esa misma página podemos ver que porcentaje de bloques han obtenido los diferentes pools en los últimos 7 días y con esta información, aplicándole las declaraciones de los responsables de cada pool, se puede hacer la cuenta de la vieja y obtener un resultado preliminar. En el momento de escribir este artículo tenemos de mayor a menor éxito los siguientes pools: AntPool 20,8%, BTC.top 18,9%, Huobi 16,9%, ViaBTC 10,9%, BTC.com 8,8%, SBI Crypto 2,9%, Bitcoin.com 2%, y un largo número de pools minoritarios además de un grupo de mineros anónimos.

Hasta ahora AntPool, BTC.top, ViaBTC y BTC.com han manifestado su apoyo explicito mediante declaraciones al IFP. Esto supone un porcentaje de votos a favor del 59.4 %.

Igualmente Bitcoin.com se ha manifestado en contra y que va a utilizar el nodo de BCN, lo que supone un porcentaje de votos en contra del 2%.

El resto de mineros no conozco su predisposición para la votación.

Otro elemento a tener muy en cuenta es que actualmente los mineros que minan en la cadena de BCH son aproximadamente el 4% del total de la potencia de hash disponible. Si los mineros que hasta ahora no han minado BCH deciden entrar a minar BCH aún a consta de pérdidas con el objetivo de modificar el resultado de las votaciones, el panorama se vuelve mucho mas complejo. Este tipo de actuaciones serán a favor del IFP si este no llega al valor umbral para favorecer las incertidumbres, o en contra del IFP si estos actores consideran que el IFP es bueno para BCH y malo para su cadena de bloques preferida. Estarían votando en contra del interés final de BCH, pero con un coste que estarían dispuestos a pagar, aunque dicho coste se incrementa cuantos mas votos consigan emitir. Esos sobrecostes durante un periodo tan prolongado como el de 16 días es nuestra única defensa frente a ellos.

Muchos lectores quieren un resumen final de que pasará con el precio de BCH y aquí os doy mis predicciones:

Si la presión consigue que el cartel de mineros retire la propuesta, el precio de BCH subirá en el corto plazo, ya que se verá como una victoria de la comunidad de las redes sociales frente a los mineros. El problema es que con eso no se resuelve el problema inicial, y muchos mineros de los que además se quedan parte de sus ganancias como inversión en BCH se sentirán decepcionados y perderán su ilusión por BCH, es decir, una señal clara para deshacer posiciones en BCH, quizás no todo, pero si dividir la posición de la cartera a la mitad.

El proceso del BIP9 para activación del IFP puede dar lugar a dos resultados, la activación o no. Si se consigue una activación con una amplia mayoría, muchos miembros de la comunidad han manifestado su intención de reducir sus posiciones, por lo que en un corto plazo podrá disminuir su precio, pero será justo el momento de acumular mas BCH en nuestra cartera cripto.

Si por el contrario en las sucesivas ventanas de tiempo no se va consiguiendo su activación ocurrirá como en el caso de la retirada de la propuesta.

Aunque estoy seguro que me he dejado muchas cosas en el tintero ya es demasiado largo y lo voy a finalizar aquí.

Actualización 1 (22/02/2020)

En primer lugar una corrección a un tema del articulo inexacto. Cuando digo que en una implementación como BCN los mineros que eligan esa opción no pueden modificar su voto a favor o en contra del IFP, esto es inexacto, ya que la votación se refleja en un bit que va en la estructura "nversion" del bloque, y muchos mineros tienen codigo personalizado para reflejar en esa estructura aspectos como "ASICBoost", luego con una pequeña modificación de dicho código personalizado también podrian señalizar en cualquier sentido.

En segundo lugar un tema que se me pasó por descuido y cansancio, que ciertamente recoge muchas de las críticas a la implementación de ABC, tal y como DarthRoibson refleja en su comentario. El tema es la implementación de la whitelist de direcciones a las que hacer los pagos. Este tema ha sido polémico desde el principio, ya que en la propuesta inicial el cartel de mineros queria que fuese a parar a manos de un fondo global / fundación y recibió muchas críticas precisamente por quien y como iba a controlar esos fondos. La implementación de ABC de la propuesta recoge tanto esa variante como el pago directo a direcciones controladas por los grupos de desarrollo. Establecer una whitelist aprobada por todos es una tarea ardúa y un proceso muy largo, deben establecerse criterios o principios, etc... El anuncio de la propuesta de ABC establece unos criterios que algunos pueden considerar vagos, pero no ha dado tiempo a avanzar en ello, sin duda es un tema en el que habrá que avanzar. Recientemente el mismo Amaury en una reunión de desarrolladores lanzó la idea de utilizar Avalanche para llegar a un consenso en una whitelist como una solución a futuro para este problema.

La elección de ABC para formar parte de esta whitelist es obvia, no necesita justificación, es la implementación que usan prácticamente la totalidad de los mineros.

La crítica más importante viene por la no inclusión en la lista de otros, principalmente BU. En mi opinión BU no debe estar en esa lista porque en primer lugar su software de cliente de nodo no es utilizado por los mineros, en segundo lugar su modelo de financiación es otro y no tiene necesidades, y en tercer lugar porque desde el primer momento se ha manifestado estar muy en contra del IFP.

La elección de BCHD puede ser mas criticable por no cumplir con la idea de que es usada por los mineros pero sus problemas de financiación son los mismos y su proyecto si trabaja en temas de infraestructura como el caso de la implementación de avalanche.

La elección de Electron Cash es criticada por Tobias Ruck en su artículo https://read.cash/@TobiasRuck/why-i-support-the-ifp-despite-the-community-seeming-to-hate-it-and-how-to-fix-it-d128e975. Su articulo está en la misma línea que este pero en ingles y su contenido es mucho mejor que este en la mayoria de los puntos por lo que recomiendo a todo el mundo su lectura. En esta ocasión difiero de la opinión de Tobias, y aunque el poryecto es mas conocido por su monedero electron cash (Tobias considera que no debe financiarse con el IFP proyectos de monederos), los componentes de ese grupo también han desarrollado muchos elementos de infraestructura que tienen un objetivo final de aumentar el uso y la adopción de BCH, como por ejemplo CashSuffle, CashFusion y Fulcrum, y por estos proyectos yo considero que los miembros de Electron Cash son unos candidatos a formar parte de la whitelist.