|
barruka (OP)
|
 |
December 15, 2013, 10:30:56 AM |
|
Como no tenemos un subforo de desarrollo en español, pongo aquí el mensaje porque no se dónde ponerlo, si lo tengo que mover se mueve o lo que sea, no problem. Pensando en una posible utilización del BTC para recibir/enviar pagos a nivel empresa, es decir para ventas a clientes y devoluciones a clientes, ahora mismo estoy con una hoja en blanco: no tengo mucha idea de cómo funciona técnicamente el protocolo del BTC y voy a empezar a buscar la info lógicamente en inglés en su wiki, además de "usar el puto google"  Ahora bien para desarrolladores de software que estén trabajando con BTC y lo conozcan, yo soy desarrollador y tengo un gran defecto: creo que "para dormir a gusto me tengo que hacer yo mismo la cama". Por tanto aunque hay mucho código opensource en la red, a mí me gusta empezar con el IDE en blanco y picar mis propias líneas de código. Lógicamente voy a usar las librerías disponibles ya desarrolladas, no voy a ponerme a desarrollar hard coded el envío de info a la red BTC byte a byte. Pero sí quiero desarrollar la integración para la automatización del proceso, es decir, no quiero tener que abrir el monedero, crear una dirección y estar mirando hasta que vea la transacción. Entonces, el análisis que estoy pensando de funcionamiento de la integración es: 1. Cliente hace una compra e indica que quiere pagar con BTC. Le muestro importe total a pagar convertido de EUR a BTC. ¿ Qué exchange debería utilizar para obtener la tasa de cambio que más refleje el valor del mercado ? Creo que lo más correcto sería utilizar el valor del día anterior, no calcularlo a cada segundo ya que según fluctuara el mercado podría perjudicar mucho o beneficiar mucho al cliente, con o sin su conocimiento. 2. Genero una dirección BTC única (ADDRESS_ORDER) y su clave privada para ese pago ya que no quiero que mi competencia conozca los BTC que voy recibiendo. ¿ Cuando el cliente me envíe dinero desde su wallet (bien local u online) (ADDRESS_CUSTOMER) a mi dirección BTC ADDRESS_ORDER podría pedir expresamente que no tenga comisiones/fees ? Si esto es posible, ¿sin fees cuanto tiempo puede pasar hasta que la transacción tenga la primera confirmación en la cadena de bloques? 3. Como es el cliente el que me envía los BTC, no querría pedirle el id de transacción, por lo que ¿puedo preguntarle a la cadena de bloques que me diga las transacciones que tiene ADDRESS_ORDER y consultar las confirmaciones de cada transacción? --------------- A nivel funcionamiento del protocolo BTC: a. ¿veis lagunillas en el análisis del proceso planteado o es el proceso correcto? b. ¿que source de información creéis que tengo que estudiar? Gracias por anticipado. |
|
|
|
|
|
vitruvio
|
|
December 15, 2013, 12:34:00 PM |
|
Como no tenemos un subforo de desarrollo en español, pongo aquí el mensaje porque no se dónde ponerlo, si lo tengo que mover se mueve o lo que sea, no problem. Pensando en una posible utilización del BTC para recibir/enviar pagos a nivel empresa, es decir para ventas a clientes y devoluciones a clientes, ahora mismo estoy con una hoja en blanco: no tengo mucha idea de cómo funciona técnicamente el protocolo del BTC y voy a empezar a buscar la info lógicamente en inglés en su wiki, además de "usar el puto google" Ahora bien para desarrolladores de software que estén trabajando con BTC y lo conozcan, yo soy desarrollador y tengo un gran defecto: creo que "para dormir a gusto me tengo que hacer yo mismo la cama". Por tanto aunque hay mucho código opensource en la red, a mí me gusta empezar con el IDE en blanco y picar mis propias líneas de código. Lógicamente voy a usar las librerías disponibles ya desarrolladas, no voy a ponerme a desarrollar hard coded el envío de info a la red BTC byte a byte. Pero sí quiero desarrollar la integración para la automatización del proceso, es decir, no quiero tener que abrir el monedero, crear una dirección y estar mirando hasta que vea la transacción. Entonces, el análisis que estoy pensando de funcionamiento de la integración es: 1. Cliente hace una compra e indica que quiere pagar con BTC. Le muestro importe total a pagar convertido de EUR a BTC. ¿ Qué exchange debería utilizar para obtener la tasa de cambio que más refleje el valor del mercado ? Creo que lo más correcto sería utilizar el valor del día anterior, no calcularlo a cada segundo ya que según fluctuara el mercado podría perjudicar mucho o beneficiar mucho al cliente, con o sin su conocimiento. 2. Genero una dirección BTC única (ADDRESS_ORDER) y su clave privada para ese pago ya que no quiero que mi competencia conozca los BTC que voy recibiendo. ¿ Cuando el cliente me envíe dinero desde su wallet (bien local u online) (ADDRESS_CUSTOMER) a mi dirección BTC ADDRESS_ORDER podría pedir expresamente que no tenga comisiones/fees ? Si esto es posible, ¿sin fees cuanto tiempo puede pasar hasta que la transacción tenga la primera confirmación en la cadena de bloques? 3. Como es el cliente el que me envía los BTC, no querría pedirle el id de transacción, por lo que ¿puedo preguntarle a la cadena de bloques que me diga las transacciones que tiene ADDRESS_ORDER y consultar las confirmaciones de cada transacción? --------------- A nivel funcionamiento del protocolo BTC: a. ¿veis lagunillas en el análisis del proceso planteado o es el proceso correcto? b. ¿que source de información creéis que tengo que estudiar? Gracias por anticipado. Supongo que hablas de una tienda web, si es algún paquete conocido puede que ya haya pasarelas de pago para btc. De todas formas básicamente el proceso que se hace es lo que dices: -sobre el precio pues una media diaria de precio, mtgox el precio de referencia mas usado, aun con la volatilidad de precios que tienes si no usas alguna gestor de pagos como bitpay que te haga el cambio instantáneo de precios a € (a ti te ingresan los €) te arriesgas a pillarte los dedos si el mercado baja. -sobre las direcciones si, lo normal es generar una por cliente o por pago si quieres (todo con el mismo cliente bitcoind), pero la dirección btc del cliente no deberías controlarla, de hecho es probable que el mismo cliente en su cartera tenga varias direcciones y que en el mismo pago recibas los fondos de varias e ellas, el cliente bitcoin lo hace automáticamente, las fees las paga el que te manda los btc así que él verá si paga y cuanto, de ello dependerá en gran medida cuanto tarda en confirmarse la transacción, el id de transaccóon tampoco te lo tendría que dar, eso lo sacas de tu cliente btc cuando recibas el pago. Mas que la mecánica del proceso lo delicado es el tema de tener el cliente btc y la billetera accesible desde el servidor web para generar las direcciones en el instante, si te hackean la web estás perdido, tendrías que ver como gestionar todo esto sin tener la billetera accesible desde el server web. Un saludo |
|
|
|
|
|
barruka (OP)
|
|
December 15, 2013, 03:45:34 PM |
|
Sí, sería para varias tiendas online pero como decía no querría utilizar bitpay ni similares, quiero hacerlo lo más propio posible. Por la seguridad no es algo que me preocupe ahora mismo ya que no creo que reciba un volumen significativo de pagos en un primer momento, por el tipo de productos que venden las tiendas online, el BTC ya te digo que el 99,9% de los clientes no saben ni lo que es. Pero quiero integrarlo a nivel marketing-publicidad y por darles en los morros a la competencia que siempre viene bien ser el primero en tu sector en utilizar una nueva herramienta / tecnología. Como toda nuestra tecnología es propia no hay bugs ni backdoors conocidas, sólo tenemos las propias del SO. Y para el monedero podríamos tener un servidor dedicado corriendo DEBIAN a pelo con el cliente bitcoin modo server al que le haríamos las llamadas desde los distintos servidores web con json. A este debian server monedero, se le cierran todos los puertos por firewall, sólo se podría acceder desde la IP fija de la oficina para puerto de control remoto y desde los servidores web para los puertos del json. No estaría accesible en Internet, ni el password de root sería admin ni 1234 Que seguro si algún hacker "malicioso" (por no decir HDLGP) se empeña nos toca las pelotas pero sólo podría acceder a nuestras btc address únicas que han recibido los pagos de las que aún no se hubieran tansferido los BTC a la cuenta AHORRO_BTC que no se habría creado en el monedero debian, sino offline y sólo impresa en papel dirección y clave privada. He visto que blockchain.info hace esto de forma gratuíta con una API, por lo que también podría ser otra opción mucho más sencilla y económica para empezar, ya que ni server dedicado ni preocupación por seguridad. No se... sigo pensando intentando darle forma al proyecto. |
|
|
|
|
|
fernarios
|
|
December 15, 2013, 04:27:05 PM |
|
Por la seguridad no es algo que me preocupe ...
Dejé de leer ahí. |
|
|
|
|
|
barruka (OP)
|
|
December 15, 2013, 05:08:10 PM |
|
Por la seguridad no es algo que me preocupe ...
Dejé de leer ahí. gracias por tu aportación técnica fernarios, muy bien explicada y desarrollada gracias por tu crítica constructiva, siempre es un placer aprender de grandes profesionales |
|
|
|
|
|
vitruvio
|
|
December 15, 2013, 05:20:21 PM |
|
Sí, sería para varias tiendas online pero como decía no querría utilizar bitpay ni similares, quiero hacerlo lo más propio posible. Por la seguridad no es algo que me preocupe ahora mismo ya que no creo que reciba un volumen significativo de pagos en un primer momento, por el tipo de productos que venden las tiendas online, el BTC ya te digo que el 99,9% de los clientes no saben ni lo que es. Pero quiero integrarlo a nivel marketing-publicidad y por darles en los morros a la competencia que siempre viene bien ser el primero en tu sector en utilizar una nueva herramienta / tecnología. Como toda nuestra tecnología es propia no hay bugs ni backdoors conocidas, sólo tenemos las propias del SO. Y para el monedero podríamos tener un servidor dedicado corriendo DEBIAN a pelo con el cliente bitcoin modo server al que le haríamos las llamadas desde los distintos servidores web con json. A este debian server monedero, se le cierran todos los puertos por firewall, sólo se podría acceder desde la IP fija de la oficina para puerto de control remoto y desde los servidores web para los puertos del json. No estaría accesible en Internet, ni el password de root sería admin ni 1234 Que seguro si algún hacker "malicioso" (por no decir HDLGP) se empeña nos toca las pelotas pero sólo podría acceder a nuestras btc address únicas que han recibido los pagos de las que aún no se hubieran tansferido los BTC a la cuenta AHORRO_BTC que no se habría creado en el monedero debian, sino offline y sólo impresa en papel dirección y clave privada. He visto que blockchain.info hace esto de forma gratuíta con una API, por lo que también podría ser otra opción mucho más sencilla y económica para empezar, ya que ni server dedicado ni preocupación por seguridad. No se... sigo pensando intentando darle forma al proyecto. Con la api de blockchain podrías generar nuevas direcciones como si fuera el cliente bitcoin, pero delegas toda la seguridad fuera, si crees que su seguridad (paranoia) es mayor a la que tu necesitas, pues te ahorras mucho en desarrollo y mantenimiento del segundo servidor y la billetera offline. |
|
|
|
|
|
mauricioltc
|
|
December 16, 2013, 02:49:51 AM |
|
amigo barruka yo te iba decir lo mismo puedes acojer alguna de estas api sea de btc-e o de cryptsy o de ecoins-e
creo que hacer tu propia api te llevara mas tiempo pero lee esto
si tu principal coin es bitcoin cuando ya transfiero de okpay, o de virwox o de blockchain a btc-e es de lujo solo toma 3 minutos en confirmarse maximo 7 minutos asi que las api de btc-e para recibir pagos te venderia bien
ahora personalmente probe un pago con la api de cryptsy desde ecoins-e y que problema amigo me ha sacado canas es muy inestable por ahora de los otros no hablo porque no tengo conocimiento no se como ira la api de bitstamp
ahora en cuanto a seguridad algo muy bueno es la confirmacion por email esto ayuda algo, tambien puedes pagar para proteger tu server de ataques de denegacion de servicios, hay muy buenas startups que ofrecen super vpns para proteger tu server en fin
ir por cuenta propia sinceramente en castellano encontraras muy poca info sobre todo para crear tu propia api
te deseo exitos en tu nuevo proyecto amigo barruka
|
|
|
|
|
|
barruka (OP)
|
|
December 22, 2013, 04:42:07 PM |
|
Teniendo en cuenta que una transacción sin comisión podría quedar huérfana y no ser incluida en la cadena de bloques (ya que por lo que he leído los mineros pueden decidir que transacciones procesar), ¿Podría yo tener un minero que minara esta transacción concreta hasta que le sacara al menos la primera confirmación?
|
|
|
|
|
LuisCar
Legendary
 Offline
Activity: 1820
Merit: 1017
|
|
December 22, 2013, 05:11:08 PM |
|
No se minan transacciones, se minan bloques.
|
|
|
|
|
barruka (OP)
|
|
December 22, 2013, 05:32:02 PM |
|
Y como es que he leído que los mineros pueden decidir cuales minar? Leen el bloque, ven las transacciones que llevan y sus comisiones y si les interesan lo procesan?
Siento ser tan ignorante en cuanto al funcionamiento
|
|
|
|
|
|
vitruvio
|
|
December 22, 2013, 06:47:01 PM |
|
No vas mal encaminado, realmente un bloque es un conjunto de transacciones, el bloque no está preestablecido y los mineros miran dentro, son los mineros los que eligen las transacciones sin confirmar en la red y van montando su bloque, pero lo que no vas a poder es minar un bloque que incluya solo una transacción, como poder puedes pero necesitarías TeraHashes de potencia para conseguirlo, es verdad que los mineros (el software de las pool) eligen que transacciones a añadir al bloque que están buscando, pero realmente no son tan discriminatorias que dejen fuera las de fee 0 por regla, al final entrará esa transacción.
Un saludo
|
|
|
|
|
LuisCar
Legendary
Offline
Activity: 1820
Merit: 1017
|
|
December 22, 2013, 09:25:21 PM |
|
La pega es que no siempre acaban entrando las transacciones de muy poco montante con 0 btc de comisión.
|
|
|
|
|
vitruvio
|
|
December 22, 2013, 09:43:18 PM |
|
La pega es que no siempre acaban entrando las transacciones de muy poco montante con 0 btc de comisión.
Pues no se, yo creo que si, o una transacción se acaba perdiendo sin más? o tienen caducidad? https://blockchain.info/es/unconfirmed-transactions?offset=950Aquí la transacción más antigua es del día 20. Ya me dirás como se hace esa purga. |
|
|
|
|
|
barruka (OP)
|
|
December 22, 2013, 10:08:01 PM |
|
joder esto es complicado de cojones  entonces ya que vosotros controlais del tema: ¿podría de alguna forma agilizar mis propias transacciones para que tuvieran la primera confirmación? la preocupación es por recibir el pago, si un cliente me hace un pago con bitcoin, la idea es que lo haga él desde su wallet por lo que lo hará sin fee entonces, imaginemos que hace un pedido a las 17:00 y lo paga con bitcoin, la agencia de transporte pasa a recoger los paquetes a las 18:00 ya no tengo el control, y si esa transacción queda huérfana, el cliente se queda con sus BTC y con el producto gratix que si, que le podré pedir que me haga la tx de nuevo... pero ya me entendeis |
|
|
|
|
|
vitruvio
|
|
December 22, 2013, 10:17:16 PM |
|
joder esto es complicado de cojones entonces ya que vosotros controlais del tema: ¿podría de alguna forma agilizar mis propias transacciones para que tuvieran la primera confirmación? la preocupación es por recibir el pago, si un cliente me hace un pago con bitcoin, la idea es que lo haga él desde su wallet por lo que lo hará sin fee entonces, imaginemos que hace un pedido a las 17:00 y lo paga con bitcoin, la agencia de transporte pasa a recoger los paquetes a las 18:00 ya no tengo el control, y si esa transacción queda huérfana, el cliente se queda con sus BTC y con el producto gratix que si, que le podré pedir que me haga la tx de nuevo... pero ya me entendeis La única forma de agilizarlo es que pague fee. Aun así su inclusión en un bloque o en otro posterior no tienes forma de controlarlo. |
|
|
|
|
aTg
Legendary
Offline
Activity: 1358
Merit: 1000
|
|
December 22, 2013, 11:56:54 PM |
|
No me he leído mucho el hilo pero por los dos últimos post si lo que quieres es 0% de comisión y estar seguro de que vas a obtener los BTC al momento, puedes idear un software con el que el cliente te envíe la clave privada que contenga el importe a pagar, la transferencia es instantánea puesto que no hay transferencia realmente y tu puedes al momento comprobar que esa clave controlar la cantidad de BTC acordados.
Siempre me ha parecido que para solucionar el problema de los pagos instantáneos lo mejor es transferirse las claves privadas, es como pagar con un billete en mano o un cheque al portador.
|
|
|
|
|
LuisCar
Legendary
Offline
Activity: 1820
Merit: 1017
|
|
December 23, 2013, 01:49:15 AM
Last edit: December 23, 2013, 02:10:15 AM by LuisCar |
|
Vamos a ver, el problema se da en ocasiones con transferencias de muy poco montante y sin comisión, al no tener comisión y ser tan pequeñas tienen una prioridad muy baja por lo que pueden tirarse mucho tiempo en la cola de espera para entrar en un bloque, ya que constantemente aparecen nuevas transacciones con prioridad más alta que la suya. Eventualmente, si no entran en un bloque acaban "desapareciendo", evidentemente los bitcoins no han salido nunca de la dirección origen (esto ocurre cuando la transacción pasa a formar parte de la cadena de bloques porque un minero/pool la haya incluido en un bloque resuelto). Creo que el cliente desde el que se ha realizado la transacción continúa remitiendo la misma a la red, pero si dicho cliente se cierra, con el tiempo la transacción acaba desapareciendo. Desde luego me ha ocurrido y sé de algún otro caso de transacciones en el limbo sin resolver nunca. La solución es fácil, solicitar que el pago incluya comisión (sobre todo si es de una cantidad pequeña, de céntimos o milibitcoins) y verificarlo antes si deseamos aceptarlo con cero confirmaciones, si no lleva comisión nos esperaremos a que dicha transacción se confirme. La verdad es que no veo tan complicado que la gente se acostumbre a enviar las transacciones con el equivalente a un par de céntimos de euro de comisión, sobre todo si se quiere inmediatez. Se puede poner en la pagina de pago una leyenda del tipo "Si desea un procesado rápido de su pedido, por favor, incluya al realizar el pago una pequeña comisión minera". De algo tendrán que vivir los mineros en un futuro, digo yo. No me he leído mucho el hilo pero por los dos últimos post si lo que quieres es 0% de comisión y estar seguro de que vas a obtener los BTC al momento, puedes idear un software con el que el cliente te envíe la clave privada que contenga el importe a pagar, la transferencia es instantánea puesto que no hay transferencia realmente y tu puedes al momento comprobar que esa clave controlar la cantidad de BTC acordados.
El problema es que luego tienes que hacer la transacción desde la clave privada recibida hasta otra que controles tú, ya que de no hacerlo, te puedes encontrar en la situación de que el comprador te la vacíe en algún momento futuro, por lo que pienso que es mejor que la realice directamente el comprador. Además enviar la clave privada supone un riesgo añadido, y es que haya terceros que puedan acceder a ella durante el proceso de envío, por lo que tendríamos que enviarla cifrada, etc. lo que complica todo muchísimo más. Además este método deja fuera a las personas menos técnicas que no saben bien ni siquiera qué son las claves privadas y que será un tipo de usuario que debería crecer con el tiempo si Bitcoin acaba teniendo mucho éxito. |
|
|
|
tiozes
Legendary
Offline
Activity: 861
Merit: 1000
“Create Your Decentralized Life”
|
|
December 23, 2013, 01:49:29 AM |
|
No me he leído mucho el hilo pero por los dos últimos post si lo que quieres es 0% de comisión y estar seguro de que vas a obtener los BTC al momento, puedes idear un software con el que el cliente te envíe la clave privada que contenga el importe a pagar, la transferencia es instantánea puesto que no hay transferencia realmente y tu puedes al momento comprobar que esa clave controlar la cantidad de BTC acordados.
Siempre me ha parecido que para solucionar el problema de los pagos instantáneos lo mejor es transferirse las claves privadas, es como pagar con un billete en mano o un cheque al portador.
Si no lo he entendido mal seria como si por ejemplo se tienen 5 btcs en un paper wallet, el tio te pasa la clave privada y ya lo tienes, solo tienes q transferirlo, pero ya estaria en tu poder no? Saludos |
|
|
|
LuisCar
Legendary
Offline
Activity: 1820
Merit: 1017
|
|
December 23, 2013, 01:53:37 AM
Last edit: December 23, 2013, 02:17:51 AM by LuisCar |
|
Si no lo he entendido mal seria como si por ejemplo se tienen 5 btcs en un paper wallet, el tio te pasa la clave privada y ya lo tienes, solo tienes q transferirlo, pero ya estaria en tu poder no?
Correcto, estaría en el poder de "al menos" dos. A continuación te tocaría hacer a ti la transacción. Postdata: Acabo de ver precisamente como tras unas 48 horas la red ha olvidado una transacción que no se ha llegado a confirmar nunca al ser de un pequeño importe (milibitcoins) y no llevar comisión. https://bitcointalk.org/index.php?topic=172530.msg4088395#msg4088395 |
|
|
|
|
barruka (OP)
|
|
December 23, 2013, 09:22:16 PM |
|
Pues no me parece bien!!!
Pensando en un pago en BTC entre 15 y 100 eur, que por los menos son los que procesaría yo, además a medida que el precio del BTC vaya subiendo estos pagos en BTC serán más reducidos
Sobre el fee de la tx, no creo que sea el cliente el que tenga que decir que cuanta comisión quiere pagar.
Chicos no penséis como linux, que luego pasa lo que pasa y los usuarios no lo utilizan, sólo los frikis informáticos (y me incluyo tanto en lo de friki como en lo informático). Yo pienso en una pasarela de pago lo más simple posible para el user, a la hora de pagar, y esto de que la tx se pueda quedar fuera de la blockchain da miedo, mucho miedo
Además, el cliente puede poner una fee de 0.0001 y que a los mineros NO les parezca bien. Lo que me raya es que los mineros SI puedan decidir qué tx incorporan al bloque que están minando y yo no pueda tener un minero exclusivo para incorporar al bloque que esté minando las tx que quiera, no lo entiendo.
Sigo leyendo y pensando....
|
|
|
|
|
|
