Topic: ¿Por qué no hacemos un exchange descentralizado basado en el sistema multifirma? (Read 5355 times)

Muchas gracias, interesante, estoy leyendo y analizando a ver si un esquema similar me podría permitir hacer lo que haría con el esquema de multifirma con depósito previo (evitar ofertas sin respaldo, ejecutar las órdenes sin estar en línea, transacción "instantánea", y gestión de ofertas en distintos dispositivos). Yo ya había estado jugando con heurísticas similares usando el nLockTime, pero no había llegado a nada concreto, había reservado nLockTime para usarlo como forma de garantía de que los depósitos no se perdieran para siempre en caso de la desconexión permanente de la mayoría de servidores que crearon la dirección de depósito (más o menos igual a la garantía que tanto promociona GreenAddess en donde se crea una transacciń nLockTime para usarla en caso de que el servidor deje de existir, excepto por varias consideraciones que hay que hacer en un entorno donde los depósitos podrían ser negociados).

En inglés: https://bitcointalksearch.org/topic/20-btc-bounty-for-first-at-atomic-cross-chain-transfer-with-script-clone-826263 https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

Correcto, pero el programa tiene que descifrar esa información en algún momento, pues no podría firmar transacciones sin la llave descifrada, ¿dónde "escondes" la llave de descifrado?, ¿cómo ejecutas el algoritmo de descifrado sin develar la llave al dueño del PC bajo ninguna circunstancia?.

- Aunque no tengas el código fuente, puedes mirar el contenido de la memoria y usando un depurador, encontrar las claves privadas de las que estamos hablando. O las claves de cifrado del tráfico de red que mencionas.
- Nadie va a instalar un software propietario como el office. Este mercado descentralizado multisig será además código abierto. (Vamos, digo yo ).

Yo soy dueño de mi PC, pero no puedo modificar el MS Office que tengo instalado, puedo hacerme uno pero de nada me serviría porque no sería compatible/ o nadie lo aceptaría, puedo descargarme un wireshark y ver lo que entra y sale de mi PC, pero si está encriptado me sirve de poco mirar ahi, lo mismo pasa con la memoria o el disco, si los datos están encriptados no sé lo que habría y por último, el dinero solo estaría temporalmente en esa wallet secreta.

El dueño del PC, puede modificar el software, o hacer uno propio usando el protocolo, o leer lo que entre por su cable de internet, o leer su memoria RAM, o leer su disco duro, y hacer lo que le de la gana con el dinero que recibe...

¿Administrador? En mi modelo no he hablado en ningún momento de administradores... el software en tu pc tendría una wallet que se administra automáticamente por el software, no por ningún agente (persona).

Es decir, imagina que yo creo un programa que genera una wallet en tu pc y que cada vez que recibe dinero, lo manda a otra direccion B. ¿Qué administrador hay? 

No sólo es un problema de código abierto, de nuevo, el nodo va a saber la llave privada (igual que la empresa tiene una lista de códigos de activación válidos en tu ejemplo), y un administrador corrupto podría hacer gastos sobre lo depositado allí, eso es una de las cosas que quiero evitar.

Con software libre sí es fácil, pues puedo editar el código fuente y cambiar su comportamiento.

Ya, no soy ningún experto en seguridad, pero al menos cambié el problema de la centralización a la seguridad! 

En cuanto a poder leer la clave y hablando desde la ignorancia, ¿no sería algo parecido a conseguir la clave de activación o licencia de un software? ¿Eso es tan facil?

Gracias diaviidi por los comentarios.


La verdad es que no veo en dónde está la centralización, pues no existe servidor central, ni depósitos centralizados, de hecho tooodas las consideraciones de seguridad prácticamente se reducirán a evitar centralizar las firmas en un sólo servidor...


Pero entonces las llaves privadas de los depósitos se quedan en los nodos, y un administrador de nodo corrupto podría robarlos, y eso es lo que quiero evitar...


Exacto, cualquier listillo podrá leer cualquier cosa que se genere en su computador. Cuando comencé a abordar el problema yo estaba considerando un sistema similar, parecido a lo que propuso vgo, y uno de los problemas por lo que lo descarté fue la imposibilidad de "esconder" del usuario el proceso de creación del par de llaves, el usuario siempre podrá ver y copiar lo que hace su memoria ram o disco duro, incluso había comenzado a "inventar" alguna cosa para ofuscar de alguna forma la creación del par de llaves y evitar así la lectura de la llave privada, pero se complicaba demasiado el asunto, probablemente no lo hubiese logrado... en otro intento quería hacer un algoritmo de creación conjunta del par de llaves entre el usuario y un escrow, pero también se complicaba mucho...

Esto es más fácil decirlo que hacerlo. Si cojo el código fuente y le plancho un "print" por ahí, obtengo la clave.

Veo que vas de un problema de un exchange centralizado a otro problema de un scrow centralizado o wallet centralizada.

¿Qué os parece este otro sistema?

Premisas:
Cada nodo de la red tiene por defecto una wallet propia con su clave privada encriptada que sólo el programa (nodo) conoce (no el usuario). Es decir, si te descargas el programa, se crearía una wallet en tu pc de la que tu no tendrías las claves.

Proceso:
1. Bob hace un broadcast a la red de su oferta.
2. Todos los nodos reciben la oferta de bob y la actualizan en sus terminales.
3. Alice ve la oferta de Bob y la acepta, enviando otro mensaje broadcast a la red confirmando que acepta la oferta.
4. Bob manda su dinero (BTC) a n nodos cualesquiera (total btc /n para cada nodo) a la wallet secreta.
5. Alice manda su dinero (LTC) a m nodos cualesquiera (total LTC / m para cada nodo) a la wallet secreta.
6. Los nodos actualizan el libro contable con las confirmaciones del envio del dinero de Bob y Alice a los nodos.
7. Cada nodo libera el dinero retenido en su wallet al destinatario correspondiente.

Seguro que he dicho más de una tontería. 

Gracias dserrano5.


Sí, ésto es otra buena posibilidad, también lo había contemplado pero no estoy muy seguro de que hacer escrow a todo usuario sea lo mejor, hay que pensarlo bien con todas sus implicaciones, por ejemplo:

Ventajas del escrow exclusivo:

• Se podría hacer pagar una "membresía" inicial a los escrows, ésto es una barrera de entrada que le obliga al atacante a hacer una inversión inicial, desincentivando los ataques, hay un estímulo para conservar la 'bondad' y amortizar de la forma más segura su inversión inicial (siendo un miembro positivo para la red, aumentando su reputación y captando así las comisiones necesarias). Que conste que no estoy defendiendo las membresías por interés económico personal, sólo me interesa el efecto disuasivo que implica en los atacantes,  de hecho la "membresía" podría ser un 'proof of burn', si es que hay algún problema con eso, o se podría retornar a los escrows actuales como estímulo extra a los 'buenos' escrows y como una forma de compensación por la nueva competencia.
  
• Sin comisiones no hay ningún estímulo para ser un escrow bien intencionado, todos podrían intentar todo el tiempo un ataque y sería la mejor estrategia, pues no tienen nada que perder (teoría de juegos).
  
• El sistema de depósito previo descrito en mi anterior post (el que evita las ofertas de humo, permite intercambios instantáneos, ejecución de las ofertas sin que el dueño del depósito esté en linea, y gestión de las ofertas desde cualquier dispositivo) requiere que los escrows que fueron usados en la creación del depósito estén presentes para firmar todos los intercambios que incluyan esas direcciones de depósito, ésto implica asumir una responsabilidad de servicio 24/7, pues sin las firmas suficientes no se pueden firmar los movimientos, la comisión es el estímulo que tienen esos servidores para mantener una buena disponibilidad de servicio. Sin el estímulo de las comisiones, los escrows no tienen ninguna razón para permanecer en línea, la mayoría de depósitos podrían quedar congelados pues -tal vez- nunca consigan las firmas suficientes. Y sin el depósito previo la verdad no sabría como tener las ventajas mencionadas, las cuales son muy importantes para lograr el dinamismo que hoy ofrece un exchange centralizada.
  

Como bién dices se puede integrar la función de escrow al software de todo cliente, pero creo que prestar el servicio debería requerir de la "membresía", ganando el derecho a captar el necesario estímulo (la comisión) para garantizar la seguridad y la disponibilidad del servicio (en el caso del depósito previo).

No hace falta que nadie ejecute el cliente solo para hacer escrow. Los propios usuarios hacen de escrow por el simple hecho de participar en el mercado. No hacen falta escrows dedicados, por tanto mantengo que no se debería cobrar por este concepto.



Cuando indico que la plataforma provea el escrow, me refiero a que el software que haga de escrow (todo automático tal como he descrito) está integrado en el cliente del mercado, lo que significa que hay tantos escrows como usuarios. Cuando Alice y Bob hacen una transacción, se escoge algún otro nodo de la red, el que sea, para hacer de escrow. O varios nodos. Ni Alice ni Bob saben a quién o quiénes deben sobornar. Visto desde el otro lado, el nodo de Alice puede estar siendo escrow para una transacción entre Charlie y Daisy pero ninguno de los tres lo sabe. No hay "admin de la plataforma".

No, ellos no hacen intercambios entre monedas, son una wallet en línea con multisign, que soporta bitcoins, litecoins y doges, para cuentas mancomunadas, osea los grupos de personas abren una cuenta (que no es más que una dirección multifirma), entonces nadie puede tocar esos fondos sin las firmas de los demás miembros del grupo, interesante tener el servicio on-line y asistido, pero no veo la diferencia a hacerlo directamente con el cliente de la moneda, excepto el evitarte instalar el cliente y escribir los comandos...

Muchas gracias por tu colaboración cryptoonion888, sigo a la espera de que aparezca algún proyecto similar...

Mira Fernarios, estoy pensando en comprar varias acciones de este sitio, es un exchange multisig parecido a lo que propones -creo- echale un vistazo. Es una multisig con multicurrencies.   
Echale un vistazo y dime que piensas y si es mas o menos lo que tienes en mente.

http://multisigplus.com/

Vale gracias, lo voy a hacer, hace un par de años había leído de Ripple y los sistemas de las cadenas de confianza pero no seguí metido en el tema...

Bueno es un poco complicado pero puedes verlo en https://ripple.com/how-ripple-works/ ; basicamente Ripple es un exchange descentralizado, P2P, que utiliza un sistema de confianza gateway que tu activas y que es vigilado por un sistema multiservidores que le llaman el Ledge. Este sistema vigila los intercambios p2p y en el intercambio una pequeña porción de XRP (que es la moneda del sistema de ripple networks) se utiliza para verificar que no haya dobles gastos, esa cantidad al final no es una comisión sino que se destruye una vez que todo ha sido verificado.

Ripple te permite crear gateways con diversas exchanges como bitstamp, pero tambien con quien tu quieras que maneje otro tipo de currency, por ejemplo oro, usd, eur, mxn, etc, y tam,bien alt coins. Sin embargo aquí si es un sistema de confianza, es decir que para que utilizar el gateway debes confiar tu en el tenedor del dinero del otro lado porque al final ese dinero que va estar moviendo tiene que estar en algun lado, ya sea en tu cold wallet o ya sea en ripple o bitstamp, btc2ripple, The Rock, Ripple Singapore, Gold Bullion International, y otros más que te ayudan a convertir en tu moneda local (real brasileño, peso mexicano, peso argentino, etc) sin necesidad de usar un exchange centralizado.

Ripple es descentralizado pero con un sistema unificado mediante el Ledger que vigila (supongo que es un sistema automático) y esta distribuida la red ripple alrededor del mundo.

Yo solo uso rippletrade para mover mis BTC entre cryptostock, bitstamp, localbitcoin y un exchange mexicano que se llama bitso lo que permite moverme en BTC, USD, CNY, y XRP con comisiones realmente muy pequeñas, sin embargo que yo sepa no es un sistema multisig sin embargo si lo soporta https://wiki.ripple.com/Multisign


En realidad creo que vale la pena que le eches un vistazo por ti mismo que realmente sabes sobre estos temas, lo mío es solo una sugerencia de un completo noob pero que busca formas eficientizar los intercambios entre divisas dado que mi moneda local es el MXN (peso mexicano).

Perdona cryptoonion888, pero de nuevo no capto, ¿RIPPLE me puede ayudar en algo?, la verdad no soy experto en RIPPLE, ¿podrías explicar un poco el tema?.

Claro, sería automático, sin embargo, no veo por qué lo automático del escrow implique falta de comisión (cada escrow ejecutaría un cliente-servidor para prestar el servicio automáticamente), si dejamos la comisión en oferta y demanda el mercado encontrará por sí mismo la comisión adecuada, en pares con muchas transacciones (LTC/BTC por ejemplo) la comisión podría incluso llegar a ser insignificante, pues habría mucha competencia por captar la mayor cantidad de transacciones. Por otro lado, la misma plataforma podría proveer un escrow con una comisión bastante baja al principio para evitar los abusos, pero creo que te refieres a que la plataforma misma provea el escrow, la idea es que existan muchos escrows y no se pueda convertir en un monopolio, pues así se evita el riesgo de que un administrador de la plataforma se corrompa, y se comience a aliar con usuarios (o él mismo actúe como un usuario) y comience a defraudar gente. La garantía más importante del sistema (a mi parecer) es la independencia entre el escrow y las partes en una transacción, si el escrow siempre es el mismo esa garantía se reduce a la confianza que los usuarios depositen en la plataforma, y es lo que quiero evitar, y lo intento evitar abriendo el escrow a toda persona que esté interesada en proveer ese servicio, agregando un sistema de reputación de escrows, y una buena fórmula para la asignación automática y transparente del escrow basado en la reputación, la comisión y un poco de azar.


Un escrow automático perteneciente a la plataforma también es programado y susceptible de ser modificado por un humano corruptible (el admin de la plataforma), me parece más adecuado depositar la confianza sobre una red de escrows independientes que sobre un administrador, pues la principal motivación de éste proyecto es evitar depositar esa confianza excesiva en un sólo individuo. Es cierto que un escrow externo no está obligado a prestar un buen servicio, pero con un sistema multiescrow (tu también intuiste ésta característica proponiendo un 4to nodo que se encargaría de actuar en caso de fallo del escrow, yo lo había pensado como un sistema "multiescrow"), una cuarta, quinta, o décima firma en las direcciones multisign para lograr un consenso suficiente en caso de que un escrow falle o se corrompa. Eso me lleva a agregar otra sección a la especificación, en donde precisamente explicaba la necesidad de apertura al público del sistema de escrows, y la posible utilización de múltiples escrows en cada una de las transacciones:

________________________________

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.

________________________________
Lo agrego al primer post. Continuaré desarrollando la propuesta de ese sistema para escoger servidores idóneos en otro post. Repito, cualquier comentario es más que bienvenido.



Curioso que lo menciones vgo, éste proyecto comenzó con la idea de intercambiar llaves privadas P2P, fue lo primero que se me ocurrió, pero lo descarté por que precisamente no pude encontrar una forma de "bloquear" esos fondos, ni de garantizar la "destrucción" de la llave privada por parte de quien la había creado (alguien la tiene que crear pues se necesita que alguien calcule la llave pública, un computador, cuyo dueño es un ser humano corruptible), incluso pensé en sistemas en donde se creara el par de llaves en un algoritmo compartido entre los usuarios y un escrow, pero se complicaba demasiado el asunto así que tomé el camino de la dirección multifirma.

No te sirve de base el sistema de RIPPLE?

La consola del blockchain donde se ven las transacciones a tiempo real y después hacer un registro... olvídalo, igual es una chorrada.


LLámalo bloqueo de cartera o transferencia directa/automatica al escrow al hacer el pago pero supongo que lo ideal sería un sistema infalible sin necesidad de un tercero.

Re: comprobación en muchas alts: sí, es un poco peliagudo este tema. No tanto por el desarrollo inicial, sino también porque luego hay que estar al día de los cambios que se produzcan (p.ej. "Actualización obligatoria de cacacoin el próximo 10 de octubre"). No ser diligentes en este punto provocaría transacciones sin confirmar y, por tanto, fraude.

Como detalle de implementación, una arquitectura de plugins viene al pelo en este caso.

Re: comisión de la red: cada uno de los peers pondría comisión en su transacción. El escrow comprobaría que es suficiente. Incluso se puede exigir una comisión, digamos, "más que suficiente" para ir sobre seguro .



Alice no sabría a qué nodo de la red atacar. Ella interactuaría con su cliente (en un software descentralizado, todo el mundo tiene que ejecutar un cliente en su ordenador) y el escrow sería transparente. Pero incluso aunque lo supiera, hacer un DoS no le supondría ventaja porque si ella publica una transacción usando la misma input, luego el escrow al hacer las comprobaciones necesarias ve que la input ya está gastada, aunque sea con cero confirmaciones, y entonces se negaría a continuar, cancelando totalmente el trato.

La única oportunidad de Alice sería intentar esto justo después de que el escrow hiciera tal comprobación, pero si en el escrow se pone este tiempo aleatorio de espera que mencioné, Alice no tiene forma de saber cuándo intentarlo. La ventana de doble gasto es muy estrecha, de unos pocos segundos en una red grande como bitcoin, más estrecha todavía en redes con menos nodos.

--

Re: comisiones de los escrows: realmente pienso que el escrow debería ser automático, y por tanto no cobraría comisión. Meter a un humano en esto, corruptible y con tendencia a desaparecer 8 horas seguidas cada día, incluso durante una operación abierta si los peers son lentos, y que aun por encima implicara costes adicionales, no me convence nada. Sé que un escrow automático tiene sus riesgos, pero pienso que merecería la pena dedicarle algo de esfuerzo.



No entiendo "cascada de blockchain"…



Supongo que esto de bloquear los fondos es precisamente la motivación original del OP en usar multifirma. Una vez los peers pierden el acceso exclusivo a sus fondos y se mete al escrow en la ecuación, se gana mucho en seguridad.

Tipo la cascada de blockchain con un registro de ordenes?? Pregunto, no tengo puta idea.

Edito: Dándole un par de vueltas mas, si existiera la posibilidad de bloquear carteras, se podría buscar un sistema en que el comprador bloquea la cartera del vendedor mediante el pago, osea a la vez que compra bloquea la cartera del vendedor con su saldo y pasaríamos a intercambios de carteras ( que tampoco se si existe), no de monedas directamente.

Gracias de nuevo por los comentarios.


Vale dserrano5, sí, podría funcionar, sin embargo, me da un poco de temor eso de que la comprobación de la validez de transacción la haga el escrow, con tantas monedas y con -tal vez- protocolos distintos (o versiones de protocolos distintas), creo que se complicaría el tema a la hora de crear el algoritmo de comprobación, sumado al cálculo de la comisión adecuada en cada moneda (para evitar el doble gasto por falta de comisión), soportar también una nueva moneda sería un tema más delicado. También como lo mencionas está lo de un posible fallo en el escrow cuando llega la hora de publicar una de las transacciones, no sólo un fallo casual, también podría ser atacado con DDoS o algo así, en el momento en que por ejemplo Alice envía la transacción al escrow, y de esa forma conseguir el retraso necesario para hacer el doble gasto, . Pero sí, haciendo esas salvedades (y agregando el backup del escrow) croe que ese sistema podría funcionar, se sacrifica un poco de certidumbre y se complicaría un poco la implementación pero se ganaría mucho tiempo.


Hem... tal vez en un nuevo hilo alguien se interese. Como dije, los bitshares no es la solución que busco, pues éstos requieren de la centralización de los depósitos en manos de una sola entidad o persona.


Gracias cryptoonion888 entendo el apalancamiento, pero creo que las criptomonedas tienen la suficiente volatilidad como para se cuestionable su uso, no lo descarto, pero igual de todas formas es una característica muy avanzada, por ahora estaré concentrado en las características más básicas de las exchanges centralizadas...

El tema de las comisiones será interesante, pues en un esquema como el que propuse la comisión de cada transacción se podría pagar a los escrows directamente, y los escrows podrían pagar una membresía a la plataforma o un pequeño porcentaje de acuerdo a las operaciones asignadas, ya veremos, también habría que manejar de forma transparente la asignación de intercambios, pues la competencia entre escrows también será una variable importante. En fin, sí, se podría fijar una comisión estándar de acuerdo al par que se trate, sin embargo, las comisiones también estaría regidas por la competencia entre escrows, un escrow podría cobrar más en un par de monedas "raro", hasta que le llegue competencia de otro escrow disponible con menor comisión y mejor o similar reputación, el monto de la comisión estaría regido por la oferta y demanda .

Quizá no quedo claro, pero supongamos que tu creas un exchange eFOREX, entonces por cada BTC que tu depositas, el exchange te presta 100 BTC para que tus ganancias sean mas altas, pero de igual manera si te equivocas tus pérdidas se multiplican por 100. Así funciona el FOREX, ahora escribiendolo veo que es algo intenso y descabellado inclusive, pero dejando el spread de lado, la comisión si variaría dependiendo las monedas que se intercambien quizá por porcentajes basados en el exchange mas común que es el USD/BTC o CNY/BTC.

En el FOREX los pares manejan un spread que es la comision que cobra el exchange por el cambio. En pares que son muy convertidos como el EUR/USD el spread es de 4 pips o sea que si el euro está a 1.2806 dlls, para que yo comience a tener porcentaje positivo, -si yo creo que el euro va a subir- tiene que subir al menos a 1.2810 para arriba, los pips despues de ese valor es ganancia. En los FOREX un pip puede parecer poco pero como se apalanca al 100 por cada dolar que yo pongo me prestan 100, o sea que si pongo 100 me dan 10000 entonces un pip resulta ser 1 dll, y no 0.0001 dlls  (va por lotes)
Lo otro que se maneja en FOREX es el swap que es un porcentaje de retención por mantener una postura a la venta o a la compra que es del 0.01% diario.

Pero aquí lo importante para las criptomonedas es que el spread varía, por ejemplo para el EUR/USD  es de 4 pips, pero para monedas exóticas como NZD/CAD puede ser de hasta 20 pips.

Analizando esto la comisión por convertir de BTC/LTC, BTC/DOGE es mucho menor, pero cuando es por ejemplo BTSX/NXT, URO/DOGE, aumenta un poco la comisión. Digamos que actualmente por cambiar de NXT a BTC es 0.2%; en lugar de ello tu compras el par NXT/BTC ya sea a subir o bajar (Buy o sell) con un spread, digamos, de 30 NXT porque lo que compras es el par NXT/BTC que está a 16400/1   ... jeje. Bueno en el FOREX funciona así por el apalancamiento, pero lo importante es que es porcentaje de cambiar NXT por BTC es de 0.2% pero por cambiar NXT/CANN por decir algo, podría ser del 0.5% directamente, sin tener que hacer el paso NXT-BTC-CANN-BTC-NXT que implicaría exponenciar ese 0.2% al menos 3 veces si lo dejas en CANN.  

y si hacemos una moneda pos para clonar btsx en castellano en el futuro.

Tras madurar mis ideas un poco más me di cuenta de que no conducían a nada. Que para no operar en dos cadenas al mismo tiempo, el mercado tendría su propia cadena de bloques. O sea, sería una altcoin. O sea, habría que comprar y vender esta alt… y entonces estamos como al principio.



Se me ha ocurrido otra cosa:

• Bob hace una oferta en una plataforma pública de ofertas, quiere intercambiar 0.8 bitcoins por 80 litecoins.
• Alice acepta la oferta y avisa al sistema sobre su intención de aceptarla, un escrow de la plataforma toma su lugar. A continuación hace llegar a Bob y al escrow una dirección de bitcoin suya (1Alice) donde recibirá BTC de Bob.
• Bob crea una raw transaction 2 de 2 pagando 0.8 BTC a 1Alice y enviando el cambio a una dirección suya. La firma. A continuación hace llegar a Alice y al escrow una dirección suya (LBob) donde recibirá LTC de Alice, y envía su raw transaction al escrow.
• Alice crea una raw transaction 2 de 2 pagando 80 LTC a LBob y enviando el cambio a una dirección suya. La firma y la envía al escrow.
• El escrow hace las comprobaciones pertinentes (0.8 BTC van a 1Alice, 80 LTC van a LBob, las dos son estándar según las normas de cada cadena, ninguna va a suponer un doble gasto…), pone la firma que falta a ambas transacciones y las publica al mismo tiempo en ambas cadenas.

En este escenario todo es automatizable, incluso el escrow. A partir del clic de Alice, el software se encarga de todo. El escrow podría ejecutarse en algún otro nodo de la red.

Problemas:

• Alice, sabiendo que todo va rápido a partir de su clic, tiene una ventana para intentar un doble gasto (así, su transacción no se confirmaría pero la de Bob sí); sin embargo, se puede programar en el escrow un tiempo de espera aleatorio para que Alice no conozca el milisegundo exacto en que debe intentarlo.
• El nodo donde se ejecuta el escrow podría venirse abajo durante la operación. En el peor de los casos, se caería justo después de publicar una de las transacciones y antes de publicar la otra. Oops… Quizá un cuarto nodo podría hacer de ayudante. El escrow envía las transacciones firmadas al ayudante y a continuación las publica. El ayudante espera unos segundos y las publica incondicionalmente. Si el escrow se queda a medias a la hora de publicarlas, el ayudante vendría al rescate. Sin embargo esto no es una solución definitiva, solo probabilística.
• Seguramente más .

Gracias por los comentarios dserrano5.


Sí, creo que estamos pensando de forma diferente, con "el escrow" me refiero a una persona independiente, no voy a usar el sistema de escrow automático en donde el depósito se pierde si alguien traiciona, voy a usar un sistema de escrow automatizado pero que represente una aprobación de un servidor independiente. Tienes un punto muy válido, sería muy difícil coordinar un intercambio al mismo tiempo en dos cadenas de bloques diferentes (en donde de hecho se van a confirmar en tiempos diferentes lo que lo hace vulnerable al doble gasto), de ahí que se te ocurra la transacción atomizada (de hecho ésta idea nació atomizando las transacciones, pero después cambié el modelo precisamente por estos inconvenientes), en mi idea, hay un intermediario, alguien quien puede firmar un par de direcciones multisign 2-of-2 que las partes usan como escrow, una vez las monedas estén en las direcciones multisign, será el intermediario el que firme las transacciones de intercambio (sacar de las direcciones multisign a las direcciones personales de los destinatarios).

Mostraré un ejemplo, para simplificar la explicación del concepto fundamental el ejemplo desarrolla un intercambio de criptomonedas con un escrow, pero es claro que así aún estamos lejos de lo que ofrece un exchange centralizado, luego agregaré otras cosas como un sistema multiescrow, el sistema de consenso para la descentralización de los depósitos, y una propuesta para usar un sidechan en vez de trabajar directamente en las cadenas de bloques de cada moneda, se complica el sistema, pero creo que todo tiene buenas razones, ya hablaremos de eso en detalle...

_____________________________________

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

Agrego el ejemplo al primer post.

Ofrecer ésta plataforma de publicación de ofertas y de reputación de escrows podría ser la primera etapa del proyecto, pero como mencioné, el objetivo es ofrecer el mismo dinamismo y funcionalidad que ofrece hoy una exchange centralizada, así que sólo sería la primera etapa de muchas...

¿Esto tiene sentido? En un mercado descentralizado, tal como yo lo veo, nadie envía coins a ningún sitio que haga de depósito. En bitstamp hay decenas de miles de coins porque la gente las ha enviado pero en uno descentralizado, los usuarios tienen las "reservas". Lo que hay que probar es que las entradas en el libro están respaldadas por coins reales.



En mi visión, no habría servidor que hackear .



La pega de esto es que Bob es perfectamente libre de no enviar el producto a Alice, con lo que el trato se rompe. En un mundo ideal, Bob no solo estaría forzado a seguir adelante con el trato (coñe, para eso tiene una entrada en el libro de órdenes) sino que además la operación sería atómica. Este último requisito tiene mucho más meollo puesto que eso implica una transferencia de coins en dos cadenas distintas al mismo tiempo. Aunque Bob todavía podría romper el trato con un intento de double spend…

Me parece que mis ideas en algunos puntos no se alinean del todo con las tuyas . Quiero decir, yo no veo el multisig por ningún sitio.

Gracias por las preguntas cryptoonion888.


En resumen, funcionaría decentralizando el escrow, ampliaré esto en detalle en la especificación. La principal ventaja sería la decentralización y todo lo que implica en cuanto a seguridad de los depósitos.
Al final del post publicaré una justificación del proyecto, en donde también se responden a grandes rasgos estas preguntas de cryptoonion888.

Tal cual se ha logrado decentralizar Bitcoin y otras criptomonedas: en base a un sistema de consenso.

No sería parecido a BTSX, pues en BTSX los depósitos están centralizados, y una sola persona tiene el control de todos ellos.
El sistema podría trabajar con tantos pares de monedas como sea posible, siempre y cuando las monedas soporten el sistema multisign, hayan personas interesadas en ofertar intercambios entre estos pares, y hayan escrows disponibles para soportar los depósitos.

El crowdfounding se me ha pasado por la cabeza, sin embargo, aún estoy en una etapa preliminar, cuando tenga especificado todo el proyecto y haya realizado algunos experimentos para demostrar la viabilidad de los aspectos principales, empezaremos a pensar en la financiación del proyecto.

Como mencioné, sí, el proyecto será libre de agregar cualquier par de monedas, siempre y cuando exista gente interesada en hacer ofertas entre esos pares y escrows interesados en soportarlo, ésto también está hecho para que el trading sea más incluyente, para que cualquier moneda pueda ser intercambiada sin necesidad de pasar por la aprobación de un administrador de exchange, beneficiará a proyectos que han trabajado mucho por sus monedas pero que no tienen la visibilidad que se merecen por no estar en uno de los exchanges dominantes.

Hem, no me queda muy claro eso de manejar los spread como comisión, ¿podrías ampliarlo?.



Agregaré ésto al post inicial, así iré completando la propuesta en un solo post, eventualmente lo pasaré a un archivo independiente.
______________________________

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

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://bitcointalksearch.org/topic/hiring-developers-for-automated-multisig-nxt-gateways-c-java-474009
[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/

_____________________________


Sobra decir que cualquier comentario o pregunta será más que bienvenida.

De algo estoy seguro. BTC es la moneda de referencia, pero al igual que el USD no es nada globalmente sin otras monedas de soporte. El FOREX permite que el USD no se deprecie y eso es gracias a que existen todos los pares de monedas posibles, es decir conversiones de MXN/JPY, GBP/CAD, CAD/NZD, NZD/MXN, etc. La ganancia en el pareo entre monedas no principales o secundarias como por ejemplo entre el par MXN/NZD está en el spread... si se pudiera hacer una plataforma que maneje los spread como comisión, sería no sólo un buen negocio sino que fortalecería al sistema del Bitcoin.

¿Cómo funcionaría un sistema de intercambio descentralizado basado en el sistema multifirma y cual sería la ventaja contra otros como Bittrex, Poloniex, CEX, etc. ?
¿Cómo se logra que sea descentralizado sin que tenga allá detrás una empresa que lo dirija?
¿Sería algo parecido a las plataformas de NXT o BTSX pero con multisig e interconectando todas las criptos entre sí: ejemplo parear NXT/CANN, XRM/URO CANN/URO, LTC/DOGE, LTC/BTSX ETC?

Quizá podría ser una plataforma tipo PLUS500 pero para pares de criptos y con multisig...  ¿No te gustaría meterlo a una crowdfound o a cryptostock...? A crypsy le fue bien en CS.

Bueno... me alegra confirmarlo xD... gracias.


Muchas gracias dserrano5, ésto era principalmente lo que necesitaba, que la gente me diga si conoce un proyecto similar, pues he investigado y se me hace muy raro no encontrar una propuesta similar, pues no veo por qué no hacerlo, la tecnología multifirma ya estaba propuesta hace varios años, y ya está implementada hace más de un año en el core de bitcoin, y hace varios meses en varias altcoins, la han estado aprobechando en algunos servicios para bitcoin, pero casi cero aplicaciones para altcoins, mucho menos he visto una combinación para el comercio entre monedas, he llegado a pensar que en realidad no se puede aplicar como estoy pensando y nadie lo ha propuesto por eso, tal vez yo no estoy viendo algún inconveniente que otros sí, por eso necesito de la ayuda de la comunidad, en ésto se aprende todos los días algo nuevo, y por supuesto yo podría estar omitiendo algo importante, tendremos más claridad cuando especifique las cosas técnicamente. También he estado consciente de OpenBazaar, me parece muy interesante, sin embargo, creo que un exchange especializado en intercambiar pares de criptomonedas es algo muy distinto, creo que necesitamos algo dedicado, pues entre otras cosas, sería difícil tener un precio de referencia y soportar todos los aspectos que tiene el trading sobre operaciones en openBazaar, aunque sí, se podría ver la posibilidad de hacer una capa sobre OpenBazaar dedicada al trading, interesante... pero definitivamente habría que al menos adaptarlo, tal y como está propuesto creo que no cumpliría con las expectativas y necesidades básicas de un usuario habitual de exchanges de altcoins.


Gracias Danbcf, también espero eso, que con la explicación ya comencemos a cuestionar detalles (o todo el proyecto)...

Por supuesto que tendríamos que abrir el proyecto a los algo-parlantes, sin embargo, quería manejarlo aquí en ésta etapa preliminar, pues me siento más cómodo discutiendo en español, (entiendo muy bien el inglés, pero confieso que a la hora de redactar soy un desastre), quería exponer el proyecto en inglés con la ayuda de un traductor profesional calificado cuando (si es posible), o por lo menos alguien que no se demore tanto como yo redactando algo decente, pero quiero hacerlo ya cuando tengamos algo más sólido el proyecto.

La comunidad española es mas bien corta aunque cuando saques el proyecto a la luz esperemos que los grandes entendidos aporten su granito de arena, sino tal vez podrías sacar mas del foro en inglés.

Un saludo

Sí, hombre, claro que hace falta. Sin embargo, ¿no viene openbazaar a rellenar un poco este hueco? De acuerdo que no es un exchange como tal, pero sirve perfectamente para tradear BTC y altcoins de forma descentralizada.

Con el desastre de Cryptorush... y la reciente quiebra de Mintpal (sólo por mencionar algunos casos), ¿no estamos de acuerdo en que necesitamos algo como ésto?, no trato de pescar en río revuelto, pero es que la verdad creí que el hilo despertaría algo más de interés...   ¿no lo ven viable? o ¿no lo ven importante?. Bueno, es cierto que no he explicado mucho (me estoy mudando y no he tenido mucho tiempo), pero creí que mencionando la automatización del escrow multifirma más o menos se imaginarían por dónde va la cosa y sería suficiente para algunos comentarios... en fin, en estos días estaré publicando la especificación (ya tengo adelantada buena parte), si no despierta interés mejor no gasto energía en ésto, pues la idea era un proyecto de software libre en donde se incluyera a la comunidad, si éste hilo es una discusión de yo con yo mejor lo hubiese desarrollado yo sólo y un par de amigos cercanos, pero estoy seguro que si lo desarrollamos de cara a la comunidad tendremos mejores resultados pues aquí hay personas que pueden aportar bastante, y no sólo desde el aspecto técnico (si es que les interesa claro...), pues es la comunidad la que mejor sabe exactamente lo que necesitamos.

Gracias aleix, conocía Bitsquare, junto a coinffeine son los proyectos que les veo más posibilidades en cuanto a descentralización de las exchanges, me parecen muy interesantes y estoy muy pendiente de ellos, sin embargo, mientras ellos se concentran en FIAT/BTC, yo quiero ayudar a brindar una solución al trading entre pares de criptomonedas...

Fernarios, creo que te puede interesar http://bitsquare.io

El desarrollador es un colega, se llama Manfred y es miembro de la comunidad bitcoin de Barcelona.

Estará encantado de discutir contigo los detalles del proyecto, compartir código, etc. Además están buscando más desarrolladores  

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.

una duda.... que es el scrow multifirma?

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://bitcointalksearch.org/topic/hiring-developers-for-automated-multisig-nxt-gateways-c-java-474009
[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/