En informática, un ataque de denegación de servicio (Ataque DoS; Reino Unido: /dɒs/ dormir NOSOTROS: /dɑːs/ daas(1)) es un ataque cibernético en el que el perpetrador busca hacer que una máquina o un recurso de purple no esté disponible para sus usuarios previstos interrumpiendo temporal o indefinidamente los servicios de un host conectado a una purple. -La definición de Wikipedia de ataque de denegación de servicio.
Este es un concepto muy básico. Alguien hace uso de sus propios recursos para interrumpir el funcionamiento de otras máquinas en una purple.
Los ataques DoS han sido un problema desde que existe Web. Uno de los “primeros ataques de denegación de servicio distribuido (DDoS)” comúnmente discutidos fue contra el proveedor de servicios de Web (ISP) Panix a mediados de los años 90. Por supuesto, hubo muchos ejemplos técnicos anteriores sobre servicios de Web más antiguos, pero este fue uno de los primeros ejemplos importantes, si no el primero, de un ataque de este tipo en la World Broad Net moderna.
Este ataque hizo que numerosas computadoras comenzaran a iniciar una conexión de Protocolo de management de transmisión (TCP) con los servidores del ISP, pero nunca finalizaron el protocolo de enlace que finalizó la conexión. Esto eat los recursos del servidor para administrar las conexiones de purple e impide que usuarios honestos accedan a Web a través de los servidores del ISP.
Desde este ataque DDoS “inicial”, han sido tan comunes en Web como las tormentas en la naturaleza, un suceso common contra el cual se han construido enormes infraestructuras de Web para defenderse.
La cadena de bloques
La cadena de bloques es uno de los componentes centrales de Bitcoin y una dependencia necesaria para la funcionalidad de Bitcoin como libro de contabilidad distribuido. Estoy seguro de que muchas personas en este espacio llamarían a las llamadas transacciones “spam” un ataque DoS a la cadena de bloques de Bitcoin. Para llamarlo así, habría que definir el “servicio” que ofrece la cadena de bloques como sistema y explicar cómo las transacciones de spam niegan ese servicio a otros de una manera que no estaba prevista en el diseño del sistema.
Apostaría a que la mayoría de las personas que creen que el spam es un ataque DoS dirían algo como “el servicio que ofrece blockchain procesa transacciones financieras, y el spam le quita espacio a las personas que intentan hacerlo”. El problema es que ese no es específicamente el servicio que ofrece blockchain.
El servicio que realmente ofrece es la confirmación de cualquier Transacción válida por consenso a través de una subasta en tiempo actual que se liquida periódicamente cada vez que un minero encuentra un bloque. Si su transacción es válida por consenso y ha ofertado una tarifa lo suficientemente alta para que un minero incluya su transacción en un bloque, está utilizando el servicio que la cadena de bloques proporciona exactamente como se diseñó.
Esta fue una decisión de diseño consciente tomada durante años durante las “Guerras del tamaño de bloques” y finalizada con la activación de Segregated Witness y el rechazo del aumento del tamaño de bloques de Segwit2x a través de una bifurcación impulsada por las principales empresas en ese momento. La cadena de bloques funcionaría dando prioridad a las transacciones con tarifas de oferta más altas, y los usuarios serían libres de competir en esa subasta. Así es como se asignaría el espacio en bloques, con una restricción world para proteger la verificabilidad y un mecanismo de fijación de precios de libre mercado.
Nada de una transacción que algunos definen arbitrariamente como “spam” ganadora en esta subasta abierta es un DoS de la cadena de bloques. Se trata de un usuario que hace uso de ese recurso como debe hacerlo, participando en la subasta con todos los demás.
La purple de retransmisión
Muchos, si no la mayoría, de los nodos de Bitcoin ofrecen retransmisión de transacciones como servicio al resto de la purple. Si transmite sus transacciones a sus pares en la purple, ellos las reenviarán a sus pares, y así sucesivamente. Debido a que la lógica de emparejamiento que resolve con qué nodos emparejar mantiene una amplia conectividad, este servicio permite que las transacciones se propaguen a través de la purple muy rápidamente y, específicamente, les permite propagarse a todos los nodos de minería.
Otro servicio es la retransmisión de bloques, que propaga bloques válidos a medida que se encuentran de la misma manera. Esto se ha optimizado mucho a lo largo de los años, hasta el punto de que la mayoría de las veces nunca se transmite un bloque completo, solo un “bosquejo” abreviado del encabezado del bloque y las transacciones incluidas en él para que pueda reconstruirlas desde su propio grupo de memoria. En otras palabras, las optimizaciones en la retransmisión de bloques dependen de que una retransmisión de transacciones funcione correctamente y propague todas las transacciones válidas y que probablemente sean minadas.
Cuando los nodos no tienen transacciones en un bloque ya en su mempool, deben solicitarlas a los nodos vecinos, tomando más tiempo para validar el bloque en el proceso. También reenvían explícitamente esas transacciones junto con el boceto del bloque a otros pares en caso de que se las pierdan, desperdiciando ancho de banda. Cuantos más nodos filtren transacciones que clasifiquen como spam, más tiempo tardarán los bloques, incluidas esas transacciones filtradas, en propagarse por la purple.
El filtrado de transacciones busca activamente interrumpir ambos servicios, en el caso de que la retransmisión de transacciones falle estrepitosamente para evitar que se propaguen a los mineros, y en el caso de que la propagación de bloques tenga una degradación marginal pero notable del rendimiento cuanto más nodos en la purple estén filtrando transacciones.
Estas políticas de nodo tienen el propósito explícito de degradar el servicio de purple de propagación de transacciones a los mineros y el resto de la purple, y ven la degradación de la propagación de bloques como una penalización para los mineros que eligen incluir transacciones válidas que están filtrando. Buscan crear una degradación del servicio como objetivo y consideran positiva la degradación de otro servicio resultante de ese intento.
En realidad, se trata de un ataque DoS, ya que en realidad degrada un servicio de purple en contra del diseño del sistema.
¿A dónde desde aquí?
Toda la saga de Knotz contra Core, o “Spammers” contra “Filterers”, no ha sido más que un ataque DoS miserablemente ineficaz y fallido en la purple Bitcoin. Los filtros no hacen absolutamente nada para evitar que las transacciones filtradas se incluyan en bloques. El objetivo de interrumpir la propagación de transacciones a los mineros no ha tenido éxito alguno, y la degradación de la retransmisión de bloques ha sido lo suficientemente marginal como para no desincentivar a los mineros.
Veo esto como una gran demostración de la solidez y resistencia de Bitcoin contra los intentos de censura y perturbación a nivel de la propia purple Bitcoin.
¿Y ahora qué?
A PBI por un autor anónimo se ha propuesto para promulgar un softfork temporal que expiraría después de aproximadamente un año, invalidando numerosas formas de incluir “spam” en el consenso de transacciones de Bitcoin durante ese período de tiempo. Después de darse cuenta de que el ataque DoS en la purple peer-to-peer había sido un fracaso complete, los partidarios del filtro han optado por realizar cambios por consenso, ya que a muchos de ellos se les dijo que serían necesarios hace más de dos años.
¿Esto realmente resolverá el problema? No, no lo será. Simplemente obligará a las personas que deseen enviar “spam” a esta purple bifurcada, si realmente siguen implementándola, a utilizar ScriptPubKeys falsos para codificar sus datos en resultados inútiles que inflarán el conjunto UTXO.
Entonces, incluso si esta bifurcación recibiera un apoyo rotundo, se activara con éxito y no diera como resultado una división de la cadena, aún así no lograría el objetivo declarado y no dejaría a los “spammers” otra opción que “enviar spam” de la manera más dañina posible para la purple.
En informática, un ataque de denegación de servicio (Ataque DoS; Reino Unido: /dɒs/ dormir NOSOTROS: /dɑːs/ daas(1)) es un ataque cibernético en el que el perpetrador busca hacer que una máquina o un recurso de purple no esté disponible para sus usuarios previstos interrumpiendo temporal o indefinidamente los servicios de un host conectado a una purple. -La definición de Wikipedia de ataque de denegación de servicio.
Este es un concepto muy básico. Alguien hace uso de sus propios recursos para interrumpir el funcionamiento de otras máquinas en una purple.
Los ataques DoS han sido un problema desde que existe Web. Uno de los “primeros ataques de denegación de servicio distribuido (DDoS)” comúnmente discutidos fue contra el proveedor de servicios de Web (ISP) Panix a mediados de los años 90. Por supuesto, hubo muchos ejemplos técnicos anteriores sobre servicios de Web más antiguos, pero este fue uno de los primeros ejemplos importantes, si no el primero, de un ataque de este tipo en la World Broad Net moderna.
Este ataque hizo que numerosas computadoras comenzaran a iniciar una conexión de Protocolo de management de transmisión (TCP) con los servidores del ISP, pero nunca finalizaron el protocolo de enlace que finalizó la conexión. Esto eat los recursos del servidor para administrar las conexiones de purple e impide que usuarios honestos accedan a Web a través de los servidores del ISP.
Desde este ataque DDoS “inicial”, han sido tan comunes en Web como las tormentas en la naturaleza, un suceso common contra el cual se han construido enormes infraestructuras de Web para defenderse.
La cadena de bloques
La cadena de bloques es uno de los componentes centrales de Bitcoin y una dependencia necesaria para la funcionalidad de Bitcoin como libro de contabilidad distribuido. Estoy seguro de que muchas personas en este espacio llamarían a las llamadas transacciones “spam” un ataque DoS a la cadena de bloques de Bitcoin. Para llamarlo así, habría que definir el “servicio” que ofrece la cadena de bloques como sistema y explicar cómo las transacciones de spam niegan ese servicio a otros de una manera que no estaba prevista en el diseño del sistema.
Apostaría a que la mayoría de las personas que creen que el spam es un ataque DoS dirían algo como “el servicio que ofrece blockchain procesa transacciones financieras, y el spam le quita espacio a las personas que intentan hacerlo”. El problema es que ese no es específicamente el servicio que ofrece blockchain.
El servicio que realmente ofrece es la confirmación de cualquier Transacción válida por consenso a través de una subasta en tiempo actual que se liquida periódicamente cada vez que un minero encuentra un bloque. Si su transacción es válida por consenso y ha ofertado una tarifa lo suficientemente alta para que un minero incluya su transacción en un bloque, está utilizando el servicio que la cadena de bloques proporciona exactamente como se diseñó.
Esta fue una decisión de diseño consciente tomada durante años durante las “Guerras del tamaño de bloques” y finalizada con la activación de Segregated Witness y el rechazo del aumento del tamaño de bloques de Segwit2x a través de una bifurcación impulsada por las principales empresas en ese momento. La cadena de bloques funcionaría dando prioridad a las transacciones con tarifas de oferta más altas, y los usuarios serían libres de competir en esa subasta. Así es como se asignaría el espacio en bloques, con una restricción world para proteger la verificabilidad y un mecanismo de fijación de precios de libre mercado.
Nada de una transacción que algunos definen arbitrariamente como “spam” ganadora en esta subasta abierta es un DoS de la cadena de bloques. Se trata de un usuario que hace uso de ese recurso como debe hacerlo, participando en la subasta con todos los demás.
La purple de retransmisión
Muchos, si no la mayoría, de los nodos de Bitcoin ofrecen retransmisión de transacciones como servicio al resto de la purple. Si transmite sus transacciones a sus pares en la purple, ellos las reenviarán a sus pares, y así sucesivamente. Debido a que la lógica de emparejamiento que resolve con qué nodos emparejar mantiene una amplia conectividad, este servicio permite que las transacciones se propaguen a través de la purple muy rápidamente y, específicamente, les permite propagarse a todos los nodos de minería.
Otro servicio es la retransmisión de bloques, que propaga bloques válidos a medida que se encuentran de la misma manera. Esto se ha optimizado mucho a lo largo de los años, hasta el punto de que la mayoría de las veces nunca se transmite un bloque completo, solo un “bosquejo” abreviado del encabezado del bloque y las transacciones incluidas en él para que pueda reconstruirlas desde su propio grupo de memoria. En otras palabras, las optimizaciones en la retransmisión de bloques dependen de que una retransmisión de transacciones funcione correctamente y propague todas las transacciones válidas y que probablemente sean minadas.
Cuando los nodos no tienen transacciones en un bloque ya en su mempool, deben solicitarlas a los nodos vecinos, tomando más tiempo para validar el bloque en el proceso. También reenvían explícitamente esas transacciones junto con el boceto del bloque a otros pares en caso de que se las pierdan, desperdiciando ancho de banda. Cuantos más nodos filtren transacciones que clasifiquen como spam, más tiempo tardarán los bloques, incluidas esas transacciones filtradas, en propagarse por la purple.
El filtrado de transacciones busca activamente interrumpir ambos servicios, en el caso de que la retransmisión de transacciones falle estrepitosamente para evitar que se propaguen a los mineros, y en el caso de que la propagación de bloques tenga una degradación marginal pero notable del rendimiento cuanto más nodos en la purple estén filtrando transacciones.
Estas políticas de nodo tienen el propósito explícito de degradar el servicio de purple de propagación de transacciones a los mineros y el resto de la purple, y ven la degradación de la propagación de bloques como una penalización para los mineros que eligen incluir transacciones válidas que están filtrando. Buscan crear una degradación del servicio como objetivo y consideran positiva la degradación de otro servicio resultante de ese intento.
En realidad, se trata de un ataque DoS, ya que en realidad degrada un servicio de purple en contra del diseño del sistema.
¿A dónde desde aquí?
Toda la saga de Knotz contra Core, o “Spammers” contra “Filterers”, no ha sido más que un ataque DoS miserablemente ineficaz y fallido en la purple Bitcoin. Los filtros no hacen absolutamente nada para evitar que las transacciones filtradas se incluyan en bloques. El objetivo de interrumpir la propagación de transacciones a los mineros no ha tenido éxito alguno, y la degradación de la retransmisión de bloques ha sido lo suficientemente marginal como para no desincentivar a los mineros.
Veo esto como una gran demostración de la solidez y resistencia de Bitcoin contra los intentos de censura y perturbación a nivel de la propia purple Bitcoin.
¿Y ahora qué?
A PBI por un autor anónimo se ha propuesto para promulgar un softfork temporal que expiraría después de aproximadamente un año, invalidando numerosas formas de incluir “spam” en el consenso de transacciones de Bitcoin durante ese período de tiempo. Después de darse cuenta de que el ataque DoS en la purple peer-to-peer había sido un fracaso complete, los partidarios del filtro han optado por realizar cambios por consenso, ya que a muchos de ellos se les dijo que serían necesarios hace más de dos años.
¿Esto realmente resolverá el problema? No, no lo será. Simplemente obligará a las personas que deseen enviar “spam” a esta purple bifurcada, si realmente siguen implementándola, a utilizar ScriptPubKeys falsos para codificar sus datos en resultados inútiles que inflarán el conjunto UTXO.
Entonces, incluso si esta bifurcación recibiera un apoyo rotundo, se activara con éxito y no diera como resultado una división de la cadena, aún así no lograría el objetivo declarado y no dejaría a los “spammers” otra opción que “enviar spam” de la manera más dañina posible para la purple.
