Re: comisiones de los escrows: realmente pienso que el escrow debería ser automático, y por tanto no cobraría comisión.
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.
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.
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 MultiescrowRecordemos 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í:
+---+---+------+
| k | n | P |
+---+---+------+
|3 |4 |31,25%|
+---+---+------+
|4 |6 |34,38%|
+---+---+------+
|5 |8 |36,33%|
+---+---+------+
|6 |10 |37,70%|
+---+---+------+
|7 |12 |38,72%|
+---+---+------+
|8 |14 |39,53%|
+---+---+------+
|9 |16 |40,18%|
+---+---+------+
|11 |20 |41,19%|
+---+---+------+
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 disponiblesSin 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.
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.
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.
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.
