¿Cómo se implementan las carteras de bitcoin populares? [cerrado]

¿Cómo se implementan las populares billeteras de bitcoin en línea, como blockchaininfo? ¿Por qué no son de código abierto?

Esto es demasiado vago para ser razonablemente responsable, si está solicitando detalles de todas las "carteras en línea populares". ¿Puede reformular la pregunta a algo específico y que se pueda responder, como "¿Cómo se implementa el sistema blockchaininfo eWallet?"? Si no, sospecho que esta pregunta se cerrará.
El código de la billetera del lado del cliente (por ejemplo, Javascript) es de código abierto. El lado del servidor no lo es.
-1 por preguntar por qué no son de código abierto (simplemente tonto). Sin embargo, puede eliminar esa pregunta secundaria.

Respuestas (3)

Precisión no garantizada

blockchain.info

  • Las carteras son archivos json. El archivo json se cifra mediante AES ( crypto-js ) antes de que los navegadores soliciten que se almacene en el servidor.
  • El archivo de la billetera está incrustado en la página de inicio de sesión como un atributo de datos html, el navegador descifra el archivo con la contraseña proporcionada y extrae una lista de direcciones y claves privadas.
  • Luego, el navegador solicita a la información de blockchain el saldo y la lista de transacciones recientes para las direcciones descifradas.
  • Al enviar, los navegadores solicitan a blockchain.info una lista de salidas no gastadas. Luego selecciona las construcciones de salida y firma la transacción en sí ( bitcoin-js ). Cuando esté lista, la transacción se serializa y se envía a bloackchain para su transmisión a la red de bitcoin.
  • La autenticación se realiza mediante una "clave compartida" única contenida en el archivo de la billetera en lugar de la contraseña de los usuarios.
  • Del lado del servidor, usamos 4 servidores que ejecutan el clúster MySQL y Java. Se utiliza un cliente bitcoind modificado para llenar la base de datos.

Vea cómo funciona

moneda fuerte

  • Similar a blockchain.info con cifrado del lado del cliente.
  • Las claves privadas se almacenan individualmente en el servidor como una entrada de la base de datos en lugar de en un solo archivo de billetera.
  • La autenticación se realiza del lado del servidor mediante sesiones tradicionales.
  • La construcción y firma de transacciones se realiza en javascript.
  • Utiliza blockchain.info o blockexplorer.com para consultar saldos de direcciones. Utiliza blockchain.info para transmitir transacciones.
  • El lado del servidor usa Ruby on Rails y Heroku

base de monedas

  • El lado del servidor usa Ruby on Rails y Heroku
  • Base de datos MongoDB personalizada para consultar el saldo de direcciones.
  • El servidor selecciona salidas, construye y transmite transacciones.
  • La autenticación se realiza del lado del servidor mediante sesiones tradicionales.
  • La aplicación web se conecta directamente a la red bitcoin usando Bitcoin-Ruby para llenar la base de datos.

¿Qué no son de código abierto?

Son empresas comerciales con una gran cantidad de tiempo de desarrollo invertido. El código, que es de código abierto, a) aumentaría la competencia b) haría que aparecieran sitios de phishing idénticos c) los estafadores podrían piratear o ejecutar clones que dañan la reputación del sitio principal.

Partes de blockchain.info son de código abierto . Personalmente, espero que el resto del sitio sea completamente abierto algún día, pero hay mucho que planear. Si el código simplemente se descarga, no beneficiará a nadie.

¿Cómo consulta la información de blockchain las transacciones recientes para obtener una lista de direcciones? Por ejemplo, si el archivo JSON de la billetera tiene 100 direcciones, ¿eso requiere hacer 100 llamadas separadas a la API de información de blockchain para las transacciones recientes de cada dirección?

Como alguien que ha implementado una billetera electrónica pequeña, supongo que puedo responder esta pregunta desde mi perspectiva.

La implementación de una billetera electrónica es bastante simple. El uso de la API oficial hace que todo se reduzca a emitir llamadas JSON RPC correctas. Por lo general, tiene una instancia de bitcoind ejecutándose en un servidor, junto con el frente de su sitio web. El principal problema es asegurarse de que su sitio pueda distinguir entre varias personas y asegurarse de que no puedan acceder al dinero de los demás. En la práctica, es bastante simple.

Hay algunos caminos de implementación que puede tomar con eWallets:

  • Puede tener una cuenta por persona, por lo que, siempre que pueda distinguir entre las personas, su sitio web puede ser "sin estado", es decir, no guardar ningún dato. He implementado eso y no fue difícil.
  • Puedes dejar que cada persona tenga tantas cuentas como desee. Esto requiere que se almacene cierta información adicional en su sitio web y para garantizar que su nombre sea único. Además, no es un gran problema, lo he hecho.
  • Puede mover el dinero de todos a un fondo compartido y realizar un seguimiento de cuánto tiene cada persona. El servidor de su sitio web debe tener una base de datos separada de saldos. Un poco más complicado, debe tener en cuenta problemas como el doble gasto y demás para no dar crédito a los estafadores. Hasta donde yo sé, este es el modelo más popular para eWallets.
  • Concéntrese principalmente en mantener las claves privadas de los usuarios. Esta es una opción utilizada por ejemplo por StrongCoin . El sitio web puede obtener sus saldos de servicios como Block Explorer , descifrar sus claves en su computadora y permitirle crear transacciones allí también. Un modelo interesante ya que no almacena todas las claves privadas en una billetera de fácil acceso para robar.

Hay muchas preocupaciones que uno debe tener en cuenta al implementar una billetera electrónica, principalmente la seguridad de sus fondos, etc., pero ese es un tema para otra pregunta.

En cuanto a por qué no son de código abierto, bueno, personalmente quiero ganar algo de dinero con mi trabajo, así que guardo el código fuente para mí y para cualquiera que me comisione para crear uno para ellos. Otras razones para no optar por el código abierto pueden ser evitar la competencia o no exponer algunas posibles fallas de seguridad en el propio sistema.

Si alguien desea compartir su trabajo conmigo, se lo agradezco. Pero no espero que otros estén obligados a compartir su trabajo.