Topic: ¿Por qué no hacemos un exchange descentralizado basado en el sistema multifirma? - page 3. (Read 5403 times)

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/