Nano Payments

Más allá de los micropagos: El auge de los nano servicios. por Shadders

Nano Payments

Más allá de los micropagos: El auge de los nano servicios

16 de septiembre de 2020

 

El lanzamiento de Rails de Bitcoin SV (v1.0.5) presenta varias características que cambian el juego que se han estado desarrollando durante mucho tiempo.

  1. Activación del ensamblador de bloques de registro por defecto
  2. Lotes de transacciones presentación
  3. Transacciones de consolidación gratuitas

Esta versión tiene el nombre en código RAILS porque sus características principales están destinadas a abrir casos de pago nuevos e innovadores utilizando el protocolo y el libro mayor de Bitcoin SV, y permitir a las empresas de Bitcoin SV construir más infraestructura para los pagos: «vías de pago».

Es el último de estos en el que nos centraremos en la publicación.

El límite de polvo – The dust limit

Érase una vez, algunos desarrolladores de BTC, conscientes de sus responsabilidades parentales con todos los participantes en la red Bitcoin, introdujeron un mecanismo de protección llamado límite de polvo. Dejando de lado el debate sobre lo correcto o incorrecto de las actitudes paternalistas de los desarrolladores, este límite persiste hoy como una política impuesta por defecto por los mineros. Se puso en marcha como un intento de evitar que las personas cayeran en una trampa en particular.

Una transacción típica de Bitcoin se parece a esto:

La parte notable de esta transacción de ejemplo es que los valores pagados (en satoshis) son muy altos en comparación con la tarifa. El pago es de aproximadamente $ 11 USD en dinero actual, mientras que la tarifa es una pequeña fracción de un centavo. Esta pequeña tarifa es lo que hace posible los micropagos. Nadie quiere pagar una parte significativa de sus transacciones como tarifas, pero cuando son tan bajas, los pagos de incluso 1 centavo son muy factibles. Pero hay un límite inferior a lo que tiene sentido económicamente. Y si cruzas ese límite lo suficiente, te adentras en un territorio donde puedes inutilizar algunos satoshis.

En el ejemplo anterior, estamos tratando de ir más allá de los micropagos y entrar en lo que llamaremos «nanopagos» adjuntando una pequeña salida de 10 satoshi a una transacción existente. Aquí es donde normalmente se aplicaría el límite de polvo para evitar que la transacción se realice, porque según las políticas de tarifas estándar a las que todos estamos acostumbrados en Bitcoin, esta salida requeriría una tarifa más alta para gastar que el valor de la salida en sí. Es económicamente más barato simplemente descartar esos 10 satoshis que gastarlos. A menos que tal vez esperemos y esperemos que Bitcoin SV suba muchos órdenes de magnitud y las tarifas en satoshis caigan por igual.

Los canales de pago son un mecanismo bien conocido que permite intercambios de valor de forma incremental en unidades tan pequeñas que no serían económicas en una transacción de Bitcoin por sí solas. Pero hay otras maneras.

Transacciones de consolidación

Una transacción de Bitcoin tiene un número variable de entradas y un número variable de salidas. Cuando se acepta una transacción, las salidas anteriores (a las que hacen referencia las entradas) se eliminan de la base de datos de UTXO y se agregan las salidas. Entonces, el efecto neto sobre el tamaño de la base de datos UTXO (en términos de elementos discretos, no bytes) después de aceptar una transacción se puede expresar como:

uxto_delta = nOutputs – nInputs. 

Desde el punto de vista de un minero, el tamaño de la base de datos UTXO es importante porque cuanto más grande es, mayor es el costo de mantenerla. Esto se compensa con el aumento del valor de las tarifas de transacción que resulta, pero todavía es de interés económico para todos los mineros recortar el UTXO siempre que sea posible. Ingrese el concepto de una transacción de consolidación que tiene muchas entradas y pocas salidas, de modo que utxo_delta es sustancialmente negativo, lo que da como resultado una reducción de la base de datos UTXO. Dado que esto ya es un beneficio neto económico para un minero, es factible que un minero permita una transacción de este tipo con una tarifa cero.

Al hacerlo, no sólo permitimos que una gran cantidad de UTXO de polvo existentes vuelvan a ser útiles, sino que también abrimos algunos casos de uso nuevos y poderosos que no son posibles con el límite de polvo actual.

En el ejemplo anterior, vemos una transacción normal con 10 salidas satoshi adicionales adjuntas. El destinatario de estas salidas simplemente recopila suficientes para cumplir con los criterios de una transacción de consolidación gratuita y luego convierte el valor colectivo de 1000 entradas en una única salida de mayor valor. El tamaño de la base de datos UTXO se reduce en 999 entradas. Se podría argumentar que estos son UTXO que no se habrían creado sin que este modelo fuera factible, lo que bien puede ser cierto, sin embargo, incluso ignorando los beneficios de limpieza de polvo existentes, terminamos con un costo neto en el tamaño de UTXO de cero, al tiempo que permite una alta flexibilidad nuevos casos de uso.

Casos de uso de servicios nano

Entonces, ¿cómo podría hacer uso de la capacidad de pagar tan solo 1 satoshi por un servicio? Bueno, eso es para que lo exploren otras mentes creativas, pero en términos de operaciones normales de la red Bitcoin, aquí hay algunos ejemplos:

  •   Pagarle a un minero específico algunos satoshis para que le devuelva una prueba Merkle cuando se extrae una transacción (independientemente de si la extraen).
  •  Pagarle a un minero específico para que esté atento a los gastos dobles y le notifique.
  •  Pagos a un host de correo de pago.
  •  Pagar a un servidor de canales para almacenar y reenviar sus mensajes mientras está desconectado (más sobre esto más adelante).
  •  Pago del seguro o refrendo por un custodio multifirma especializado.

Básicamente, cualquier servicio que esté relacionado con una transacción económica podría pagarse de esta manera. La principal advertencia es que debe haber un valor de movimiento de transacción existente en exceso de una tarifa de transacción típica para que el nanopago pueda aprovechar.

¿Y los canales de pago? What about payment channels?

Los canales de pago son una forma perfectamente válida de lograr nanopagos que son útiles en muchos escenarios. Un canal de pago solo se vuelve útil cuando el monto probablemente liquidado excede una tarifa de transacción, pero permite cambios incrementales de valor en montos igualmente pequeños a una transacción de consolidación. Esto es útil cuando es posible que desee utilizar repetidamente el mismo nano-servicio. Hay que considerar las compensaciones en torno a la complejidad de la implementación. Donde una transacción de consolidación difiere es que se puede utilizar como única vez para un servicio en particular sin establecer una relación similar a un canal de pago con la contraparte. Cuál de los dos tiene más sentido se reducirá a una evaluación uso por uso.

Entonces, ¿cómo los usamos?

Al igual que en los primeros días de aumento del límite OP_RETURN, habrá algunas barreras iniciales para que se acepten tales transacciones. Muchos recordarán los esfuerzos necesarios para encontrar nodos que lo admitieran y para construir rutas de conexión entre nodos habilitados para que las transacciones OP_RETURN pudieran propagarse. Tomó algún tiempo y se volvió más confiable con el tiempo hasta que se logró la adopción general. Esto será similar pero con un acelerador de teclas proporcionado por Merchant API (de ahora en adelante conocido como mAPI).

En primer lugar, la creación de salidas de polvo en sí misma todavía está limitada en cierto grado por el límite de polvo. Este límite se eliminará por completo a finales de año permitiendo incluso salidas de valor 0. Mientras tanto, la versión 1.0.5 de bitcoin al menos ha fijado el límite estricto y lo ha convertido en una función de la tarifa de retransmisión establecida por el minero. Esto significa que los mineros que se hayan actualizado a 1.0.5 deberían aceptar salidas superiores a 140 satoshis.

Hasta que se logre la implementación generalizada por parte de los mineros, el límite de polvo seguirá siendo una barrera para que estas transacciones se transmitan, lo que significa que no debe asumir el mismo nivel de garantía de cero confianza que una transacción con solo salidas sin polvo. Pero para los casos de uso en los que zero-conf no importa, es seguro usarlo ahora mismo.

En segundo lugar, para escenarios de configuración distintos de cero, la propagación p2p se puede omitir por completo una vez que mAPI admita estas transacciones. Esta es una característica de mAPI 1.2 cuyo lanzamiento está previsto para octubre. Una vez que acople un 1.2 mAPI con un 1.0.5 Bitcoin SV, podrá enviar transacciones de salida de polvo y transacciones de consolidación directamente a un minero.

Definición de una transacción de consolidación

Para que una transacción sea clasificada como consolidación por el software Bitcoin SV, se deben cumplir algunas condiciones estrictas. nChain y el equipo de SV han realizado un análisis exhaustivo para elegir estos criterios a fin de garantizar que el mecanismo no sea jugable. Nos hemos equivocado mucho por el lado de la cautela y, por lo tanto, hay mucho espacio para que los criterios se relajen en el futuro, pero los criterios actuales permiten que una transacción de consolidación se construya de manera bastante simple.

Una transacción de consolidación es una transacción que reduce la cantidad de UTXO por un margen que es más valioso para la red que la tarifa implícita. Por lo tanto, permitimos transacciones de consolidación sin ningún cargo.

Las condiciones para una operación de consolidación son las siguientes:

  •  Los tamaños de scriptPubKey de las salidas de transacción gastadas se comparan con los tamaños de scriptPubKey de la transacción de consolidación. La suma del primero debe ser mayor que la suma del segundo multiplicada por el factor de consolidación (parámetro de configuración: minconsolidationfactor)
  •  El recuento de entradas de transacciones debe ser mayor que el recuento de salidas de transacciones multiplicado por minconsolidationfactor
  • Todas las entradas deben tener un recuento de confirmación de al menos un mínimo de madurez de entrada de consolidación.
  • Los tamaños de scriptSig de la transacción de consolidación tienen un límite superior de bytes de tamaño máximo de entrada de consolidación para evitar juegos.
  • Las entradas gastadas en transacciones de consolidación deben cumplir con la prueba anterior de isStandard () si acceptnonstdconsolidationinput es igual a 0
  • El valor predeterminado para maxconsolidationinputscriptsize es 150 bytes.
  • El valor predeterminado para minconsolidationfactor es 20
  • El valor predeterminado para minconsolidationinputmaturity es 6 (equivalente a una hora)
  • El valor predeterminado para acceptnonstdconsolidationinput es 0, lo que significa que solo se permiten entradas estándar
  • Establecer minconsolidationfactor en 0 deshabilita la función de transacciones de consolidación gratuitas

La condición como fórmula es:

Como regla general:

  • Consolide al menos 100 entradas en una salida.
  • Utilice únicamente entradas p2pkh estándar o multisig desnudo con no más de 2 firmas.
  • Utilice únicamente entradas confirmadas para al menos 6 bloques.
    • Esta regla se puede eludir simplemente construyendo la transacción usando todas las entradas disponibles pero no transmitiéndola hasta 6 bloques después de haberla hecho.

Al seguir estas pautas, debe cumplir con los criterios estrictos. Lo peor que puede suceder si no lo hace es que la transacción sea rechazada con un mensaje de ‘tarifa demasiado baja’, en cuyo caso puede ajustarla e intentarlo de nuevo.

El conjunto disponible de modelos de precios de transacciones será determinado finalmente por los mineros y probado por las fuerzas del mercado. Este modelo en particular pretende ser una demostración de lo que es posible cuando se eliminan las restricciones. El equipo de SV espera ver de qué formas innovadoras se pueden utilizar los nanopagos.

 

Más allá de los micropagos: el auge de los nano servicios

16 de septiembre de 2020

https://bitcoinsv.io/2020/09/16/bitcoin-sv-node-software-important-upgrade-to-v1-0-5/

Bitcoin SV 1.0.5 ‘Rails’ release is out today

– Journalling block assember – batch sendrawtransaction

– free consolidation transactions

– lowered dust limit by 75%

https://bitcoinsv.io/2020/09/16/mapi-v1-1-release/

mAPI 1.1 also released (formerly known as Merchant API)

– batch transaction submissions for high volume users that want to avoid round trip latency.

 

I published an explanation of consolidation transactions and how they enable the rise of nanoservices:

https://bitcoinsv.io/2020/09/16/beyond-micropayments-the-rise-of-nano-services/

 

 

 

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *