Estoy tratando de diseñar un sistema que me permita aceptar Bitcoins en mi sitio web. Me gustaría usar bitcoind o bitcoinj. Sin embargo, tengo muchas preguntas con respecto a esta configuración.
Para su información, ya leí preguntas similares en este sitio web y no he recibido mi respuesta.
Bitcoinj:
Bitcoind:
Estoy planeando hacer lo siguiente:
1) El usuario genera la dirección en mi sitio web, envía BTC.
2) Comienzo a sondear 'listunspent' cada X minutos. Cuando veo que el TX obtuvo N confirmaciones, envío el dinero a la cámara frigorífica. También pongo dinero en la cuenta del remitente en mi sitio web.
3) Ahora, ¿cómo me deshago de esta dirección? Parece que estas direcciones se acumularán y romperán bitcoind después de algún momento.
He leído mucho sobre esto pero nadie explica este aspecto. Simplemente giran en torno al problema.
En realidad he hecho esto.
Lo que yo diría es que si está planeando hacerlo usted mismo, requiere algo de tiempo y experiencia si realmente desea implementar una solución personalizada que pueda integrarse con su plataforma web. Investigué un poco y al final así es como lo hice.
Yo uso Bitcoind
Se ejecuta en un servidor privado alejado del servidor web. En el servidor privado, hay varias billeteras cifradas que se ejecutan en diferentes puertos con diferentes cuentas de usuario, cada una de ellas ejecuta el deamon RPC que solo responde a SSL desde el host local.
Los usuarios tienen una cuenta en la aplicación web, cuando se crean, se les asigna una de las billeteras privadas y se les asigna una cuenta en esa billetera.
La aplicación web envía una solicitud RPC para obtener una dirección utilizando una cola de mensajes que escucha un proceso en el servidor privado. Esto emite una nueva dirección para el pago y la coloca en la base de datos de aplicaciones web.
Cuando queremos aceptar el pago mostramos la nueva dirección al usuario en la página web
En el servidor privado, un deamon se ejecuta cada minuto más o menos para que las llamadas se reciban por dirección -minconf con las direcciones que hemos mostrado a los usuarios para recibir el pago.
cuando ve un nuevo pago, actualiza la base de datos del servidor web con el registro del pago.
Para hacerlo más complicado pero seguro, la comunicación también está encriptada y los detalles de la transacción se firman utilizando un secreto compartido entre el servidor web y el proceso del demonio de la billetera. Entonces, por ejemplo, la aplicación web no considerará el pago como aceptado hasta que vea una transacción firmada en su base de datos y el demonio no colocará una allí hasta que haya visto el número mínimo de confirmaciones de transacciones en la red.
Me tomó un par de días implementarlo, pero tuve una gran ventaja inicial. La forma más fácil es ir con uno de los proveedores de pagos que han hecho el trabajo duro por usted, a menos que planee convertirse en uno de ellos.
Hay varios otros gotyas que debe tener en cuenta ... por ejemplo, mantener una copia de seguridad segura de las billeteras remotas, mantener preparado el conjunto de direcciones en las billeteras remotas y asegurarse de haber realizado una copia de seguridad de la billetera después de prepararla. Almacenar las contraseñas de la billetera para que no se bloquee y no pueda cambiarlas.
Lo que hago es tener un enfoque de múltiples firmas en el que la mitad de la frase de la billetera se guarda en el binario del daemon para que el desarrollador pueda obtenerla. La otra mitad la ingresa en tiempo de ejecución el tipo de soporte. Ninguno de ellos tendría la frase de contraseña completa, así que no puedo robar la billetera y huir con ella fácilmente.
Respecto al problema de crear demasiadas direcciones y no poder eliminarlas. En ese momento, esto no es un problema para nosotros, ya que nuestra solución se escalará a medida que obtengamos más usuarios, podemos crear más billeteras.
En cuanto al almacenamiento en frío, no estoy completamente convencido de que esto nos brinde más seguridad que la que tenemos ahora sin darnos más problemas asociados con la gestión de la parte fría del almacenamiento. Por el momento es un juego de números. donde si solo tenemos $ 5000 en una billetera, probablemente no valga la pena. Si tenemos $ 3 millones en una billetera, primero estaríamos encantados de que nuestro negocio fuera tan exitoso. Luego, probablemente invirtamos en un centro de datos privado más seguro, algunos servidores nuevos y algunas personas de seguridad muy inteligentes.
¿Cuántas direcciones puede administrar razonablemente bitcoind?
no es la cantidad de direcciones lo que importa, sino la cantidad de transacciones que entran y salen de esas direcciones lo que puede estresar al servidor.
¿Es una buena idea crear toneladas de direcciones y hacer que Bitcoind las vigile todas?
Si lo tiene bien organizado en una base de datos o en algún otro archivo, hágalo.
¿Con qué frecuencia debo 'vaciar' la billetera? No tiene sentido para mí mantener la misma billetera todo el tiempo, ya que ese archivo crecerá enormemente con el tiempo.
alguien dijo que tengo una billetera con muchas transacciones. Es alrededor de 200M. y cada billetera vacía tarda 4 segundos y bloquea las llamadas JSON RPC. de github. Entonces, a menos que pase 200 millones de transacciones, no se preocupe por el lavado.
en lo que respecta a su segunda parte, ¿por qué no usar una interfaz de bitcoin de código abierto como coiniv? De esa manera, no tiene que preocuparse de que el cliente genere nuevas direcciones de bitcoin, simplemente intégrelo con coiniv, que ya tiene una API.
Pude hacer que esto funcionara con ayuda externa (le pagué con Bitcoin).
http://www.bitcoinmonitor.net/
Supervisa la cadena de bloques para los pagos a una dirección que proporcione (utilizo una dirección de almacenamiento en frío para que nunca esté expuesta a los piratas informáticos). Cuando llega un pago, envía los detalles y luego puedo procesar los datos recibidos.
bitcoind es una aplicación muy grande
Deberías probar esto por ti mismo antes. Actualmente estoy tratando de probar el ataque de diccionario. 100k direcciones hechas mi wallet.data 50mb . Después de los primeros 50k, la velocidad de agregar una nueva dirección disminuyó radicalmente.
No hay opción para eliminar la dirección de wallet.dat por razones seguras, para evitar pérdidas.
Puede mirar pywallet , este pequeño script de python puede volcarlo wallet.daten texto sin formato. Probablemente, volver de simple a binario no sea una tarea difícil, incluso para un programador joven.
Parece que la API lateral, lo que ha mencionado @mulllhausen, es la mejor solución ligera.
Mire vanitygen , puede generar direcciones de vanidad por solicitud del usuario ajax + cgi y verificar por blockchain.info apiconfirmación, y enviar un correo electrónico a su caja de trabajo con privkey.
Sin embargo, no sé qué tipo de intercambios de ofuscación usaron, como cryptsy o mtgox. De todos modos, parece que mantener vivo el demonio bitcoind predeterminado en el servidor web no es una buena idea.
Si realmente desea usar bitcoind en lugar de un procesador de pagos y tiene un volumen que una sola instancia de bitcoind no puede manejar (digamos, 5 cifras de direcciones), entonces tendrá que crear un clúster. Use una base de datos para realizar un seguimiento de qué direcciones se encuentran en qué instancia de bitcoind.
Una aplicación de vanitygen podría ser útil para crear direcciones y esperar un pago antes de enviar la dirección a una billetera bitcoind para evitar llenar los servidores con billeteras sin usar.
Existen algunas herramientas para verificar los saldos de las direcciones de Bitcoin sin tener que importarlas a bitcoind (y sin revelar la clave privada de las herramientas).
Debe consultar http://bitpay.com o http://coinbase.com . Ellos alojan el procesador de pagos por usted.
muro
abelgo
alexg