El antiguo formato de transacciones estándar incluía 3 tipos: P2PUBKEY, P2PKH, P2SH. Después de la bifurcación suave de Segwit, tenemos 2 tipos adicionales: P2WPKH y P2WSH.
Si comparamos el costo de gastar entradas (en bytes que escribimos en HDD) para P2PUBKEY, P2PKH y P2WPKH y obtenemos los siguientes valores:
De esta comparación, podemos concluir que P2PUBKEY es el mejor para reducir el tamaño de la cadena de bloques. Podemos ahorrar alrededor del 19% del tamaño de la entrada de gastos. Entiendo que P2PKH da más seguridad en caso de que no reutilicemos la dirección. Si reutilizamos la dirección, no hay ventajas de usar P2PKH. Podemos observar el uso bastante frecuente de direcciones repetidamente. Para una gama específica de tareas, no necesitamos seguridad adicional como P2PKH. ¿Por qué en los tipos de transacción de Segwit no tenemos la capacidad de usar P2WPUBKEY como transacción estándar? ¿Este tipo de transacción ayuda a reducir el tamaño de la cadena de bloques en caso de que un usuario no necesite/quiera usar el modelo de seguridad "sin reutilización de direcciones"? 20 bytes para cada entrada, esta es una buena oportunidad para ahorrar el tamaño de la cadena de bloques.
Además, leí este hilo https://bitcointalk.org/index.php?topic=6430.0 , ¿cuál es la razón por la cual los desarrolladores del núcleo de bitcoin no quieren usar la recuperación de clave pública y ahorrar 33 bytes para cada entrada? Si las preocupaciones están relacionadas con el rendimiento, podemos observar cómo funciona ethereum y alcanza alrededor de 1 millón de tx por día (esto es como 1 millón de entradas por día en Bitcoin).
Si las preocupaciones están relacionadas con el rendimiento, podemos observar cómo funciona ethereum y alcanza alrededor de 1 millón de tx por día (esto es como 1 millón de entradas por día en Bitcoin).
Ethereum realmente no es una buena comparación considerando que es imposible sincronizar un nodo Ethereum de archivo de validación completa.
De todos modos, la preocupación no es solo el "rendimiento", sino el riesgo de ataque de denegación de servicio. Realizar la recuperación de la clave pública es mucho más costoso computacionalmente que calcular un hash de algo. Por lo tanto, existe potencialmente un ataque DoS en el que un atacante crea muchas transacciones con firmas no válidas en las que un nodo tiene que realizar la recuperación de la clave pública solo para descartar la transacción porque no es válida. Al requerir que un nodo realice muchos cálculos en transacciones no válidas, se puede evitar que realice cualquier verificación de transacciones reales, lo que impide que el nodo realmente haga su trabajo.
Con hashes de clave, esto es un riesgo menor porque el atacante necesita conocer la clave pública para que un nodo se rompa en el paso de firma no válido. Por lo tanto, un atacante no podría simplemente usar cualquier salida que tenga el mismo formato (como podría hacerlo con cualquier salida usando recuperación de clave), sino que tiene que usar salidas específicas para las que conoce las claves públicas, lo que limita la cantidad de transacciones que se pueden crear.
bitaps.com
andres chow