Tenemos BIP 148: UASF

[dserrano5]

Alguien ha cogido el BIP 148 propuesto por shaolinfry y ha hecho un fork (en el sentido de código fuente ) de bitcoin core implementándolo. En bitnodes se puede ver que ya hay unos cuantos nodos ejecutando este código. Ahora no sale pero antes había uno de Barcelona, gracias!!

Me he bajado el fuente de core y el de core+bip148:

Code:

$ git clone https://github.com/bitcoin/bitcoin.git bitcoin-core
Cloning into 'bitcoin-core'...
remote: Counting objects: 89168, done.
remote: Total 89168 (delta 0), reused 0 (delta 0), pack-reused 89167
Receiving objects: 100% (89168/89168), 78.18 MiB | 1.64 MiB/s, done.
Resolving deltas: 100% (66482/66482), done.
Checking connectivity... done.

$ git clone https://github.com/UASF/bitcoin.git bitcoin-UASF
Cloning into 'bitcoin-UASF'...
remote: Counting objects: 89176, done.
remote: Total 89176 (delta 0), reused 0 (delta 0), pack-reused 89175
Receiving objects: 100% (89176/89176), 78.18 MiB | 299.00 KiB/s, done.
Resolving deltas: 100% (66488/66488), done.
Checking connectivity... done.

Cambié a la rama 0.14 en ambos repositorios:

Code:

$ cd bitcoin-core
$ git checkout 0.14
Branch 0.14 set up to track remote branch 0.14 from origin.
Switched to a new branch '0.14'
$ cd ..

$ cd bitcoin-UASF
$ git checkout 0.14
Branch 0.14 set up to track remote branch 0.14 from origin.
Switched to a new branch '0.14'
$ cd ..

Comprobé las diferencias entre core y core+bip148:

Code:

$ diff -urpN bitcoin-core bitcoin-UASF
[blah blah cosas de git]
diff -urpN bitcoin-core/src/clientversion.cpp bitcoin-UASF/src/clientversion.cpp
--- bitcoin-core/src/clientversion.cpp  2017-03-26 00:33:00.222894462 +0000
+++ bitcoin-UASF/src/clientversion.cpp  2017-03-26 00:40:56.349650311 +0000
@@ -13,7 +13,7 @@
  * for both bitcoind and bitcoin-core, to make it harder for attackers to
  * target servers or GUI users specifically.
  */
-const std::string CLIENT_NAME("Satoshi");
+const std::string CLIENT_NAME("Satoshi BIP148");

 /**
  * Client version number
@@ -82,8 +82,8 @@ std::string FormatFullVersion()
     return CLIENT_BUILD;
 }

-/**
- * Format the subversion field according to BIP 14 spec (https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki)
+/**
+ * Format the subversion field according to BIP 14 spec (https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki)
  */
 std::string FormatSubVersion(const std::string& name, int nClientVersion, const std::vector<std::string>& comments)
 {
diff -urpN bitcoin-core/src/validation.cpp bitcoin-UASF/src/validation.cpp
--- bitcoin-core/src/validation.cpp     2017-03-26 00:40:49.453668289 +0000
+++ bitcoin-UASF/src/validation.cpp     2017-03-26 00:40:56.397650186 +0000
@@ -1851,6 +1851,13 @@ bool ConnectBlock(const CBlock& block, C
         flags |= SCRIPT_VERIFY_NULLDUMMY;
     }         

+    // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive
+    if (pindex->GetMedianTimePast() >= 1506816000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())
+      if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(chainparams.GetConsensus(), Consensus::D
+        return state.DoS(0, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
+      }                                                                                                          
+    } 
+      
     int64_t nTime2 = GetTimeMicros(); nTimeForks += nTime2 - nTime1;
     LogPrint("bench", "    - Fork checks: %.2fms [%.2fs]\n", 0.001 * (nTime2 - nTime1), nTimeForks * 0.000001);

Y a compilarrrrr:

Code:

$ cd bitcoin-UASF
$ ./autogen.sh
$ ./configure --without-miniupnpc --disable-wallet --without-gui
$ time make -j 3
$ file src/bitcoind
src/bitcoind: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=1a4233b81430d232090c7dd53895121064520914, not stripped

[Shawshank]

Interesante descripción paso a paso para quien quiera construir el cliente directamente desde código fuente. 

Sin embargo, no veo cómo UASF puede funcionar si tienes una potencia de hash importante que se opone a activarlo. Se pueden generar situaciones muy endiabladas en las que se va todo al garete y nadie gana.

El concepto fundamental debería ser, los soft forks necesitan el apoyo de los mineros; los hard forks necesitan el apoyo de la mayoría económica. El atractivo del soft fork es su compatibilidad hacia atrás, que es algo que se respeta en los grandes sistemas siempre que se puede: los programas de Windows 8 funcionan en Windows 10; los programas de 32 bits funcionan en sistemas de 64 bits; las direcciones IPv4 pueden interactuar con las IPv6...

Parte del impasse actual ocurre porque se intenta activar la opción de la mayoría económica (Segwit) con un soft fork (que requiere del apoyo de los mineros), mientras que la opción de una parte significativa de los mineros (Unlimited) necesita un hard fork (que requiere la mayoría económica).

Se me ocurre que UASF podría funcionar aunque no tengas la mayoría de los mineros a tu favor, solo en el caso de que no los tengas en contra. Es decir, algo así como que un porcentaje importante de los mineros no se preocupe por señalizar el apoyo a Segwit, y simplemente sabes que no te va a atacar en el proceso de puesta en marcha de UASF. Desgraciadamente, hay al menos un actor (Jihan Wu) que está mostrando una oposición clara, así que el UASF no lo veo.

Para terminar con un aporte optimista, creo que con el tiempo se irá haciendo cada vez más evidente que Segwit es la mejor solución para Bitcoin y que BTU no tiene futuro. Solo falta que Jihan Wu deje de obstaculizar la activación de Segwit y podamos empezar a ver un montón de nuevas aplicaciones para Bitcoin. 

[Leonyx]

Yo no soy el mas indicado para hablar de estos asuntos pero creo que si hay una oposicion en una parte a algo que es necesario empezaran ocurrir cosas como estas,en la que usuarios que no estan ni en un lado ni en otro empiecen hacer cosas por su cuenta,lo que esta bien si es para mejorar.

Haciendo un simil: Si se construye un presa en un rio y esta no deja pasar acabara desbordandose por el punto mas debil y el rio tomara su curso natural.

Gracias.

[dserrano5]

Interesante descripción paso a paso para quien quiera construir el cliente directamente desde código fuente. 

Sí porque binarios firmados por los sospechosos habituales, lo veo difícil, y que venga yo o cualquier otr@ a compartir su binario no es buena idea. Quizá juntándonos varios de nosotros, aprovechando que gitian nos aporta la posibilidad de crear el mismo binario…

Para terminar con un aporte optimista, creo que con el tiempo se irá haciendo cada vez más evidente que Segwit es la mejor solución para Bitcoin y que BTU no tiene futuro. Solo falta que Jihan Wu deje de obstaculizar la activación de Segwit y podamos empezar a ver un montón de nuevas aplicaciones para Bitcoin. 

En este sentido, montar un nodo BIP148 que anuncie al mundo que está ahí y que cuente en las estadísticas puede ser una herramienta política que contribuya a este fin. Estoy de acuerdo en que si llega octubre y no hay una posición de consenso clara, las cosas se pueden poner feas y ejecutar este parche puede que no sea la mejor opción (nadie lo sabe), pero ahora mismo esto supone riesgo cero y mandas un mensaje al mundo.


En otro orden de cosas, veo que no hay una cadena de búsqueda clara, hay que mirar en al menos dos sitios:

https://bitnodes.21.co/nodes/?q=UASF
https://bitnodes.21.co/nodes/?q=BIP148