AFIK, HMAC is needed only when you use a non self-authenticate symmetric encryption. For example, CTR mode must be used with external authentication (HMAC). But, in principle, CBC does not need HMAC (and so don't KDF, because the shared secret can be used as the single key).

Quenoquenoquenoquenoqueno..... que no tiene nada que ver. En 2009 no había ASIC, por tanto no podía tomar control. El "hashrate" depende de la tecnología accesible, pero la seguridad no tiene nada que ver con eso.

Relative to nothing or, if you want, relative to the level of 0 dB at the limit of human perception (actually 0 dB correspond to 20 micropascal of pressure amplitude)

Pero ese problema es independiente de la potencia de la red. Podemos estar tirando con tractores, que si el contrario viene con un tanque estamos perdidos.

Ese es el problema del 51% y está latente sea cual sea la potencia de la red.

No la hace más segura y no tiene ningún beneficio.

La red era igual de segura en 2009, con pocos MH/s de potencia, que ahora con casi 100 TH/s. Es una cuestión de escalas: con pocos nodos o poca potencia, la dificultad de generar un bloque es pequeña; con más potencia, la dificultad es mayor. Al final, se produce 1 bloque cada 10 minutos, que es el objetivo final y que se consigue con cualquier potencia de red.

Es como el juego de la cuerda. Dos personas tirando de ella la mantienen tensa; si una de ellas llama a un amigo, la otra también lo hará para evitar que el otro se lleve la cuerda. Si una engancha un burro, la otra también; o un tractor, o un camión...

La cuerda siempre está tensa y no cae al suelo. Pero da igual tener a dos personas que a dos tractores tirando para conseguir ese objetivo.

Hombre, yo es que ni me he molestado en señalar que cualquiera con un dispositivo conectado a una IP real puede ser minero. Ya daba por descontado que eso es evidente por sí mismo.

[/quote]


Yo entiendo que las empresas que reparten IPs su negocio es precisamente ese, el reparto de IPs. Si quieren seguir teniendo clientes tendrán que dejar esas IPs libres para ellos.

Por otra parte, tener un nodo activo con bitcoin no es tan "barato" como se piensa. El tráfico de datos es enorme. Yo tuve que desconectar mi nodo porque estaba dando un tráfico del orden de 100 Gb por día (y sólo de salida...) y amenazaba con comerse en pocos días todo el tráfico contratado para un mes. Un particular se lo puede permitir puesto que el nodo, aparte de minar, le ofrece el servicio de envío y recepción de monedas.

Bajo un punto de vista empresarial, es más rentable cobrar por el alquiler de esa IP que ponerse a minar uno mismo.

The answser is: yes, it is really hard searching something in these vBulletin, SMF, etc boards. But I've tried without success. That's why I kindly asked for links.


The "vote" is the confirms of the solved block. If the majority of power confirms its own blocks, the chain will fork.

If I'd have a huge farm of ASIC miners, I'd give away any hardfork that put my inversion into ruin.


I didn't mention sudden catastrophic blowups of the algorithm. Any analysis that shows slight departure from the Random Oracle model, in such a way that given the freedom of input, it is possible to construct hashes lower than target with tiny higher probability than random, is enough IMHO to move away from SHA256d.


I'd love to read these threads. I'll search more intensively...

¿"tenemos"? 

Creo que no sabes dónde te has metido... 

Everybody knows what ASIC is: a goal-driven device, hardware coded for a precise task; a small computer who runs a single program. This specialisation gives an extraordinary efficiency and velocity to the programmed task.

Also, everybody knows about a generation of ASIC chips programmed with the task SHA256d, that will arrive to bitcoin universe to process blocks with huge amount of hashes per second. The expectation of hashrate growth is ten times or more the actual HR. And, the most important fact, the biggest proportion of this HR will be held by ASIC chips. And this will happen in some months

If somebody didn't understand yet, I repeat: ASIC-chip knows to do only ONE task. It does not serve for other thing.

So, let's see the scenario of a vulnerability on the SHA256d algorithm. The traditional answer of the bitcoin community to this question is: a hardfork will replace SHA256d to other trustworthy algorithm. But, in the next months, this hardfork will be simply impossible, because ASiC-miners, who will have the HR-power, will dictate to continue with SHA256d, because otherwise they can't afford the new algorithm. And they will have the vote-power to do this. The blocks eventually generated by the hardforked clients will be orphaned from the main chain dictated by ASICs.

Comments, links and tips are welcome.

Hola javi618. Ya veo que vienes con perfil de inversor/trader/especulador "duro"

Mis consejos a lo mejor te suenan a chino, pero yo te aviso por si acaso.

Bitcoin es un sistema creado para eludir el problema de confiar en terceros y usar las matemáticas y la criptografía como sustitutos. Por tanto, cualquier paso que des por tener una cartera en una web implica una confianza en un tercero que nadie aquí te va a dar, salvo el típico "a mi me funciona". Es absurdo meterse en bitcoin, que elude el problema de la confianza, para después meterte como un pardillo a dar tus datos y tus claves privadas a una web.

Por tanto, consejo número 1: crea tu propia cartera local con el programa cliente -de código público y ampliamente auditado-, cifra tu cartera y haz copias cifradas en varios sitios por si te casca el disco duro. NO HAGAS cuentas en blockchain.info y servicios similares.

Lo mismo se aplica a los "exchangers". Allá tú dónde metes tu dinero. Pero, sobre todo, evita cuidadosamente a MtGox. Tienen un largo historial de cagadas estruendosas por ataques DDoS y otros ataques informáticos, y no invierten un duro en protección de su servidor. Si husmeas por los hilos en inglés verás un montón de quejas de gente que se ha quedado colgada, con su dinero retenido o directamente evaporado.

Bitcoin es un mecanismo de intercambio de mercancias por la red, un dinero para usarse como medio de intercambio. Ya sé que las teorías económicas dicen que todo sistema de intercambio alcanza valor por sí mismo, pero en mi opinión es demasiado pronto para bitcoin llegar a ese punto. Mientras que como herramienta de intercambio es una red perfectamente descentralizada, como herramienta de inversión y ahorro depende de unos pocos "exchangers" que son fácilmente atacables por DDoS, y cuya honestidad es un asunto de fe. Y yo soy ateo...

Yo es que no comparto las premisas de este "post". No creo en una "economía basada en bitcoin".

Lo que sí que creo es que bitcoin (o alguno de sus "fork") triunfará como método de pago en la red y que se impondrá a sistemas como PayPal.

Mejor. Cuantos más nodos, más resiliente la red como ya he dicho (y no me refiero exclusivamente al ataque del 50%, sino a DDoS y otras lindezas).


De nuevo, mejor que mejor. Como ya he dicho antes, la codicia va en beneficio de la red en este caso. No hay tal "deshonestidad".


Yo no lo veo así. El incentivo de una persona por participar en una criptomoneda es tener un medio de inversión/pago descentralizado y fuera del control de bancos centrales. Por eso se instala su "wallet" y su programa de generar y recibir pagos. Si, además, puede recibir unas monedillas por su tener su nodo corriendo buscando bloques, más incentivo aún. No entiendo muy bien esta objeción.


Porque aparte de energía se necesita talento de programador que yo no tengo. A falta de éste, creo que es mi deber invertir esa energía en contestar a los que contestan a mis hilos, aunque sólo sea por cortesía elemental.


A ver, que creo que hay algo no se ha entendido muy bien en mi propuesta. No se trata de aplicar la Justicia Universal (*), sino de evitar el consumo de energía estéril, la escalada de MH/s (que no aporta nada a bitcoin) y la incentivación a la recentralización, con un sistema que, como efecto secundario, incrementa la resiliencia de la red. No hay nada caritativo ni justiciero en mi propuesta (*). Por si acaso no ha quedado claro, me autocito (otra vez...):


Sí te concedo que con mi sistema se incentiva la creación de virus que infecten ordenadores zombies. Con el actual sistema basado en la potencia, un ordenador zombi es poco útil si no tiene una gráfica potente; pero con el que yo propongo esto no es necesario.

(*) Reconozco que como efecto secundario también buscaba un reparto más distribuido de las monedas generadas; pero de nuevo no por una causa justiciera, sino porque una distribución de monedas más dispersa promueve que la circulación de moneda sea más ágil y dinámica; pero no siempre se pueden ganar todos los puntos.

What about automatic earnings for not registered users!? I'm almost at 0,05 and no payment yet arrived, when limit is 0,01

Un desarrollo de tecnología absolutamente banal porque los ASIC no sirven para nada, excepto calcular SHA256d... y sospecho que ni eso; supongo que están optimizados para calcular SHA256d con 80 bytes de entrada y nada más.

Mientras que el mineo con GPU sí traía innovación porque todos podemos aprender a programar en paralelo con una GPU a partir de los desarrollos hechos para el mineo, para otras muchas cosas que no son el mineo. Con los ASIC llegamos a un callejón sin salida. De hecho, suponen un peligro latente para bitcoin: supongamos que mañana se descubre que SHA256d tiene una vulnerabilidad grave, de tal forma que eligiendo astutamente la entrada se consigan "targets" con más posibilidad. La solución obvia es cambiar la rutina de hash (por ejemplo, SHA3, recientemente elegido por el NIST) e implementarla en los nuevos clientes... pero... como ya hay una gran cantidad de dinero invertida en esos desarrollos, estos inversores (los mineros ASIC) no lo van a consentir; y como tienen la mayoría de la potencia de cálculo, mantendrán la cadena de bloques principal con SHA256d mientras que los bloques producidos por el nuevo cliente quedarán "huérfanos"... chungo, chungo.


Pero es que es más fácil que sea así ¿no te das cuenta? La condición base de toda red p2p es que nadie domine el 50% de los nodos. Esa es la condición de partida de bitcoin. Pero esa condición se ve sobrepasada por otra, que es que nadie domine el 50% de la potencia de cálculo. En la condición actual, es más fácil que alguien controle el 50% de la potencia de cálculo, que en cualquier red p2p alguien controle el 50% de nodos.


A ver LuisCar, sé realista: ¿cuántas direcciones posibles IPv4 existen? 2^32 ~ 4x10^9, o sea, 4000 millones. ¿Cuántos nodos hay conectados actualmente a bitcoin? Unos 1000 (información de blockchain.info), es decir, menos de una millonésima.

Suponiendo que un sistema como el que propongo se implante y promueva la creación masiva de nodos y que llegamos a 1 millón de nodos. Eso sigue siendo menos del 0.1% del total disponible.

Por lo tanto es lo de menos que haya un país que controle tanto o cuanto. Es más, tú mismo puedes ir mañana a alquilar un servidor dedicado cuya IP posiblemente sea de EEUU.
 

Uhmmm ¿qué es lo que no has entendido de mi exposición?  Porque yo sí te puedo confesar que no estoy seguro de entenderte.

A ver: la red actual con 80 TH/s y una dificultad de 10 millones es igual de segura que la red de hace dos años, con 80 GH/s y una dificultad de 10.000. Es una cuestión de escala. Mi propuesta va en el sentido de normalizar hacia abajo.

No sé si va por ahí tu objeción


Vale, estamos de acuerdo en que dejar el nonce a 16 bits no es suficiente.


De nuevo, es una cuestión de escala: una red funcionando a 1 MH/s puede producir 1 bloque cada 10 minutos si se regula la dificultad proporcionalmente. Da igual si los mineros se ven obligados a pausar o no. Para la tasa de creación de bloques es absolutamente irrelevante.

Pero para el ahorro energético y para la desincentivación a la centralización es mejor mi sistema.


Es que la "prueba de trabajo" sí me convence. Mi sistema no la obvia. En principio, aquel nodo que resuelva el bloque se lleva la recompensa. Igual que ahora.


Interesante reflexión Nubarius. Ahora sí que nos estamos entendiendo: tú ves una dificultad intrínseca, más allá de si es posible o no controlar el espacio "ExtraNonce" o el "coinbase". Como, por ejemplo, la identificación de las direcciones IP. Yo creo que sí es posible, más que nada porque los "peers" sólo se entienden con IPs. De hecho, en blockchain.info se encuentra abundante información acerca del nodo que genera cada bloque.

En cualquier caso, no estoy seguro 100% de tener razón, pero creo que la propia criptografía puede proporcionar un sistema de evitar la falsificación. La salida del "poder computacional" es sencilla, pero nos arrastra a una escalada inútil y perjudicial (por el gasto energético y la recentralización) que es posible que se le escapara al poder visionario de Satoshi Nakamoto.

Me cito a mi mismo:


Es decir, que ya lo sé. Por eso he añadido:

Eso no es verdad.

La red es más segura con más nodos, no necesariamente con más potencia de cálculo.

Es que creo que no has entendido bien la propuesta: cualquiera que llegue a 65 kH/s ha alcanzado la máxima eficiencia. Repito: Cualquiera que llegue a 65 kH/s ha alcanzado la máxima eficiencia. Fin del problema. No tienen sentido los ASIC ni nada de eso.


Pero es que eso no es un inconveniente, sino una ventaja. Mayor número de nodos implica una red más resistente. Repito que la codicia rema a favor de la robustez de la red.

El mecanismo que me falta por explicar implica que la red ve a cada IP como un único nodo; los equipos tras una NAT salen con la misma IP, por tanto son el mismo nodo; no serviría tener cientos de ordenadores tras una NAT, sino con una IP directa a internet. Habría que contratar servidores dedicados con su propia IP. Y eso es caro.

Habrá gente que se pueda permitir tal dispendio, pero dudo mucho que sea más fácil conseguir superioridad así, que con el sistema actual a base de invertir en GH/s.


Je, je... eso se soluciona con lo que aún no he explicado. Pero demuestra que le das a la cabeza y que has reflexionado sobre el asunto. Muchas gracias.

Eso ya lo veremos 

Aparte de eso... ¿alguna otra debilidad?

Voilá!

https://bitcointalk.org/index.php?topic=188972.0

En otro hilo he expresado mi opinión de que bitcoin tiene un problema de diseño en la generación de bloques mediante la "prueba de trabajo". Este problema se manifiesta con dos síntomas:

• La absurda carrera a ninguna parte de la potencia de cálculo, que ahora experimenta un repunte importante con los ASIC: es como el juego de la cuerda, con dos equipos tirando de ella; de repente uno ata un burro y parece que va a ganar, hasta que el otro equipo ata otro burro; después un caballo, después un tractor, después un camión... y ambos equipos siguen exactamente donde estaban al principio, pero habiendo invertido estérilmente en todos esos recursos. Pues bien:  ¿en qué beneficia esa carrera a bitcoin? ¿acaso es más seguro con más potencia de cálculo? ¿Para qué gastar tanta energía y recursos tontamente?
• Favorece la creación de "pools" centralizados, rompiendo el carácter distribuido de la red. Eso no sólo no ayuda al proyecto, sino que lo perjudica gravemente

Ante esta situación hay una solución relativamente sencilla de haberse pensado antes, porque ahora es imposible introducirla en el protocolo de bitcoin. Aquí la dejo, por si alguien la considera para la creación de una nueva criptomoneda.

La prueba de trabajo consiste en "hashear" la cabecera del bloque y ver si el resultado, interpretado como un número, está por debajo de un cierto valor objetivo ("target"), que es tanto más pequeño cuando mayor es la dificultad. Si es así, el nodo emite el bloque y los demás pueden probar fácilmente que es válido "hasheando" la cabecera.

Si no tiene éxito en este proceso, el nodo puede modificar un parámetro de la cabecera del bloque que es como una especie de contador (en el argot anglosajón: "nonce"); lo incrementa y vuelve a "hashear" y comprobar con el objetivo. Lo normal es empezar con el contador a 0 e ir subiendo hasta que el contador se "desborda". Es decir, suponed que el contador admite sólo 4 cifras decimales; pues empezando en 0 tenemos 10.000 oportunidades de probar (hasta el 9999) antes de que se desborde.

Si hemos llegado sin éxito al punto en que el contador se desborda, no tiene sentido empezar desde 0 otra vez, porque ya sabemos que no vamos a conseguir nada. Hay que modificar otro parámetro de la cabecera, puesto que sabemos que las funciones "hash" son muy sensibles a un cambio nimio. Hay otros dos parámetros que se pueden cambiar: el "hash" de las transacciones (hablaré de esto más tarde) y otro contador, que se incrementa en 1 con cada segundo que pasa y que, en principio, es más rápido que el anterior.

Por tanto, despues de nuestros 10.000 intentos, esperamos 1 segundo y volvemos a intentarlo. El problema es que no es necesario esperar... ¡porque no nos da tiempo a desbordar el contador real, que contiene 32 cifras binarias! Y 32 cifras binarias supone la friolera de probar 2^32 = 4x10^9 hashes antes de que el contador de tiempo se incremente. Es decir, tendríamos que tener una potencia de cálculo de 4 GH/s para desbordar el contador "nonce" antes de que se incremente el contador temporal. Esto favorece repartir el trabajo en "mineros", asignando a cada uno una porción del "nonce".

Pues bien, mi propuesta es rebajar el "nonce" a 16 bits, que es equivalente a 2^16 = 65.536 hashes. Por tanto, con una potencia mínima de 65 kH/s, fácilmente conseguible incluso con CPUs, cada nodo puede desbordar su "nonce" y esperar a que el contador de tiempo se incremente. Salvo que sea muy impaciente (que lo será, si hay BTCs de recompensa de por medio) y decida manipular la otra parte de la cabecera que es manipulable: el "hash" de las transacciones; en particular, la transacción de generación, que es tremendamente voluble y cuya manipulación altera la cabecera del bloque a discreción.

Efectivamente, habría que cambiar también la forma en que se construye la transacción de generación, pero ahora no quiero extenderme más. Simplemente supongamos por ahora que esto también se puede controlar y veamos las implicaciones.

Al no poder forzar la creación de hashes, cada nodo entra en una especie de lotería en que todos tienen el mismo número de boletos y las recompensas se van repartiendo al azar entre todos. El poder de cálculo de la red es simplemente 65 * (número_de_nodos) kH/s. Y, lo que es más importante, no tiene sentido la minería en "pools", puesto que cada nodo puede cumplir por sí mismo la máxima tasa de minado eficiente.

Por supuesto, la dificultad base tiene que ser inferior a la actual. La podemos calcular de forma que un nodo solitario, trabajando a 65 kH/s, tarde un promedio de 10 minutos en generar un bloque. Esto es: 2^16 * 600 ~ 2^25 (en lugar de 2^32 como es ahora). La dificultad de generar un nodo se calcularía como ahora, de forma que toda la red genere en promedio un bloque cada 10 minutos; y ese número sería muy parecido al número de nodos conectados. Si hay 1000 nodos la dificultad es ~1000, si hay 1 millón, ~1 millón.

Aún así, los usuarios pueden hacer "trampas". Supongamos que un tipo quiere multiplicar sus ganancias y se dedica a instalar nodos, contratando servidores dedicados y/o usando todos los ordenadores a los que tiene acceso como nodos. ¡Esta persona multiplicaría sus posibilidades de recompensa! Sí, pero a costa de incrementar la robustez de la red, haciéndola más resiliente con más nodos. Es decir, la codicia de los usuarios rema a favor de los intereses de la red.

Y, por último, la red sería también más robusta que la actual, puesto que para controlar el 51% de la potencia de cálculo habría que controlar el 51% de nodos.

¿Qué os parece?