@@ -26,18 +26,22 @@ Los admins de wallet.fair.coop y ocp deberían de ser distintas personas y no gu
...
@@ -26,18 +26,22 @@ Los admins de wallet.fair.coop y ocp deberían de ser distintas personas y no gu
#### Cadena de bloques
#### Cadena de bloques
* Electrum: Python, puede ser usado como librería como se hace en OCP y en FairMarket y soporta transacciones multifirma. Software muy maduro, actualizado y auditado.
* Electrum: Python, puede ser usado como librería como se hace en OCP y en FairMarket y soporta transacciones multifirma. Software muy maduro, actualizado y auditado.
https://github.com/faircoin/electrumfair
https://github.com/faircoin/electrumfair
* Pycoin/Pycoinnet: Bibliotecas para crear aplicaciones bitcoin en python puro. Soporta FairCoin y multisig.
* Pycoin/Pycoinnet: Bibliotecas para crear aplicaciones bitcoin en python puro. Soporta FairCoin y multisig.
* FairBreadWallet: Biblioteca en C. ¿Soporta multisig?
* FairBreadWallet: Biblioteca en C. ¿Soporta multisig?
https://github.com/faircoin/fairbread-core
https://github.com/faircoin/fairbread-core
* FairCoinJ: Biblioteca en Java. Soporta multisig.
* FairCoinJ: Biblioteca en Java. Soporta multisig.
https://github.com/faircoin/faircoinj
https://github.com/faircoin/faircoinj
* FairCore-lib: Biblioteca en JavaScript. Soporta multisig. Al ejecutarse en el entorno del cliente se puede crear alguna validación extra, de forma que el cliente necesite firma la transacción. Incluso se le podría suministrar otra clave privada con la que firmar la transacción, el incoveniente de esto es que disminuye la usabilidad y el conocimiento mínimo para usar la herramienta. Puede ser opcional en el futuro.
* FairCore-lib: Biblioteca en JavaScript. Soporta multisig. Al ejecutarse en el entorno del cliente se puede crear alguna validación extra, de forma que el cliente necesite firma la transacción. Incluso se le podría suministrar otra clave privada con la que firmar la transacción, el incoveniente de esto es que disminuye la usabilidad y el conocimiento mínimo para usar la herramienta. Puede ser opcional en el futuro.
Necesitamos una herramienta que proporcione una manera rápida y segura de crear un controlador web.
Necesitamos una herramienta que proporcione una manera rápida y segura de crear un controlador web que permita la interacción con las bibliotecas anteriores.
* Odoo, es en lo que tengo más experiencia, pero claramente es matar moscas a cañonazos. Además necesitaría de una base de datos, la cual no debería ser necesaria.
* Odoo, es fácil crear un controlador, pero claramente es matar moscas a cañonazos. Además necesitaría de una base de datos, la cual no debería ser necesaria.
* Django, parece más adecuado y los más cercano a OCP.
* Django, parece más adecuado y los más cercano a OCP.
* Servidor a medida (sistema OCP actual): Desde el punto de vista de la seguridad y tiempo necesario de desarrollo no es factible.
* Servidor a medida (sistema OCP actual): Desde el punto de vista de la seguridad y tiempo necesario de desarrollo no es factible.
* Otras opciones...
### Funcionamiento
### Funcionamiento
...
@@ -70,6 +75,5 @@ Todas las carteras tienen las mismas direcciones por lo que pueden observar toda
...
@@ -70,6 +75,5 @@ Todas las carteras tienen las mismas direcciones por lo que pueden observar toda
wallet.fair.coop sólo ejecuta la cartera y sólo se comunica con los servidores autorizados, el resto de tráfico se filtrará en el firewall. Un VPS pequeño de 1 núcleo, 1GB de RRAM y 10GB de disco duro realizará el trabajo sin problemas.
wallet.fair.coop sólo ejecuta la cartera y sólo se comunica con los servidores autorizados, el resto de tráfico se filtrará en el firewall. Un VPS pequeño de 1 núcleo, 1GB de RRAM y 10GB de disco duro realizará el trabajo sin problemas.
Podemos seguir usando el sistema usado hasta ahora en OCP de forma que cada dirección mantenga el balance del usuario, aunque no es eficiente. El balance de cada usuario y el historial de transacciones deberían ser campos en la base de datos de OCP, el sistema actual es un cuello de botella que no va a dar problemas si se escala la aplicación a cientos de usuarios. De esta forma podríamos tener dos carteras en OCP:
Podemos seguir usando el sistema usado hasta ahora en OCP de forma que cada dirección mantenga el balance del usuario, aunque no es eficiente. El balance de cada usuario y el historial de transacciones deberían ser campos en la base de datos de OCP, el sistema actual es un cuello de botella que no va a dar problemas si se escala la aplicación a cientos de usuarios. De esta forma podríamos tener dos carteras en OCP:
1. Cartera temporal, con las direcciones actuales, para detectar ingresos. Cuando se realiza un ingreso, la cartera lo detecta, notifica a OCP del ingreso y se actualiza el balance del usuario en la base de datos. También este trabajo se puede realizar mediante un cron en vez de con notificaciones.
1- Cartera temporal, con las direcciones actuales, para detectar ingresos. Cuando se realiza un ingreso, la cartera lo detecta, notifica a OCP del ingreso y se actualiza el balance del usuario en la base de datos. También este trabajo se puede realizar mediante un cron en vez de con notificaciones.
2. Cartera segura multifirma, cuando OCP ha actualizado el balance, transfiere los fondos a una cartera segura, que será la cartera multifirma que se ejecute en wallet.fair.coop. De esta forma sólo desde OCP se tendrá acceso a los balances de los usuarios.
2- Cartera segura multifirma, cuando OCP ha actualizado el balance, transfiere los fondos a una cartera segura, que será la cartera multifirma que se ejecute en wallet.fair.coop. De esta forma sólo desde OCP se tendrá acceso a los balances de los usuarios.
