¿Por qué no multiplicar "seis confirmaciones" y dividir el tiempo entre bloques y la recompensa por el mismo factor?

Parece que elegir un buen factor para expandir la capacidad de Bitcoin es una buena idea. El software dividiría algunos de sus valores calculados por este factor, como el tiempo objetivo entre bloques durante el cálculo de dificultad, el número de bloques entre ajustes de dificultad y el subsidio. Para lograr la seguridad de "una hora de poder de hash", la recomendación de confirmaciones se multiplicaría por este factor. Parece que usar un factor de dos de vez en cuando (siempre que la comunidad lo encuentre valioso) sería apropiado.

Supongamos que elegimos un factor N. Esto permitirá que la propia cadena de bloques crezca N veces más rápido, proporcionando N veces las tarifas de transacción a los mineros, multiplicando el número de recompensas por N (pero dividiendo la recompensa en sí misma por N), dividiendo el promedio esperar una confirmación por N, y multiplicar la tasa a la que se confirman las transacciones por N. Esto también reduce la varianza de los ingresos mineros.

Esto permite que se utilice el tiempo (en lugar del ancho de banda de la red y la memoria de la computadora) para expandir la capacidad de carga del ecosistema bitcoin. ¿Debería escribirse tal propuesta en un BIP?

Las objeciones a esta idea hasta ahora han sido respondidas en los comentarios. Si alguien siente que hay una objeción lo suficientemente adecuada como para abandonar la idea, publique una respuesta. Si alguien quiere crear un BIP, hágamelo saber para que no tenga que hacerlo yo mismo. No me importa hacerlo yo mismo, pero probablemente sea lento.

su sugerencia también aumenta el ancho de banda de la red, a medida que se reduce el intervalo de tiempo entre bloques, aumenta la capacidad requerida para propagar bloques. También hay una latencia que entra en juego. A medida que se reduce el intervalo de tiempo entre bloques, la proporción de tiempo que contribuye la latencia aumenta y aumenta la probabilidad de que un bloque acuñado quede huérfano. Con ganas de escuchar lo que piensan los demás.
Entonces, si N = 2, tenemos un nuevo bloque de 1 MB cada 5 minutos en lugar de 10 con cada recompensa de minero reducida a la mitad en comparación con el protocolo actual. ¿No es esto fundamentalmente lo mismo que duplicar el tamaño del bloque (aunque de una manera más complicada)?
Una desventaja es que debe hacer que todos los usuarios finales entiendan que el punto de referencia para la cantidad de confirmaciones ha cambiado y que lo vuelvan a hacer cada vez que cambie N. Con el sistema actual, los usuarios finales pueden memorizar un número mágico como 6 confirmaciones que nunca cambiarán. Para tales usuarios finales, un aumento en el tamaño del bloque puede ser transparente, incluso si se trata de una bifurcación dura; tienen que actualizar su software, pero no tienen que cambiar su forma de pensar.
@renlord: sí, el requisito de ancho de banda aumenta con la capacidad. Los bloques huérfanos también aumentan, pero solo causan la mitad de las pérdidas que normalmente causan.
@ Sven-Williamson: sí, fundamentalmente lo mismo, pero no duplica el ancho de banda para cada bloque o la carga de mempool como lo hacen los aumentos de tamaño de bloque.
@ Nate-Elderidge: la seguridad siempre debería haber sido "una hora de poder de hash" y cambiarlo a eso es un cambio fundamentalmente sólido.
@NateEldredge Podría implementar esto como 'fracciones de una confirmación'. Entonces, en lugar de ver 7 confirmaciones bajo el nuevo sistema, verían 3.5. El problema es que necesita que todas las billeteras adopten este nuevo sistema de numeración.

Respuestas (1)

En consideración de reemplazar el bloque 1 con Nbloques en el mismo período de tiempo, N > 1veo los siguientes puntos:

Ventajas

  • Se reduce el tiempo esperado hasta la primera confirmación
  • Los ingresos de la minería se distribuyen de manera más fluida entre los grupos
  • Se aumenta la capacidad de la red.
  • Tráfico pico más pequeño que aumentar el tamaño de bloque enN

Desventajas

  • Se requiere un hardfork para ajustar el intervalo de bloque
  • Mayor probabilidad de bifurcaciones de cadena y mayor tasa de obsolescencia debido a que la validación de bloques ocupa una mayor parte del intervalo de bloque
  • Los clientes ligeros necesitan almacenar una mayor cantidad de encabezados
  • Uso de ancho de banda ligeramente mayor que bloques más grandes

Aún así, puede ser que 10 minutos sea demasiado conservador y un intervalo de bloque más pequeño proporcionaría un beneficio general. Por ejemplo, en Scaling Bitcoin Milan, Arthur Gervais presentó resultados de simulación que interpretó para sugerir que Bitcoin podría usar bloques de 1 minuto de manera segura.

CoinDesk cubrió el tema en Un tiempo de bloque más bajo podría ayudar a la escala de Bitcoin, pero ¿funcionará? .

¿Cómo se vería afectada la oferta monetaria? La propuesta era dividir el tiempo de bloque y la recompensa por el mismo divisor, de modo que la oferta monetaria siguiera creciendo con el tiempo al mismo ritmo que antes (aunque un poco más suave).
@NateEldredge: La oferta monetaria se reduciría muy levemente porque los subsidios en bloque antes perderían parte de un satoshi por bloque cuando la reducción a la mitad mueve la precisión a decimales, pero solo se pueden pagar los satoshis completos. – Sin embargo, acabo de calcular la cantidad real, e incluso N = 10es un poco menos de 25 mBTC, por lo que eliminé la mención de mi respuesta.
¿Por qué no multiplicar "seis confirmaciones" y dividir el tiempo entre bloques y la recompensa por el mismo factor?
RespuestasAquíPolítica de privacidad1y, 0v