Topic: Problema con trasacción (Read 3799 times)

En realidad, no la cancela nadie (recordad que Bitcoin es descentralizado y gracias a eso nadie puede cancelar, censurar o inhibir a nadie). Digamos que su transacción no es distribuída por la red porque los primeros nodos a los que llega, si tienen la cadena de bloques actualizada, la detectan como fraudulenta y rechazan reenviarla. La detectan como fraudulenta porque el hacker ya los transfirió a su cuenta tiempo atrás. Su cliente_qt intentará volver a reenviarla hasta que la actualización de su cadena de bloques le "ponga al día" con la infeliz noticia de que sus 12 bitcoins ya no están en la dirección que él creía. Es más que nada un problema de sincronización. Si el usuario hubiese esperado a tener actualizada completamente la cadena de bloques en su equipo, el cliente no le hubiera permitido lanzar esa transacción.

Disculpad la respuesta tardía.
¡Muchas gracias polvos!

Me ha servido muchísimo la explicación y te agradezco muchísimo que te hayas tomado el tiempo para explicarlo.

Entonces he de entender que la transacción de OP quedará en algún momento cancelada, pues no dispone ya de los fondos provenientes de las Tx anteriores ya que estos se han gastado en el robo que ha sufrido. ¿Cierto?

Muy buenas información polvos me sirvió para indagar y entender muchas cosas sobre las transacciones en modo raw que casualidad que estaba leyendo el hilo 

Gracias campeón! 

Ahí le has dado, nikkus

Po zi! GRACIAS POLVOS!!!

Sobre seguridad:

Creo que el mas relevante es, si tienes previsto que vas a recibir bitcoins con cierta frecuencia, igual no estaria demas tomar ciertas precauciones.

1) Podrías crear una bitcoin address, copiar la dirección publica(q es la que necesitas para recibir los bitcoins), y tener el monedero bien cifrado, ademas de eso, hacer un backup del wallet.dat(o de la clave privada) y mantenerlo a MUY buen recaudo, una vez echo eso, DESINTALE la billetera de tu PC, y controla lo que recibes por el blockexplorer.com. Y solamente cuando necesites utilizar ese dinero de alguna manera, vuelves a restaurar el backup que ya se hizo con anterioridad.

2) Mantenga su S.O.(Sistema Operativo) seguro. Soy un linuxero, pero no hace falta ser linuxero para tener su sistema limpio, para mantener un minimo de seguridad en tu sistema, mantenlo actualizado, garantiza que quien lo esté utilizando a parte de ti(ej.: Tu mujer, hijos o quien sea) NO TENGA permisos de administración, vamos que no pueda ni instalar nada sin TU permiso. Manten tu SO y su respectivo antivirus(anti: Malware, rootkit y etc) al día.

3) A pesar de todo eso:

- NO cliques en emails sospechosos: Un amigo tuyo que mal sabe el propio Español te envia un email en perfecto inglés! Entonces NO CLIQUES! Un amigo tuyo que no sabe mas que hablar de futbol, de repente te envia un email hablando maravillas sobre "no-se-que" sistema piramidal! NO CLIQUES! y un LARGOOOOO etc... Si utilizamos un pelin que sea del sentido común, nos libramos de muchas cosas.

Y por ultimo, si has recibido suficientes BTC en la dirección destinada para ello, y quieres utilizarlo, pero crees q tu SO esta comprometido. NO ABRAS EXCEPCIONES! Buscate un ordenador que NO este infectado y desde él accede a tu billetera...

Recuerda eso:
Si sospechas de tu SO! Deja de suponer y busca otra opción! En la duda, que no te quede en duda!

P.D.: Eso es solo para complementar lo que ya han dicho y muy bien dicho los compañeros anteriormente!

Excelente explicación sobre el diseño del protocolo bitcoin, Polvos. Gracias por ella.

Y la mia! Y solo pararía cdo la chiquilla esa tbm pare!

Wow genial ... bien por el admin del pool.

Gracias por la explicación polvos, ha sido muy interesante.

Muy buena la aclaración 

Como bien dices, estos errores han alegrado a los mineros mas de una vez  . La verdad es que me sorprendió el desenlace del esta situación en un hilo reciente ( al que  creo que haces referencia ), ya que pudo contactar con el admin del pool que resolvió el bloque( con su mas que generosa comisión) y recupero casi el 92% del importe.

Mi reacción hubiera sido mas parecida a esta:

Bueno, pues voy a poner ya en qué consiste el error de la transacción:

Antes os he comentado que la suma de los bitcoins de los inputs debe ser igual o superior a la de los outputs. Todos los bitcoins que superen la cantidad de los outputs pasarán a ser comisiones de transacción. En el ejemplo sólamente hay un output (los 467 euros que son transferidos hasta la cuenta corriente de la compañía de seguros).

Así que, si la transacción que utilizo como input (el ingreso de mi nómina en este caso) es superior a los 467 euros que voy a transferir a la compañía de seguros, la cantidad restante va a parar al minero que la incorpore a un bloque en forma de comisión de transacción.

Es por esto por lo que algunos usuarios están pagando muy caros los jueguecitos con las raw transactions. Algunos han llegado a pagar más de 100 BTC en forma de comisión de transacción.

La forma de evitar que esto suceda es poner siempre como mínimo dos outputs. Uno con el pago que deseamos realizar (la compañía aseguradora del vehículo en el ejemplo) y otro output con el "cambio" para que los bitcoins restantes vuelvan a alguna dirección de mi posesión (mi cuenta corriente en este caso).

En el caso del ejemplo y suponiendo que el abono de mi nómina fuese de 1800€, debería incorporar un segundo output con la dirección donde quiero que lleguen los 1800-467=1323 € de cambio. Sería así:



Dirigir el cambio a otra dirección bitcoin de nuestra propiedad lo hace automáticamente el cliente-qt. Pero hay que tener cuidado si intentamos hacer una "raw transaction" nosotros a mano para no cometer el error de pagar el cambio como comisiones de transacción.

Y aunque penséis que "nadie va a hacer una transacción fuera de los clientes habituales" os equivocáis. Es algo que va a empezar a extenderse y a generalizarse por seguridad. Esa transacción puede ser elaborada en un equipo comprometido que no disponga de las claves privadas. Después ser llevada a otro equipo con las claves privadas y aislado de internet donde será firmada, llevada de nuevo una vez firmada al equipo comprometido y transmitida a toda la red bitcoin para su validación.

De esta forma las claves privadas siempre están a salvo en un equipo aislado de internet y que símplemente se limita a firmar las transacciones previamente construidas a mano y que le llevamos con un pincho USB o con un código qr

Gracias majamalu. ¿Sabés dónde está el carísimo error que estaría cometiendo en la transacción bancaria que he puesto en modo bitcoin?

Pista: es un error crítico y muy común ahora que se ha puesto de moda el realizar transacciones manualmente fuera del cliente-qt (raw transactions)   

Gracias por tomarte el trabajo, Polvos. Lo tuyo es la docencia 

Y ahora te respondo la pregunta más complicada de las tres que has formulado. ¿Qué pasaría si el usuario recibe un pago en su billetera mayor de 12 BTC?¿Se gastarían inmediatamente en la operación anterior?

NO SE GASTARÍAN.

Es más, ni siquiera se gastarían en la operación anterior aunque los nuevos BTC fueran recibidos por la misma dirección desde la que se ha ordenado el pago en la operación anterior.

¿Por qué? Pues porque Bitcoin no funciona como una cuenta bancaria tal y como todos tenemos en mente. El protocolo Bitcoin no funciona tal y como el interface del cliente-qt nos hace entender. No tenemos una "cuenta" con la que hacer un balance contable y decir "las gallinas que entran por las que salen". De hecho ese balance contable no puede hacerse ni siquiera dentro de una misma dirección bitcoin.

Para poder entender lo que digo debemos, ante todo, comprender cómo es una transacción bitcoin según el protocolo.

Una transacción bitcoin es esto:


Por lo tanto, cualquier pago que hacemos con bitcoin, esto es, cualquier transacción. Consta de dos partes muy diferentes. Un input y un output.

El input de la transacción consta, por así decirlo, de la referencia a una transacción anterior (previous tx) y de la demostración fuera de toda dudas de que estás autorizado a transmitir esos bitcoins a otras direcciones bitcoins (scriptsig).

Por lo tanto, entender lo que significan los inputs no es muy difícil. Hace falta una referencia a una transacción previa porque, al igual que en la economía doméstica, uno sólamente está autorizado legalmente a gastar un dinero que previamente le ha llegado. Demuestras que los bitcoins han llegado a tu dirección bitcoin poniendo en la variable previous_tx el identificador de la transacción con la que te los hicieron llegar y con scriptsig firmas con la clave privada de la dirección bitcoin para demostrar que eres el legítimo propietario de ellos. Así que con los inputs estamos anunciando qué bitcoins vamos a transferir y demostramos que somos los propietarios legítimos de las direcciones bitcoin desde las que van a salir.

Los output dicen la cantidad de bitcoins, medidos en satoshis, que van a ser transferidos (value) y las direcciones bitcoin en base 58 a la que van destinados (scriptpuvkey).

En realidad es un poco más complicado (no me meteré a explicar los tipos de transacciones que se pueden obtener según los scriptsig/scriptpuvsig que podemos obtener). Pero a grandes rasgos esa es una transacción Bitcoin.

Hay que tener en cuenta algunas cosas más:

- Podemos incorporar múltiples inputs y outputs a una misma transacción
- El valor de los bitcoins de los inputs debe ser igual o mayor que el de la suma de los outputs. Todos los bitcoins que superen el valor de los outputs pasarán a ser comisiones de la transacción.

¿Qué quiero decir con todo este rollo sobre cómo funciona el protocolo Bitcoin?

Pues que, aunque recibas más bitcoins en la dirección de tu billetera desde la que enviaste una transacción que ha quedado "en el limbo", no serán gastados automáticamente.

Y esto es así porque, aunque los nuevos bitcoins recibidos han llegado a la misma dirección bitcoin de tu billetera, tienen una "previous_tx" diferente a la de los bitcoin que pululan en la transacción que ha quedado pendiente en el limbo.

Para terminar, intentaré explicarlo con el símil de la cuenta corriente bancaria. Y seguro que me hago entender mejor:

Un pago con el protcolo bitcoin desde una cuenta bancaria sería muy diferente a lo que estamos acostumbrados. Sería algo así para el pago del seguro del coche.



Si mi madre decidiese ingresar en mi cuenta algo de dinero por mi cumpleaños, sería imposible que ese dinero fuese gastado inmediatamente ya que el previous_tx sería diferente que el del ingreso de la nómina.

Bueno, lo mejor será ir poco a poco con las dudas porque esto es muy complicado de explicar. Digamos que, con bitcoin, no enviamos dinero "de una cuenta a otra" sino que, cogemos outputs de las direcciones bitcoin de nuestra billetera, los colocamos en una transacción como inputs, los firmamos y los enviamos a las direcciones destinatarias como nuevos outputs. Seguramente me he explicado como un libro cerrado.

P.D. He cometido un error en la transferencia bancaria mode bitcoin que acabo de escribir, a ver si alguien es capaz de darse cuenta (un error que me saldría bastante caro, por cierto)

Estas son unas preguntas muy interesantes Tacticat.

Para la primera pregunta te respondo ya: si enviase 12 BTC a su wallet se los robarían inmediatamente. Si previamente cifrase la billetera y posteriormente enviase los BTC de nuevo, se los volverían a robar porque las claves privadas han sido previamente comprometidas. La solución es limpiar el ordenador de virus, borrar la billetera y así el programa generaría otra billetera nueva que inmediatamente deberíamos encriptar.

Para la tercera pregunta: no hay forma de cancelar una operación publicada en la red bitcoin. En este caso la operación no es incluida por los mineros en ningún bloque porque se trata de un intento de doble gasto. Pero podría ocurrir que, aun siendo una operación válida, se quedase mucho tiempo en espera porque no tuviese suficientes comisiones para resultar interesante para la mayoría de mineros.

La solución a ese problema sería esperar pacientemente a que algún minero al que no le importe tramitar transacciones con pocas o ninguna comisiones incorporadas la incluyera en su bloque recién minado. Otra opción sería reenviar la misma transacción pero modificada para que albergase una comisión mayor.

El cliente bitcoin-qt está diseñado para, si en un período de tiempo prudente alguna de las transacciones que ha enviado no han sido incorporadas a algún bloque, volver a reenviarlas hasta que sean añadidas por algún minero. En el ejemplo del autor del hilo, su cliente seguiría reenviando la operación hasta que la actualización de su propia cadena de bloques avisase al cliente-qt de que la operación no puede realizarse porque ya no existen en la billetera los bitcoins que el usuario intenta enviar. Y entonces las publicaciones en la red de esa transferencia parte de su cliente-qt cesarían y los nodos dejarían de recibir esas peticiones de transacción que automáticamente descartaban y se negaban a reenviar porque las detectaban como fraudulentas.

Quizás esto te sirva de consuelo: el mismo error le costó - en Junio de 2011 - 25.000 (sí: veinticinco mil) bitcoins a un único usuario. https://bitcointalksearch.org/topic/i-just-got-hacked-any-help-is-welcome-25000-btc-stolen-16457

Gracias a todos por las respuestas, solo me queda aprender del error 

Esto:


Las copias de wallet.dat no encriptadas deberían ser tratadas como material radioactivo.

Tienes que tener en cuenta que el ladrón pudo hacerse con una copia de tu cartera, en el 2011, durante los primeros días en que comenzaste a minar. En aquella época todo esto era aún muy nuevo y posiblemente mucha gente no le dio la importancia a la seguridad que requería esto. A finales de ese año el precio del bitcoin era bastante inferior y el montante de dichas cantidades no resultaba tan importante. Pero el ladrón, con una copia de la cartera (seguramente en posesión de más carteras de otros usuarios de la misma época) aguardó agazapado con ésta sincronizada esperando que recibiera fondos, en cuanto este hecho se produjo y se dio cuenta de ello, rápidamente transfirió los fondos a otra dirección que solamente él controlaba. Ésta operación la repetirá tantas veces como ocasiones en la que la cartera reciba fondos.

De modo que, aunque el primer robo de fondos se produjo en marzo de 2012, el acceso a las claves privadas de tu cartera pudo darse en el 2011, durante los primeros días en los que comenzaste a minar, puesto que para ello tuviste que crear tu dirección de pago de bitcoins para el pool de minería. En aquel momento puede que tuvieras instalado, incluso, otro sistema operativo en tu equipo y aún no le hubieras dado la importancia que requería la seguridad en bitcoin, posiblemente porque en aquellos momentos pareciera simplemente una especie de experimento informático. Desgraciadamente para ti, bitcoin siguió cobrando fuerza y año y medio más tarde aquellas monedas adquirieron un valor bastante superior al que la mayoría de los usuarios ocasionales de aquel momento estimaron.

Pregunta de novato: ¿Qué ocurriría si él enviara ahora 12+ BTC a su cartera? ¿Se gastarían inmediatamente en la transacción anterior?
¿Habría alguna manera de cancelar la transacción anterior?