Dada la hostilidad de algunos a las pruebas...
lol  

Abro mi propio hilo, en éste hilo vamos a esperar el hash de información privilegiada que amablemente le pedimos a ToniPaz. Si nos quedamos esperando cada uno sacará sus propias conclusiones. El hash comprobado y sin ambigüedades es una prueba irrefutable, mi intención no es seguir la polémica, es mas bien darle la oportunidad a ToniPaz de terminar con ella de forma decente, y así dar paso a una discusión seria en donde podamos considerar esas posibilidades como algo factible a mediano plazo.

Me refiero a uno de los usos de las direcciones multifirma, para hacer un gasto sobre una dirección con multifirma se necesita de múltiples llaves privadas para que firmen esa transacción, o sea se necesita de la aprobación de dos o más personas para hacer un gasto, ésta funcionalidad puede ser usada para sistemas de escrow, por ejemplo:

Bob quiere vender a Alice 1 BTC por 100 LTC, Bob y el escrow crean una dirección multifirma y Bob envía 1BTC a esa dirección, Alice y el escrow crean una dirección multifirma y Alice envía 100 LTC a esa dirección, luego Bob firma una transacción que envía 1 BTC desde la dirección multifirma a la dirección personal de Alice, Alice a su vez firma una transacción que envía 100 LTC desde la dirección multifirma a la dirección personal de Bob, cuando el escrow vea que todo es correcto firma las transacciones y todos quedan contentos. El meollo del asunto es que el escrow nunca tubo la capacidad de po sí solo robar a alguien, pues sin las firmas de Bob y Alice no se pueden hacer transacciones sobre los fondos depositados en escrow.

Lo que propongo es automatizar el proceso para crear un exchange que funcione parecido a los exchanges tradicionales como cryptsy o mintpal, pero sin todos los riesgos que implica la centralización de los depósitos en las manos de personas que podrían no ser las más competentes, ni las más sinceras, ni las más transparentes.

A eso me refería con el desarrollo de otras soluciones similares, obviamente bitcoin no es la panacea para el crimen, estoy hablando de un futuro a largo plazo, donde la tecnología sea capaz de evitar incluso la situación que planteas de forma intrínseca  ... no quería especular hasta ese punto por que no viene mucho al tema pues me refiero a algo que trasciende lo que es Bitcoin, pues no veo un "fin de la historia" con el sólo hecho de implementar bitcoin como moneda...

Esto es sólo un ejemplo: la nanotecnología en algún punto permitirá construir robots modulares que sean capaces de tomar la forma de cualquier objeto o mecanismo a nivel macro, imagina un futuro en el que todas tus posesiones se componen de esos pequeños robots, desde las paredes y los techos de tu casa hasta el objeto más trivial dentro de ella, si añadimos a esos robots una restricción por hardware en la que sólo puedan responder al dueño de una clave privada, no tendría ningún sentido el robo de ninguna de tus posesiones, pues el ladrón no podría hacer nada con esos robots sin la clave privada. Si una característica agregada a estos robots es la conexión obligatoria a una red global para que sean funcionales, una clave de recuperación o desactivación remota mediante otros sistemas de comprobación de tu identidad podría inhibir remotamente los robots en caso de que con una pistola en la cabeza hayas tenido que revelar la llave privada. Un sistema similar a éste es a lo que me refiero, agregar intrínsecamente las restricciones correctas para hacer 'imposibles' o inviables las cosas que no quiero que sucedan en un futuro, en vez de pagarle a un policía o a un estado para que disuada al resto de la sociedad mediante la fuerza.

De hecho, ese sistema de pequeños robots podría evolucionar a un sistema de protección personal, en el que tengas un espacio personal dado y puedas restringir la entrada a tu espacio a sólo las personas que tu desees, como una barrera protectora, así, si tu casa o lugar de trabajo es invadido por sujetos hostiles, podrías estar seguro de que la situación "pistola en la cabeza" no se podrá dar. Por otro lado, si implantas una malla de esos robots en tu epidermis, podrás estar seguro que aún en esa situación la bala no pasará a tu cabeza. Eso es un sistema intrínsecamente seguro, que cambiará el futuro haciendo el crimen cosa del pasado.

Si asumimos que una tecnología así es omnipresente y universal, estaríamos en un mundo en donde las leyes serán cada vez más inútiles, y las fuerzas e infraestructura del estado para garantizar esos derechos y restricciones será cada vez menos necesaria, pues los sistemas se podrían encargar de la aplicación de esas restricciones sin intervención externa. De hecho, si una tecnología similar es omnipresente, resulta cuestionable que yo tenga motivos para desear los pequeños robots que tiene el vecino, pues los míos tendrán la capacidad de satisfacer mis necesidades... ese para mi sería ese "fin de la historia".

Lo que acabo de describir es sólo un ejemplo, algo de especulación, y sueños, no digo que ese sea necesariamente el futuro, sólo digo que la tecnología en un futuro permitirá que este tipo de sistemas reemplacen a la política de prevención mediante el miedo al castigo, y el castigo mediante la violencia que impera en nuestras sociedades para supuestamente mantener un orden social adecuado. No me imagino qué tipo de tecnología podrían en realidad surgir, pero para mi es claro que ese es el camino, la estrategia de una restricción que garantice mi integridad será lo que reemplace paulatinamente a la estrategia que ha fracasado durante milenios: basar el orden social en la intimidación de los individuos y el castigo a los que hacen el daño (muchas veces el castigo de hecho es inútil si el daño es irreparable, lo que tiene en realidad sentido es restringir el sistema para que esas cosas nunca sucedan).

Veo a Bitcoin como un paso hacia esa dirección, por eso me gusta tanto...

Me pregunto por qué no hay un proyecto similar, tomando en cuenta todas las desventajas de las exchanges centralizadas, no veo razones para que el escrow multifirma no pueda ser usado para exchanges descentralizados de pares de criptomonedas. El principal obstáculo de los proyectos de exchanges decentralizadas es el FIAT, pero tratándose de pares de criptomonedas no veo inconvenientes insuperables, la tecnología está disponible, muchos de los hijos de Bitcoin son compatibles con el sistema multisign... ¿por qué no hay proyectos de exchanges de criptomonedas decentralizados basados en el escrow multifirma?.

Si nadie aquí me disuade comenzaré un proyecto el cual iré especificando aquí, en el que la comunidad estará invitada a participar en su desarrollo, tanto en la codificación como en discusiones técnicas y discusiones de forma y de fondo...

[Idea][Propuesta] Proyecto Exchange P2P de Criptomonedas (en busca de comentarios)

¿Por qué es importante?

Ya sabemos todos los inconvenientes que hay en el esquema de exchanges centralizadas que rige actualmente:

• Reserva fraccionaria.
  
• Robos.
  
• Auto-robos de administradores corruptos.
  
• Desastres por negligencia o ineptitud de los administradores.
  
• Posible manipulación del precio con monedas que no le pertenecen a los administradores.
  
• Posible manipulación del precio con monedas inexistentes pues no existe una prueba de reserva que respalde las monedas tranzadas en la exchange.
  
• El dueño del exchange puede decidir arbitrariamente las monedas que quiere incluir, éste poder se presta para tener ventajas en el mercado usando información privilegiada.
  
• En muchos casos comunidades bien intencionadas que realmente trabajan por sus monedas no tienen un exchange decente en dónde tranzar simplemente por que no han podido llamar la atención de los dueños de los 4 o 5 exchanges dominantes, todos deberían tener el derecho de intercambiar sus monedas sin restricciones y sin pedirle permiso a nadie, regidos totalmente por la oferta y la demanda...
  
• Usar criptomonedas y al mismo tiempo centralizar los depósitos confiando el control de nuestras monedas a una persona que ni siquiera conocemos es una estupidez y un total despropósito, algo totalmente contrario a la filosofía intrínseca de todo esto.
  

En fin... me parece un problema importante que tendremos que resolver tarde o temprano si queremos seguir avanzando.

No sólo debemos resolverlo por el bien de las monedas alternativas, un saludable intercambio de criptomonedas también ayudará a Bitcoin, a pesar del montón de monedas basura que salen todos los días creo que las altcoins son una parte importante del sistema, las altcoins son más susceptibles a la experimentación que el consolidado sistema Bitcoin, entre más grande sea Bitcoin éste tenderá a resistirse más al cambio, el ecosistema altcoin es un sandbox que Bitcoin necesita para probar conceptos, estrategias, experiencias e innovaciones. En las altcoins está parte del futuro de las nuevas características de Bitcoin y de la cadena de bloques, todos sabemos que Bitcoin está muy lejos de estar terminado, y la cadena de bloques aún no ha desatado la gran mayoría de todo su potencial, Bitcoin ya tiene una enorme utilidad para la humanidad pero todo esto aún está en pañales. Bitcoin convivirá siempre con nuevas alternativas, se tendrá que acoger a las innovaciones realmente útiles, o tendrá que aprender a convivir con ellas hombro a hombro pues las altcoins ofrecerán algunas utilidades y explorarán algunos aspectos que Bitcoin no necesita o no le interesa abarcar, el punto es que las buenas altcoins son y serán una fuente de propuestas novedosas, arriesgadas e irreverentes, cuyos fracasos no tendrá que asumir Bitcoin, y de cuyos éxitos se tendrá que realimentar...


Objetivo:

Desarrollar una solución para un exchange P2P de criptomonedas con las siguientes características:
- Prueba de reserva irrefutable. Se debe poder probar la reserva de los depósitos, ésta prueba de reserva no debe ser realizada por una entidad o persona, pues toda entidad o persona es susceptible de ser corrompida, debe ser una prueba irrefutable. Esto previene la reserva fraccionaria y la manipulación del precio con monedas inexistentes.
- El poder sobre las monedas depositadas nunca debe estar en manos del administrador del servidor de la exchange. Todo administrador es susceptible de ser corrompido, evitar esto previene el tener que confiar en la integridad de un desconocido para poder negociar, el usuario podrá evitar ese estado de incertidumbre permanente; previene auto-robos, también previene los robos (no será suficiente el "hackeo" de un servidor para hacer un robo masivo), previene desastres por negligencia o ineptitud, y previene la manipulación del precio por parte de los administradores usando las monedas de los usuarios.
- Debe funcionar con cualquier moneda. No importa lo populares o desconocidas que sean las monedas, todos deben tener el derecho de tranzar si existe la oferta y demanda adecuada. Esto previene las arbitrariedades en la inclusión de monedas en las exchanges, y da vía libre a las comunidades cuyo trabajo no se ve reflejado en su inclusión en las exchanges centralizadas dominantes.

Nota: por ahora sólo estoy concentrado en el intercambio entre pares de criptomonedas, el FIAT no tiene nada que ver aquí, para el cambio descentralizado de FIAT por ahora está localbitcoins, y están avanzando algunas alternativas como el proyecto Coinffeine[1] y otros similares.

Aún no sé si es una solución completa, y no sé si hay algo que no he tenido en cuenta que pueda tumbar todo el proyecto pues no he comenzado a experimentar. En esto de las criptomonedas y todos sus aspectos técnicos siempre queda algo por aprender, no estoy del todo seguro, por lo que también pensé en pedir ayuda a la comunidad para ver si ven algo que nosotros no, escuchar opiniones, sugerencias y demás colaboración... creo que si lo resolvemos entre todos le quitaremos a la comunidad una gran amenaza de encima.


El Concepto:

Principalmente se basa en la funcionalidad de las direcciones multisig (también llamadas nrequired-to-sign, dadas por el comando addmultisigaddress en los clientes basados en Bitcoin), permite crear una dirección multisig en base a dos o mas direcciones 'normales', la validez de las transacciones desde esa dirección multisig depende de las firmas con las llaves privadas de las direcciones normales asociadas; con "direcciones normales" me refiero a las que usamos habitualmente, en Bitcoin comienzan con el caracter '1', las direcciones "multisig" se diferencian de las direcciones normales en Bitcoin por que comienzan con el caracter '3'. Por ejemplo, una dirección nrequired-to-sign 2-of-2 fue creada a partir de dos direcciones normales, y las transacciones desde esa dirección necesitan ser firmadas con las 2 llaves privadas asociadas a las 2 llaves públicas (direcciones normales) con que se creó esa dirección; una transacción desde una dirección nrequired-to-sign 2-of-3 requiere de dos firmas con 2 llaves privadas de las 3 llaves públicas que se usaron para crear esa dirección.

La dirección multisig es indispensable para el funcionamiento de ésta propuesta, por lo que el único filtro sobre las monedas incluidas será la condición de que la moneda soporte ésta característica, no debería ser un problema para las monedas basadas en Bitcoin, pues esto se incluyó hace bastante tiempo en el core (Bitcoin 0.7, lanzado oficialmente en septiembre de 2012), aunque habría que revisar qué tan difundido realmente está el soporte de éste comando, por ahora he confirmado que Litecoin, Doge y PPC lo tienen implementado, espero que ésta implementación haya sido heredada a sus hijos. Si no está implementado, la comunidad de cada moneda tendría que presionar a sus desarrolladores para que el soporte multisig se incluya, pues independiente de la inclusión en éste exchange, esta es una característica importante que va a dar mucho de que hablar en un futuro, ya hay servicios como por ejemplo GreenAddress[2] que se basan en esta característica, y habrán en el futuro muchos mas servicios que utilizarán y se basarán en direcciones multisig[3]. Además, supongo que implementarla no requerirá de mucho trabajo teniendo como referencia su implementación en las principales monedas, y es algo que muchas altcoin tendrán hacer tarde o temprano si en realidad tienen alguna perspectiva de futuro.

Como ya dije, hay que revisar el tema para confirmar, puede que en realidad su implementación sí esté bien difundida y no haya ningún problema en monedas basadas en Bitcoin, sin embargo sí podría ser problemático para otras monedas no basadas en Bitcoin (como NXT) si no tienen algo equivalente en su protocolo. Parece que los de NXT siguen trabajando en el multisig o su equivalente[4] (la verdad no he estado muy pendiente de NXT, habría que consultar cómo va el tema).

En realidad el método no es nada nuevo[5], no es más que un intercambio con escrow usando multisign[6], un resumen del proceso habitual de escrow podría ser así:

0) Alice quiere comprar un producto a Bob.
1) Alice, Bob y el escrow generan una dirección Bitcoin y la comparten.
2) Se crea la dirección multisig 2-of-3 en base a las 3 direcciones.
3) Alice envía las monedas necesarias a la dirección multisig.
4) Bob envía el producto a Alice.
5) Bob pide al escrow el retiro de las monedas firmando una transacción desde la dirección multisig a su dirección personal y enviando la transacción firmada al escrow.
5) Si Alice no presenta reclamaciones sobre la entrega, el escrow también firma la transacción y la envía a la red, completando así el pago a Bob.

De ésta forma, el escrow nunca tiene el poder absoluto de gastar las monedas, si Alice no está conforme con la entrega del producto podrá presentar las pruebas en una reclamación al escrow, y si la reclamación se resuelve a su favor las monedas podrán regresar a Alice (con la firma de Alice y el escrow). Si Bob gana el pleito las monedas se enviarán a Bob (con la firma de Bob y el escrow); si ocurre otra eventualidad como la desaparición del escrow, Alice y Bob podrán por sí mismos firmar el retiro de las monedas sin la intervención del escrow.

El escrow con multisig ya ha sido aprovechado por servicios de escrow como Bitrated[7], pero estos son servicios personalizados de resolución de reclamaciones, lo que propongo es masificar y automatizar los intercambios limitándolos a pares de criptomonedas en una exchange multiusuario en tiempo real.

Ejemplo 0: Una transacción entre un par de monedas con escrow multisign.

1) Bob hace una oferta en una plataforma pública de ofertas, quiere intercambiar 0.8 bitcoins por 80 litecoins.
2) Alice quiere aceptar la oferta de Bob, Alice avisa al sistema sobre su intención de aceptarla, un escrow de la plataforma toma su lugar.
3) Alice, Bob y el escrow crean una dirección Bitcoin multifirma 2-of-3.
4) Alice, Bob y el escrow crean una dirección Litecoin multifirma 2-of-3.
5) Alice deposita 80 litecoins en la dirección multifirma.
6) Bob deposita 0.8 bitcoin en la dirección multifirma.
7) El escrow espera a las confirmaciones necesarias (tanto en Litecoin como en Bitcoin).
Con las firmas del escrow y Alice retiran los 0.8 bitcoins de la dirección multifirma hacia una dirección personal de Alice.
9) Con las firmas del scrow y Bob retiran los 80 litecoins de la dirección multifirma hacia una dirección personal de Bob.

El escrow nunca tuvo la oportunidad de robar los depósitos.
Bob nunca tuvo la oportunidad de robar a Alice.
Alice nunca tuvo la oportunidad de robar a Bob.
Es sistema falla sólo si el escrow y uno de los involucrados están aliados y tienen intención de robar a la contraparte.

El fallo del sistema se disminuiría con una "división" del intercambio, por ejemplo, intercambiar 10 litecoins por 0.1 bitcoins a la vez, el intercambio completo durará más (pues serán necesarios 8 intercambios), pero se minimiza el riesgo de traición. Si la plataforma pública de ofertas incluye un sistema de reputación de escrows, el intercambio podría funcionar masivamente y automáticamente, sin que el escrow necesariamente tenga que ser avalado por la plataforma, y sin que Bob ni Alice tengan que conocer o depositar excesiva confianza sobre el escrow y su contraparte.


Sistema Multiescrow

Recordemos que esta solución pretende evitar que el usuario tanga la obligación de confiar en la integridad del administrador de un exchange centralizado, pues es un punto de incertidumbre que queremos eliminar, si las transacciones en el sistema usan siempre un escrow proveído por la misma administración de la plataforma se corre un riesgo importante: la posibilidad de que un administrador con acceso a las llaves privadas del servidor sea corrupto, y que por ejemplo se haga de la llave privada de Bob con de la complicidad de éste, (de hecho no se necesita de la colaboración de un usuario en el fraude, un administrador se puede hacer pasar por un usuario de la plataforma, osea tomar el lugar de Bob para engañar a Alice), en el momento de crear los depósitos de bitcoins y litecoins el administrador tendrá en su poder las dos llaves privadas necesarias para hacer gastos sobre esos depósitos.

Un ataque de ésta naturaleza tiene ciertas limitaciones, sería difícil causar un daño masivo pues el golpe estaría limitado a los depósitos hechos en el periodo de tiempo entre la corrupción del administrador y el descubrimiento del fraude, puede ser un daño importante pero es reducido en comparación a robos masivos en exchanges con depósito centralizado, por otro lado el administrador estaría actuando en contra de su negocio, una vez ejecutado el robo la confianza en la plataforma se iría al suelo acabando con el negocio. Pero a pesar de estos inconvenientes para el administrador atacante no podemos ignorar el problema, pues no sólo un administrador corrupto puede ejecutarlo, un "hacker" podría tener acceso a las llaves privadas del servidor dado que están almacenadas de forma centralizada, un "hacker" tendría todas las de ganar aún si no consigue una cantidad significativa de depósitos, y tampoco le importaría la reputación de la plataforma, el "hacker" es otro riesgo que nos regresa a uno de los problemas que queríamos resolver: el desastre por posible negligencia o incompetencia de los administradores. Para hallar una solución debemos "complicar" el sistema un poco.

Se debería garantizar que el escrow nunca tiene contacto con la segunda llave de ningún depósito en una dirección 2-of-3, pero al mismo tiempo es imposible garantizar a los usuarios que un administrador (o un "hacker") no está actuando como un usuario solapado en la exchange.

Supongamos que existen tres escrows y no uno (tres servidores), administrados por tres personas distintas en lugares distintos del planeta, si cada dirección de depósito se crea con la firma del usuario depositante y estos tres servidores, la dirección de depósito podría ser una dirección multifirma 3-of-4, osea, cada gasto sobre el depósito deberá ser firmado por el usuario dueño del depósito y 2 de los 3 servidores que crearon la dirección multifirma, osea, la mitad más uno de los servidores. Ahora supongamos que hay 9 servidores distintos, en lugares distintos del planeta, los depósitos podrían ser en direcciones multifirma 6-of-9, osea, para hacer un gasto sobre un depósito se necesitará de la firma de 5 servidores y del usuario dueño del depósito. Así, se crea un sistema de consenso, el depósito sólo se podrá gastar de forma fraudulenta si colaboran en el fraude la mitad más uno de los servidores creadores de la dirección multifirma. Esto hace muchísimo más difícil ejecutar un robo como el descrito anteriormente, pues aunque un servidor se disfrace de comprador se necesitará la aprobación de otros 5 servidores para hacer cualquier cosa sobre el depósito, también se mitiga el peligro de que un daño irreversible en un servidor o un ataque de denegación de servicio pueda traumatizar el funcionamiento de la exchange, podrían estar fuera de línea 1, o 2, o 3 o hasta 4 servidores y el sistema no sufriría ningún inconveniente pues aún se podrían recaudar las 6 firmas necesarias para hacer cualquier cosa sobre los depósitos, creando redundancia y robustez sobre la plataforma.

Si hay por ejemplo 9 servidores resultaría incluso cuestionable la necesidad de dejar una llave en manos del usuario, pues ya prácticamente todo depende de los servidores (el usuario posee solo un décimo del control del depósito), todo podría funcionar con direcciones multifirma 5-of-9 entre servidores, poca seguridad se gana agregando al sistema la llave en manos del usuario, la única ventaja de hacer al usuario partícipe de la creación de la dirección del depósito y de la firma de los gastos sería la de generar una percepción mayor de control del usuario sobre las transacciones de sus depósitos, pero en términos cuantitativos la ganancia real en seguridad es poca considerando la complejidad que añade al sistema en los intercambios. Quitarle la llave de las manos al usuario también abre nuevas posibilidades a la plataforma:

• El depósito se hace previo a la transacción. Es decir, Bob hará una oferta de vender 0.8 bitcoins por 80 litecoins sólo cuando ya existan depósitos de Bob que sumen 0.8 bitcoins en direcciones multifirma creadas por los servidores, así mismo Alice no podrá aceptar toda la oferta de Bob hasta que haya depositado previamente los 80 litecoins en direcciones multifirma creadas por los servidores. Esto evita la posibilidad de que Bob haga ofertas sobre monedas inexistentes, y evita que Alice acepte ofertas sin tener el respaldo adecuado (peligros que existían en el sistema descrito en el Ejemplo 0).
  
• También brinda la posibilidad de que Alice acepte sólo una fracción de la oferta de Bob, y así Bob podría vender sus bitcoins a uno o varios usuarios depositantes de litecoins.
  
• El usuario ya no tiene que estar en línea para hacer un intercambio sobre su oferta. Es decir, dado que los depósitos se hacen previamente a la transacción, y los gastos sobre los depósitos sólo dependen de las firmas de los servidores creadores de las direcciones multifirma, Bob no tendrá que estar en línea para firmar un intercambio sobre el depósito que respalda su oferta, Bob creará la oferta de 0.8 bitcoins por 80 litecoins y podrá salir de la plataforma, y apagar su computador, regresará a la plataforma cuando quiera comprobar si su oferta ha sido tomada o para cancelarla o hacer algún cambio sobre su oferta. Alice aceptará la oferta solicitando el intercambio a los servidores que firmaron las direcciones de los depósitos, y todo se completaría sin la necesidad de la presencia de Bob.
  
• Ya no es necesaria la espera en confirmaciones en cada intercambio, los intercambios serían casi instantáneos pues sólo dependen del concenso de los servidores que crearon las direcciones de depósito involucradas.
  
• Bob y Alice podrán usar la plataforma desde cualquier dispositivo sin que éste cuente con un software para firmar transacciones, podrán gestionar sus depósitos desde cualquier lugar, además ya no necesitarán todas sus llaves privadas en su dispositivo para poder firmar los intercambios.
  

Todas estas ventajas hacen a la plataforma algo mucho más cercano a lo que ofrece una exchange centralizada, sin los peligros que la centralización de los depósitos acarrea.


¿Cuántos escrows son suficientes?

Podría parecer atractivo que el usuario pudiese usar todos los servidores idóneos disponibles, pues así se aumentaría la redundancia de la red disminuyendo la probabilidad de que un intercambio no recaude las suficientes firmas por problemas técnicos en la mayoría de los  servidores con que se creó la dirección multifirma del depósito, sin embargo, sería impráctico crear un depósito con demasiadas firmas, pues aumentaría demasiado el tamaño de las transacciones de depósitos e intercambios, y aumentaría el tiempo de coordinación de firmas sobre esas transacciones. Propongo 6 servidores participantes en direcciones multifirma 6-of-10 por que me pareció un número más o menos adecuado, pero podría cambiarse a lo que creamos conveniente y de acuerdo al comportamiento de la red.

Por ejemplo, en el caso extremo en el que un sólo grupo de servidores aliados corruptos tengan el control de 50% de todos los servidores disponibles con buena reputación, la probabilidad de escoger n servidores y que k resulten ser corruptos se puede calcular con una distribución binomial, resultando así:


A medida que aumentamos el número de servidores involucrados en la creación de las direcciones multifirma aumenta la probabilidad de completarse un ataque de aliados corruptos, pero tampoco sería conveniente muy pocos servidores, pues por ejemplo, en el caso 3 de 4 sólo con que falten 2 servidores (debido a fallas, desconexión o corrupción) el usuario ya no podrá hacer intercambios con las monedas del depósito, con 4 de 6 hay riesgo si fallan 3, con 5 de 8 hay riesgo si fallan 4, etc., debemos halla la proporción adecuada balanceando la seguridad y la redundancia. 6-of-10 me pareció la proporción más prudente por ahora, ajustaremos ese número al comportamiento de la red en etapas iniciales, por ejemplo, aumentaremos el número de servidores en cada dirección multifirma si detectamos peligro de que aparezcan depósitos sin las suficientes firmas disponibles debido a desconexión de los servidores participantes, por el contrario, si vemos buena disponibilidad permanente de los servidores involucrados podríamos considerar disminuir el número de firmantes, por ejemplo 5-of-8, o aumentar la proporción, por ejemplo 7-of-10 para disminuir la probabilidad de ataque.

Según el escenario de la tabla en 6-of-10 se tienen 37.7% de depósitos robados, parece mucho, pero recordemos que estamos en un caso extremo donde los atacantes tiene el 50% de todos los servidores disponibles con buena reputación, si los atacantes tienen un 40% de los servidores la probabilidad disminuye a 16.62%, y con un 20% disminuye a sólo 0.64%. La restricción en el monto de los depósitos por cada dirección multifirma y una contundente disminución de la reputación de esos servidores en cada robo mitigan el daño en caso de darse una alianza de servidores corruptos.

Lo más importante entonces es crear un sistema donde los usuarios puedan escoger los servidores idóneos, reduciendo al mismo tiempo la posibilidad de alianzas.


Garantizando la idoneidad de los servidores disponibles

Sin la llave en manos del usuario, lo más importante entonces en este sistema multiescrow será garantizar que los servidores usados para crear las direcciones de los depósitos no pertenezcan a un solo administrador (o a un grupo de aliados) para evitar un ataque coordinado combinando las firmas de esos servidores corruptos para hacer gastos sobre los depósitos, se podría proponer que los desarrolladores incluyamos una lista de "servidores de confianza" haciendo algún tipo de convocatoria para escoger servidores idóneos para la red "en los que se pueda confiar", pero esto no brindaría la suficiente certeza de idoneidad, pues los jueces que hacen el filtro son susceptibles de ser corrompidos, y los criterios usados para escogerlos corren el riesgo de no ser los más adecuados; un sistema de votos tampoco sería lo mejor debido a la posibilidad de fraudes a través de la falsificación de votos, o de consecución de votos a través de engaños.

La mejor solución sería un sistema de juzgamiento descentralizado, admitir dentro de la red de servidores a cualquier persona interesada dejando como juez a una serie de reglas objetivas evaluadas por cada usuario de la exchange, la objetividad de las reglas es crucial, si cada usuario juzga basado en la confianza que puede aparentar un aspirante a servido acarrearía incertidumbre por posibles malos juicios debido a los criterios subjetivos de cada persona, se debe usar una convención de criterios automáticos y objetivos, que le permitan al usuario estadísticamente escoger automáticamente a los servidores más idóneos disminuyendo además el peligro de alianzas mal intencionadas. Nos debemos concentrar entonces en proponer los criterios adecuados que serán incluidos en esa serie de reglas, las cuales determinarán qué servidores se usarán para cada depósito.

CONTINUARÁ...

Referencias:

[1] Proyecto en desarrollo de exchange P2P FIAT-Bitcoin: http://www.coinffeine.com/
[2] Billetera en linea con seguridad basada en direcciones multisig https://greenaddress.it
[3] Artículo sobre el rol de las direcciones multisig en el futuro del ecosistema Bitcoin: http://bitcoinmagazine.com/11108/multisig-future-bitcoin/
[4] Post donde jl777 pide ayuda para el desarrollo de multisig en NXT (febrero de 2014): https://bitcointalk.org/index.php?topic=474009.0
[5] Anuncio de Gavin Andresen sobre la adición de comandos para gestionar múltiples firmas en direcciones multisig (mayo de 2012): https://gist.github.com/gavinandresen/2839617
[6] Ejemplo detallado del proceso de transacción con direcciones multisig: https://people.xiph.org/~greg/escrowexample.txt
[7] Servicio de escrow basado en direcciones multisig: https://www.bitrated.com/

Toda forma de gobierno se termina, ninguna persona tendrá derecho a estar por encima de otra, los estados serían organizaciones de personas con intereses similares sin restricciones geográficas raciales o culturales. Todo sistema de castigo, control y regulación será reemplazado por sistemas de restricción intrínsecos al sistema.

Por ejemplo, es imposible robar bitcoins (si se cuida la llave privada), este simple hecho reemplaza a los bancos y buena parte de la policía, el sistema judicial, y todas las organizaciones públicas y privadas encargadas de asegurar y transportar valores, es decir toda la infraestructura de regulación, aseguramiento y castigo encaminada a luchar contra el robo es reemplazada por una característica intrínseca en el sistema, creo que ese es el futuro de todo, pues es extremadamente más eficiente hacer el robo intrínsecamente imposible en vez de gastar todo ese esfuerzo y recursos en sistemas de aseguramiento de valores, más todo el gasto económico y social que se hace persiguiendo, juzgando y castigando gente que logra evadir esos sistemas...

Creo que ese mismo tipo de soluciones se pueden lograr con todas las restricciones básicas que un sistema legal, judicial y de fuerza policial pretende imponer sobre las sociedades.

Un hombre puede soñar... 

Yo entiendo la postura de Srbotones, pero he aprendido con el tiempo que la gente no necesita que yo lo rescate de creer en algo, la gente cree lo que quiere creer y punto, es valioso defender una posición racional en medio de tanta porquería (con "porquería" me refiero a internet en general, no a este hilo en particular), pero es suficiente con exponer claramente esa posición, sin pelear o indignarse ni nada por el estilo, cada quien verá lo que quiera ver y nos evitamos tanto drama... además, suponiendo que ToniPaz fuese un troll, Srbotones ha hecho un pésimo trabajo evitando alimentarlo xD, en éste tipo de flames hay que dar argumentos contundentes, como el hash propuesto por dserrano, no habrían razones de peso para negase a dar un hash de una frase que en un futuro cercano le callará la boca a los contradictores, es demasiado fácil de hacer, si ToniPaz evade el asunto, cada quien sacará sus conclusiones...

Esto, ToniPaz, por favor publique un hash de información privilegiada, las opiniones van y vienen y la credibilidad es subjetiva, las matemáticas son lo único que importa.

No, me refiero al proceso de comprobar que la dirección tiene saldo y no es un doble gasto en cada transacción, son comprobaciones y búsquedas sobre la cadena de bloques, y sobre las otras transacciones en el bloque, este proceso es muy rápido, pero tiene un pequeño impacto si aumentan mucho las transacciones en cada bloque.

Supongo que se refiere a que un cambio en el código de un proyecto complejo, o un cambio en el funcionamiento de un sistema, podría acarrear algún error o abrir alguna vulnerabilidad inesperada, o romper algún sistema a su alrededor que dependía de esa característica, o romper algo que había sido creado asumiendo esa característica. Si algo no está roto normalmente no hay que "arreglarlo", pues arreglar un sistema de cierta complejidad requiere arriesgarse a dañar algo.

Por otro lado, también hay un par de efectos prácticos indeseables para los mineros que se podrían considerar "riesgos" asumidos por ellos, el aumento en el tamaño del bloque también requeriría un mayor tiempo en procesar las transacciones adicionales en el bloque (es un aumento muy pequeño, pero podría ser un problema para mineros muy competitivos interesados en enviar su solución a la red lo más rápido posible y no perder unos segundos confirmando esas transacciones extra), también disminuye la velocidad de propagación del bloque, por lo que podrían aumentar un poco los bloques huérfanos... pero algún día los mineros tendrán que asumir éstos "riesgos" si quieren las comisiones de las transacciones adicionales, estos efectos también se ven mermados con el aumento de la capacidad de procesamientos de los mineros (no me refiero a los hash por segundo, me refiero a los procesadores y el disco duro usados en el proceso de comprobar la correctitud de transacciones, y armar el nuevo bloque sin dobles gastos), y el aumento de la banda ancha de un nodo promedio, dos cosas que tienden a aumentar con el tiempo.

La cadena de bloques actual no cambia, así que no habría que mover las monedas para nada, sólo actualizar al nuevo cliente... no es más que una actualización "obligatoria".


Sé que es solo un ejemplo, pero es inverosímil que eso llegue a suceder, los 42 millones es una característica fundamental, los que quieran más monedas les sería más práctico crear una altcoin, si mañana los desarrolladores se vuelven locos y ponen 100 millones en una nueva versión, de inmediato la comunidad será alertada, la mayoría decidiremos no actualizar, hacemos un fork y seguimos a partir de la versión anterior...

Aumentar el tamaño del bloque no afecta en nada las características fundamentales de Bitcoin, por lo que el ejemplo de cambiar los 42 millones no tiene nada que ver, el límite del tamaño de bloque se puso para evitar el crecimiento desmesurado de la cadena en un posible ataque de transacciones inútiles, aumentar el límite sólo tiene el efecto de hacernos un poquito más vulnerables a ese tipo de ataques, pero la comisión (ahora casi obligatoria) hace inviable un ataque como esos, así que en realidad el cambio no significa nada en términos fundamentales... la discusión se reduce a si es el momento adecuado, si el crecimiento actual de la red lo justifica, logística del cambio, y ese tipo de cosas. La pregunta no es si debemos hacerlo sino cuándo.

De acuerdo, el hecho de haber sido acusados no significa que sea verdad, sin embargo, el


no sobra para nada... sobre todo cuando no son proyectos de código abierto y de uso generalizado...

El tamaño promedio de un bloque difícilmente llega a 30KB, mejor esperar a que exista la verdadera necesidad, así no se divide tanto a la comunidad... en el momento oportuno podría ser tan evidente que sería unánime... tampoco me refiero a esperar a que comience a dar problemas, pero sí esperar varios meses más... tal vez más de año y medio o dos años...

Yo lo vi en vivo, fueron varias horas de pequeñas compras, entre BTC400 y BTC0.1, muchos de BTC10, BTC12, BTC4, BTC1 muy pocas de más de 100... fueron varias horas de golpes muy pequeños, incluso la barrera fue mayor, pues durante esas horas también se vencieron algunos vendedores entre $299 y $300, así que sí, a mi también me sorprende, pero los pequeños se enfrentaron valientemente al muro, ya en la última hora fue cuando llegaron los "grandes"...

Pero sí, no deja de ser extraña una actitud tan aparentemente "irracional"...

Entonces ¿en realidad sí era así de estúpido?  ... ya dejó de ganar más de $800.000 xD si hubiese vendido poco a poco en el rebote... bueno cada quién con su tema...

Es notable que de apoco los pequeños inversores hayan podido hacerle contrapeso a ese personaje... serán ellos los que liquiden esas ganancias (más de 10% en unas cuantas horas).

[chaman]

Por ahora parece que el rebote pierde impulso, probablemente haga falta una buena consolidación antes de ver otros niveles...

[/chaman]

De hecho cointellect ya ha sido acusado de robar monedas con su minero... http://cointelegraph.com/news/112424/is-cointellect-a-scam

Lo dicho, sólo con amenazar con llegar ahí desaparece, no tiene intención de vender ni un solo bitcoin...   hasta el próximo susto...

De acuerdo me da un poco de nostalgia... xD

Ya en serio, de acuerdo, manipulación pura y dura, poner una barrera de $8 millones no tiene ningún sentido excepto para manipular... a ver si algún super-inversor se la come y le hace salir el tiro por la culata, de lo contrario, considero improbable que bitstamp por sí solo se acerque a probar esa barrera pues da mucho miedo... por eso lo que me preocupa es que el mercado deje de seguir a bitstamp y que los demás sean los que empujen el precio para animar a bitstamp a probarla... en fin, está interesante el juego...

Yo no creo que de verdad quiera vender, he estado pendiente de lo que sucede y no he visto que alguien le compre mucho, cuando la puso en $300 de inmediato el mercado entró en pánico y a los pocos minutos estábamos en $275, y ahora lo puso en $320 y el mercado de inmediato pasó a $300, no he visto que haya vendido casi nada, sólo los pocos BTC en ordenes de compra que había en $300 y $320 en el momento en que puso las barreras....

No se puede confirmar su intención de venta hasta que no veamos a alguien que pruebe esa barrera comprando varios cientos, o cuando él ponga la barrera por debajo del precio de mercado absorbiendo un montón de bitcoins en ordenes de compra, lo cual no ha hecho.

De acuerdo, no me refería a tomar alguna acción en particular, me refería a ¿hasta cuándo el mercado va a permitir que lo asusten?... el problema es que los otros exchanges también se están dejando arrastrar por el pánico que ese personaje causa en bitstamp... lo cual me parece "natural", pero un poco tonto... sería interesante ver si el mercado logra absorber eso... antes de que la debilidad recurrente cause una catástrofe...

La puso de nuevo en $320 y el mercado se asustó de nuevo... pero bueno, supongo que el rebote igual estaba cerca de relajarse... lo que me preocupa es si éste personaje va a asustar el mercado cada vez que le de la gana... y hasta cuándo lo vamos a permitir, y hasta cuándo los otros mercados van a  responder a una manipulación descarada en bitstamp...