Bitcoin Forum
May 16, 2021, 04:38:01 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Sobre la MALEABILIDAD  (Read 1235 times)
carlengues
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
February 14, 2014, 05:16:39 PM
 #1

Hola a todos!!.

Bueno, ya parece que el asunto de la maleabilidad parece que se va corrigiendo (por lo menos en bitstamp), pero yo sigo sin entender de que se trata.
Como siempre, aprovecho este foro para que algun alma caritativa con perfil docente y que se quede en casa esta noche de Viernes nos explique en que consiste este bug (?) en Bitcoin.

Por lo que yo he entendido hasta ahora, se trata de hacer ver que una transaccion realizada no se ha realizado. Y aqui ya empiezan a aparecer mis dudas :

Ya se sabe que una transaccion no se confirma de varias fuentes pasados 10 minutos o más. ¿como te pueden engañar en estos minutos?. Te esperas a que el protocolo confirme y punto.

¿que quiere decir que te pueden cambiar el hash de tu transferencia?.

Un saludo a todos!!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1621183081
Hero Member
*
Offline Offline

Posts: 1621183081

View Profile Personal Message (Offline)

Ignore
1621183081
Reply with quote  #2

1621183081
Report to moderator
fernarios
Hero Member
*****
Offline Offline

Activity: 616
Merit: 501



View Profile
February 14, 2014, 06:11:08 PM
 #2

¿que quiere decir que te pueden cambiar el hash de tu transferencia?.

El hash es el ID de la transacción que usualmente se usa para encontrarla en la cadena de bloques, si alguien consigue cambiarlo, ésto no afecta el hecho de que el intercambio de monedas ocurrirá sin ningún problema, pues el hash no se usa para nada más que un número de referencia de la transacción, pero sí puede afectar a algunos que tienen sistemas de seguimiento de transacciones como las exchanges. La maleabilidad sólo sirve para esconder la transacción, el estafador cambia el ID de la transacción para que el que la hizo crea que no se llegó a realizar por que no la ve agregada a ningún bloque con el ID que inicialmente generó (con la ID que registró en su log de transacciones). El que recibe el pago debe reclamar al que hace el pago (varias horas después), alegando que no ha llegado la transacción (esto es una mentira), las monedas salieron y llegaron pero NO con el ID que quedó registrado en el servicio. El prestador del servicio debe ser lo suficientemente desordenado e ingenuo como para no comprobar que el saldo efectivamente se restó, y la dirección de llegada efectivamente tiene la cantidad solicitada ingresada, el prestador del servicio repetirá la transacción, completando así la estafa.

Ésta característica se conoce desde 2011, los prestadores de servicios deberían tener métodos de comprobación de transacciones reclamadas que no dependan del ID generado al momento de crear la transacción, pues éste es maleable, de ésta forma se evita el engaño, pero como ves, no es un "bug" que mediante un exploit signifique que alguien robará monedas, se necesita de ingeniería social y de varias horas, tal vez días para completar el robo (mientras se hace la reclamación, se espera a que se atienda el ticket, y el prestador del servicio se come el cuento y repite la transacción).

Para los que no manejamos muchas transacciones diarias, es muy fácil no caer en el engaño, si alguien te dice que no ha recibido las monedas, pues vas a tu billetera y compruebas que la transacción tenga confirmaciones, o también puedes ver la dirección de llegada de las monedas en blockchain.info (o cualquier explorador de bloques) y comprobar que tus monedas sí llegaron, o puedes consultar también en blockchain.info tu dirección de salida, identificar el verdadero ID de la transacción y comprobarla. Además para cambiar el ID de las transacciones se necesita cierto poder de hasheo y otros recursos, es probable que un usuario normal nunca sea blanco de un engaño de éstos. Para los que tienen servicios masivos es un poco más difícil de evitarlo con las miles de transacciones diarias que manejan, pero es relativamente trivial blindar la plataforma contra éste tipo de robos, hay varias formas de hacerlo mediante el software de la misma plataforma, o el software del personal e servicio al cliente que atiende las reclamaciones, de hecho sería suficiente con capacitar al personal de servicio al cliente para que no reenvíen pagos a menos que se llegue al fondo del problema, pues las transacciones no deben fallar simplemente así.
nikkus
Legendary
*
Offline Offline

Activity: 1523
Merit: 1005


View Profile
February 14, 2014, 06:48:51 PM
 #3

Citando a un compañero del foro Portugués, "el TXID NUNCA fue un comprovante de transacción"... Pero..Otra vez MtGox fastidiandolo todo...

1NikkusCFVtadafW15HZw3up9xo23fi5UD
PGP Key: http://pool.sks-keyservers.net:11371/pks/lookup?op=get&search=0xBBAB337F14D69D08 | j=abs(j-1)
Tox ID: 6E179B4A85329D20274DC8142BB03B2006486CA1C5327DF000A87A1065FE425934B7706AD96F
vgo
Legendary
*
Offline Offline

Activity: 2072
Merit: 1017



View Profile
February 14, 2014, 07:27:23 PM
 #4

¿que quiere decir que te pueden cambiar el hash de tu transferencia?.

El hash es el ID de la transacción que usualmente se usa para encontrarla en la cadena de bloques, si alguien consigue cambiarlo, ésto no afecta el hecho de que el intercambio de monedas ocurrirá sin ningún problema, pues el hash no se usa para nada más que un número de referencia de la transacción, pero sí puede afectar a algunos que tienen sistemas de seguimiento de transacciones como las exchanges. La maleabilidad sólo sirve para esconder la transacción, el estafador cambia el ID de la transacción para que el que la hizo crea que no se llegó a realizar por que no la ve agregada a ningún bloque con el ID que inicialmente generó (con la ID que registró en su log de transacciones). El que recibe el pago debe reclamar al que hace el pago (varias horas después), alegando que no ha llegado la transacción (esto es una mentira), las monedas salieron y llegaron pero NO con el ID que quedó registrado en el servicio. El prestador del servicio debe ser lo suficientemente desordenado e ingenuo como para no comprobar que el saldo efectivamente se restó, y la dirección de llegada efectivamente tiene la cantidad solicitada ingresada, el prestador del servicio repetirá la transacción, completando así la estafa.

Ésta característica se conoce desde 2011, los prestadores de servicios deberían tener métodos de comprobación de transacciones reclamadas que no dependan del ID generado al momento de crear la transacción, pues éste es maleable, de ésta forma se evita el engaño, pero como ves, no es un "bug" que mediante un exploit signifique que alguien robará monedas, se necesita de ingeniería social y de varias horas, tal vez días para completar el robo (mientras se hace la reclamación, se espera a que se atienda el ticket, y el prestador del servicio se come el cuento y repite la transacción).

Para los que no manejamos muchas transacciones diarias, es muy fácil no caer en el engaño, si alguien te dice que no ha recibido las monedas, pues vas a tu billetera y compruebas que la transacción tenga confirmaciones, o también puedes ver la dirección de llegada de las monedas en blockchain.info (o cualquier explorador de bloques) y comprobar que tus monedas sí llegaron, o puedes consultar también en blockchain.info tu dirección de salida, identificar el verdadero ID de la transacción y comprobarla. Además para cambiar el ID de las transacciones se necesita cierto poder de hasheo y otros recursos, es probable que un usuario normal nunca sea blanco de un engaño de éstos. Para los que tienen servicios masivos es un poco más difícil de evitarlo con las miles de transacciones diarias que manejan, pero es relativamente trivial blindar la plataforma contra éste tipo de robos, hay varias formas de hacerlo mediante el software de la misma plataforma, o el software del personal e servicio al cliente que atiende las reclamaciones, de hecho sería suficiente con capacitar al personal de servicio al cliente para que no reenvíen pagos a menos que se llegue al fondo del problema, pues las transacciones no deben fallar simplemente así.


Quiza ahí este la clave. Roll Eyes
Gofio
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250



View Profile
February 14, 2014, 08:42:42 PM
 #5

¿que quiere decir que te pueden cambiar el hash de tu transferencia?.

El hash es el ID de la transacción que usualmente se usa para encontrarla en la cadena de bloques, si alguien consigue cambiarlo, ésto no afecta el hecho de que el intercambio de monedas ocurrirá sin ningún problema, pues el hash no se usa para nada más que un número de referencia de la transacción, pero sí puede afectar a algunos que tienen sistemas de seguimiento de transacciones como las exchanges. La maleabilidad sólo sirve para esconder la transacción, el estafador cambia el ID de la transacción para que el que la hizo crea que no se llegó a realizar por que no la ve agregada a ningún bloque con el ID que inicialmente generó (con la ID que registró en su log de transacciones). El que recibe el pago debe reclamar al que hace el pago (varias horas después), alegando que no ha llegado la transacción (esto es una mentira), las monedas salieron y llegaron pero NO con el ID que quedó registrado en el servicio. El prestador del servicio debe ser lo suficientemente desordenado e ingenuo como para no comprobar que el saldo efectivamente se restó, y la dirección de llegada efectivamente tiene la cantidad solicitada ingresada, el prestador del servicio repetirá la transacción, completando así la estafa.

Ésta característica se conoce desde 2011, los prestadores de servicios deberían tener métodos de comprobación de transacciones reclamadas que no dependan del ID generado al momento de crear la transacción, pues éste es maleable, de ésta forma se evita el engaño, pero como ves, no es un "bug" que mediante un exploit signifique que alguien robará monedas, se necesita de ingeniería social y de varias horas, tal vez días para completar el robo (mientras se hace la reclamación, se espera a que se atienda el ticket, y el prestador del servicio se come el cuento y repite la transacción).

Para los que no manejamos muchas transacciones diarias, es muy fácil no caer en el engaño, si alguien te dice que no ha recibido las monedas, pues vas a tu billetera y compruebas que la transacción tenga confirmaciones, o también puedes ver la dirección de llegada de las monedas en blockchain.info (o cualquier explorador de bloques) y comprobar que tus monedas sí llegaron, o puedes consultar también en blockchain.info tu dirección de salida, identificar el verdadero ID de la transacción y comprobarla. Además para cambiar el ID de las transacciones se necesita cierto poder de hasheo y otros recursos, es probable que un usuario normal nunca sea blanco de un engaño de éstos. Para los que tienen servicios masivos es un poco más difícil de evitarlo con las miles de transacciones diarias que manejan, pero es relativamente trivial blindar la plataforma contra éste tipo de robos, hay varias formas de hacerlo mediante el software de la misma plataforma, o el software del personal e servicio al cliente que atiende las reclamaciones, de hecho sería suficiente con capacitar al personal de servicio al cliente para que no reenvíen pagos a menos que se llegue al fondo del problema, pues las transacciones no deben fallar simplemente así.


+1000
Nubarius
Sr. Member
****
Offline Offline

Activity: 310
Merit: 253


View Profile
February 15, 2014, 08:52:31 AM
 #6

(...)
Además para cambiar el ID de las transacciones se necesita cierto poder de hasheo y otros recursos, es probable que un usuario normal nunca sea blanco de un engaño de éstos.
(...)
Quiza ahí este la clave. Roll Eyes

¿Por qué haría falta "cierto poder de hasheo"?. En principio, modificar el ID de las transacciones debería ser trivial. La dificultad, en teoría, estaría en que si se crea una transacción maleada B a partir de una transacción original A que ya pulula por la red, la transacción A, al haber salido antes, habrá cobrado ventaja respecto a B, que será rechazada por los nodos al llegarles con posteioridad. En transacciones creadas por Bitcoin-Qt, sería un ataque difícil porque se necesitaría actuar con velocidad de relámpago y tener mejor conectividad en la red para que B acabe superando a A. El ataque es sin embargo facilísimo con muchas de las transacciones generadas por MtGox porque el software propio que utilizan genera de manera habitual transacciones "no canónicas", con un formato que Bitcoin-Qt rechaza desde, creo, la versión 0.8.2 de mayo de 2013. Por eso, desde entonces este foro esta plagado de comentarios sobre los famosos dobles gastos de MtGox, que consisten en que muchas de las transacciones que genera MtGox se quedan estancadas, marginadas por el resto de la red, que las rechaza. Eso hace que, en el caso concreto de esas transacciones, el atacante tenga todo el tiempo del mundo para malear la transacción: se toma la transacción estancada de MtGox, se modifican los datos para darles la forma canónica que exige Bitcoin-Qt, y se envía a la red la transacción "arreglada", que tiene otro valor de hash. Los nodos propagan esta transacción, se confirma en la cadena de bloques y después el atacante escribe al servicio técnico de MtGox para quejarse de que no le ha llegado su transacción. Entonces MtGox hace su famoso doble gasto una y otra vez hasta que por pura chiripa la transacción les sale con formato canónico y la red la propaga. El atacante consigue así cobrar dos o más veces la cantidad. El ataque es fácil en este caso, pero por la sorprendente torpeza de MtGox de no haber sabido arreglar ese problema en más de ocho meses.
Mperez
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
February 15, 2014, 10:44:50 AM
 #7

Maleabilidad, pero esto ha caido hasta el infinito y mas alla. A ver si corrigen tambien esto pronto o estamos... un poco perdidos.
jaime
Sr. Member
****
Offline Offline

Activity: 339
Merit: 250


División de Poderes s.XXI es Descentralización


View Profile WWW
February 15, 2014, 11:19:33 AM
 #8


Para los que no manejamos muchas transacciones diarias, es muy fácil no caer en el engaño, si alguien te dice que no ha recibido las monedas, pues vas a tu billetera y compruebas que la transacción tenga confirmaciones,


Creo que bitcoin-qt también puede dar algún error de esta forma, supongo que al menos hasta que haga un rescan. En cualquier caso, si se volviera a repetir la misma transacción, esta no se confirmaría nunca por estar ya hecha.

Como muy bien ha explicado fernarios, la estafa sólo funciona en exchanges con carteras que contienen el saldo de todos sus clientes,así, cuando el estafador llama para reclamar, le reponen su saldo en su cuenta privada con el exchange  (que no es un wallet de bitcoins).

En cuanto al desorden en MtGox (y otros) al no haber cierres, ya que funcionan 24/7 y las confirmaciones pueden tardar lo que se quiera, el control de saldos se complica bastante. Ahora todos están cambiando sus procesos de verificación para que este tipo de cosas no pasen, pero la mejor forma de solucionarlo es que la comunidad acuerde un nuevo ID de transacción que no se pueda cambiar, y no que cada uno utilice el suyo.

dserrano5
Legendary
*
Offline Offline

Activity: 1960
Merit: 1026



View Profile
February 15, 2014, 04:39:34 PM
 #9

la mejor forma de solucionarlo es que la comunidad acuerde un nuevo ID de transacción que no se pueda cambiar, y no que cada uno utilice el suyo.

Este cambio va a tardar años. Está planeado desde que se sabe que los txid se pueden cambiar (2011) pero tiene miga.

La solución que los exchanges pueden y deben tomar hoy día es no usar el txid, sino otras partes de la transacción que a día de hoy no es posible cambiar.
Anillos2
Legendary
*
Offline Offline

Activity: 1260
Merit: 1003


View Profile
February 15, 2014, 05:34:32 PM
 #10

Por curiosidad: ¿Tengo algo que temer a la hora de pagar dinero o recibirlo como particular?

Por ejemplo, si alguien me encarga un dibujo vectorial o optimizar imágenes en una página web... ¿Podría quedarme sin ver la pasta?

dserrano5
Legendary
*
Offline Offline

Activity: 1960
Merit: 1026



View Profile
February 15, 2014, 06:19:07 PM
 #11

Por curiosidad: ¿Tengo algo que temer a la hora de pagar dinero o recibirlo como particular?

Si esperas a tener confirmaciones, no.

Si haces un segundo pago mientras el primero está sin confirmar, puedes tener problemillas. No vas a perder dinero pero va a dar la impresión de que bitcoin "no funciona" y queda feo. Entiendo que en la 0.9 esto estará solucionado.
Anillos2
Legendary
*
Offline Offline

Activity: 1260
Merit: 1003


View Profile
February 16, 2014, 12:47:43 AM
 #12

Por curiosidad: ¿Tengo algo que temer a la hora de pagar dinero o recibirlo como particular?

Si esperas a tener confirmaciones, no.

Si haces un segundo pago mientras el primero está sin confirmar, puedes tener problemillas. No vas a perder dinero pero va a dar la impresión de que bitcoin "no funciona" y queda feo. Entiendo que en la 0.9 esto estará solucionado.
Gracias.

Veo que efectívamente, se trata de algo excepcional, y que con un uso normal de Bitcoin y esperando algunas confirmaciones, no debería darse.

BitLinares
Member
**
Offline Offline

Activity: 98
Merit: 10

Bitbahia.com


View Profile WWW
February 16, 2014, 05:36:08 AM
 #13


El hash es el ID de la transacción que usualmente se usa para encontrarla en la cadena de bloques, si alguien consigue cambiarlo, ésto no afecta el hecho de que el intercambio de monedas ocurrirá sin ningún problema, pues el hash no se usa para nada más que un número de referencia de la transacción, pero sí puede afectar a algunos que tienen sistemas de seguimiento de transacciones como las exchanges. La maleabilidad sólo sirve para esconder la transacción, el estafador cambia el ID de la transacción para que el que la hizo crea que no se llegó a realizar por que no la ve agregada a ningún bloque con el ID que inicialmente generó (con la ID que registró en su log de transacciones). El que recibe el pago debe reclamar al que hace el pago (varias horas después), alegando que no ha llegado la transacción (esto es una mentira), las monedas salieron y llegaron pero NO con el ID que quedó registrado en el servicio. El prestador del servicio debe ser lo suficientemente desordenado e ingenuo como para no comprobar que el saldo efectivamente se restó, y la dirección de llegada efectivamente tiene la cantidad solicitada ingresada, el prestador del servicio repetirá la transacción, completando así la estafa.

Ésta característica se conoce desde 2011, los prestadores de servicios deberían tener métodos de comprobación de transacciones reclamadas que no dependan del ID generado al momento de crear la transacción, pues éste es maleable, de ésta forma se evita el engaño, pero como ves, no es un "bug" que mediante un exploit signifique que alguien robará monedas, se necesita de ingeniería social y de varias horas, tal vez días para completar el robo (mientras se hace la reclamación, se espera a que se atienda el ticket, y el prestador del servicio se come el cuento y repite la transacción).

Para los que no manejamos muchas transacciones diarias, es muy fácil no caer en el engaño, si alguien te dice que no ha recibido las monedas, pues vas a tu billetera y compruebas que la transacción tenga confirmaciones, o también puedes ver la dirección de llegada de las monedas en blockchain.info (o cualquier explorador de bloques) y comprobar que tus monedas sí llegaron, o puedes consultar también en blockchain.info tu dirección de salida, identificar el verdadero ID de la transacción y comprobarla. Además para cambiar el ID de las transacciones se necesita cierto poder de hasheo y otros recursos, es probable que un usuario normal nunca sea blanco de un engaño de éstos. Para los que tienen servicios masivos es un poco más difícil de evitarlo con las miles de transacciones diarias que manejan, pero es relativamente trivial blindar la plataforma contra éste tipo de robos, hay varias formas de hacerlo mediante el software de la misma plataforma, o el software del personal e servicio al cliente que atiende las reclamaciones, de hecho sería suficiente con capacitar al personal de servicio al cliente para que no reenvíen pagos a menos que se llegue al fondo del problema, pues las transacciones no deben fallar simplemente así.


Muchas gracias! ahora entiendo todo este rollo.

jaime
Sr. Member
****
Offline Offline

Activity: 339
Merit: 250


División de Poderes s.XXI es Descentralización


View Profile WWW
February 16, 2014, 07:41:42 AM
 #14

la mejor forma de solucionarlo es que la comunidad acuerde un nuevo ID de transacción que no se pueda cambiar, y no que cada uno utilice el suyo.

Este cambio va a tardar años. Está planeado desde que se sabe que los txid se pueden cambiar (2011) pero tiene miga.

La solución que los exchanges pueden y deben tomar hoy día es no usar el txid, sino otras partes de la transacción que a día de hoy no es posible cambiar.

A nivel de wallet esto tiene una solución rápida, así que todo este embrollo se arreglará pronto.

Cuando MtGox abra la puerta vamos a ver una estampida, todo el mundo sacando sus bitcoins a la carrera., con lo que imagino que el precio ahí subirá en la misma proporción en la que los btc van desapareciendo. Creo que vamos a tener una buena oportunidad...

¿Qué opinas?

Jebuz
Newbie
*
Offline Offline

Activity: 40
Merit: 0


View Profile
February 16, 2014, 06:44:27 PM
 #15

la mejor forma de solucionarlo es que la comunidad acuerde un nuevo ID de transacción que no se pueda cambiar, y no que cada uno utilice el suyo.

Este cambio va a tardar años. Está planeado desde que se sabe que los txid se pueden cambiar (2011) pero tiene miga.

La solución que los exchanges pueden y deben tomar hoy día es no usar el txid, sino otras partes de la transacción que a día de hoy no es posible cambiar.

A nivel de wallet esto tiene una solución rápida, así que todo este embrollo se arreglará pronto.

Cuando MtGox abra la puerta vamos a ver una estampida, todo el mundo sacando sus bitcoins a la carrera., con lo que imagino que el precio ahí subirá en la misma proporción en la que los btc van desapareciendo. Creo que vamos a tener una buena oportunidad...

¿Qué opinas?

En un mercado de oferta y demanda, el retiro de bitcoins no generara precisamente una baja, sino que quedaria mtgox sin oferta de bitcoins para ser comprados, por lo que tendria que generar una subida rapida de precio.
Como todo movimiento rapido en mercados, esto genera volatilidad. Es decir, el precio sube rapido, y muchos venden rapido para liquidar y obtener ganacias. Por ende se genera un "sube y baja" permanente y con margenes amplios, hasta que se estabilicen las operaciones (quienes queria comprar barato lo hayan hecho y quienes querian tomar ganancias en las subidas tambien).
A partir de ahi, viendo el precio de otros exchanges, deberia generar un suba en mtgox, pero aca es la parte incierta. Si, mtgox estara barato para comprar, pero que confianza tendra la gente en ellos? Esta es la parte psicologica. Si todo sigue como antes, la gente vuelve a confiar casi que por osmosis. Si el precio no sube, nadie querra poner su dinero en ese exchange. Pero hay una realidad, mtgox ha sido por mucho tiempo el lider y quien manejaba mas del 50% de operaciones y volumen de transacciones. No creo que desaparezca, a menos que las perdidas que hayan tenido con este problema hayan sido de niveles epicos.
Por lo pronto muchos han vendido y estan recomprando a menos de $300, lo cual si todo se recupera, algunos habran multiplicado un par de veces su saldo y se lo agradeceran a mtgox....

Saludos!
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!