Pague para anclar
El script de salida Pay to Anchor (P2A) no es un “script de bloqueo” en ese sentido. No requiere información adicional para ser válido para su inclusión en la cadena de bloques. Es “cualquiera_can_spend”, es decir, cualquiera puede crear una entrada que hace referencia a la salida de transacción según su punto de salida y gastarlo con un script de entrada vacío y pila de testigos. Por supuesto, cada salida sigue siendo única (identificada por su superar) solo se puede gastar mediante una transacción.
Salidas nativas de segwit
P2A cae en la categoría de scripts nativos de salida de SEGWIT. Los scripts nativos de salida de Segwit siguen el patrón
Cuando el pago para presenciar el hash de la clave pública (P2WPKH) y el pago para presenciar el script hash (P2WSH) se introdujeron, fueron designados “Native Segwit Versión 0”, por lo que sus guiones de producción comienzan con OP_0 (que produce direcciones que comienzan con bc1q). Para Segwit V0 nativo, los programas de testigos de longitud de 20 bytes deben adherirse a las reglas P2WPKH, los programas de testigos de la longitud de 32 bytes deben adherirse a las reglas P2WSH, y Todas las otras longitudes al lado de 20 y 32 bytes fueron declarados inválidos.
Se eligió un enfoque diferente para la versión 1 de Segwit nativo. Cuando se introdujo el pago a Taproot (P2TR), se designó que las reglas P2TR solo se aplican a las salidas de Segwit nativas de programas de testigos de 32 bytes, y todas Otras longitudes quedaron sin gravación. Los scripts nativos de salida de Segwit V1 comienzan con OP_1 que produce direcciones que comienzan con bc1p.
P2A también es un script de salida nativo de Segwit V1. Por lo tanto, también comienza con OP_1 y su prefijo de dirección es bc1p. El programa de testigos fue elegido para ser la longitud mínima del programa de testigos permitido de dos bytes. Se eligieron los dos bytes porque hacen que la dirección resultante contenga las “tarifas” de la cadena. P2A siempre es válido, simplemente porque todos los scripts de salida de Segwit nativos se consideran válidos y no se introdujeron más reglas para restringirlo. Cualquiera puede gastar cualquier salida de P2A simplemente haciendo referencia al punto de salida de la salida (txid:vout) en una entrada de transacción sin necesidad de más información en la entrada. Como con todas las entradas que gastan salidas de Segwit nativas, el script de entrada (también conocido como scriptSig) está vacío, pero para P2A la pila de testigos también está vacía.
Amigos de P2A: Truc y 1p1c
P2A se introdujo en Bitcoin Core V28.0 junto con dos actualizaciones relacionadas con el comportamiento de Mempool: _ Topológicamente restringido hasta las transacciones de confirmación (TRUC )_ y Relé de paquete 1p1c oportunista (1P1C). Resumido brevemente, un remitente puede crear opcionalmente transacciones TRUC que se limitan a tener un hijo o uno padre y limitado en peso al establecer la versión de transacción en 3. Esto restringe las transacciones TRUC a los paquetes de la mayoría de las dos transacciones relacionadas en la memoria (pero también se permite una única transacción TRUC).
Un nodo generalmente sabrá sobre todos los utxos gastados por transacciones, pero a veces, aprenderemos sobre una transacción infantil antes de ver a su padre. En ese caso, no sabemos sobre uno de los utxos gastados por la transacción infantil, y ponemos esto huérfano Transacción En una estructura de datos llamamos el “orfanato”. 1P1C mejora la resolución huérfana para paquetes con dos transacciones. En explicit, no podemos validar una transacción con insumos desconocidos, ni determinar su Feerate. Después de recibir uno, le preguntamos al compañero que nos anunció al niño para la transacción principal. En basic, cuando un nodo aprende sobre una transacción que no cumple con su mínimo dinámico Feerate, rechaza esa transacción. En versiones anteriores, cuando el par proporcionaba la transacción de los padres desaparecidos, y el Feerate de la transacción principal no cumplía con el mínimo de nuestro nodo, rechazaríamos al padre y al huérfano permanecería en el orfanato. 1P1C mejora la situación de tal manera que cuando se rechaza una transacción de los padres debido a que no cumple con el mínimo de Feerere, mientras que tenemos a su hijo en el orfanato, posteriormente intentamos presentar a los padres e hijos juntos como un paquete. Si la tarifa del niño hace que el paquete cumpla o exceda el mínimo de Feerate, ambos se agregan a la Mempool a la vez. Esto también permite que dichos pares de transacciones con un padre feerado bajo se propagen (aunque no de manera confiable), lo que aborda un punto de dolor de la crimson de rayos donde los feerates de las transacciones de compromiso tuvieron que estimarse lo suficientemente altos como para llegar a la memoria incluso si los feerates se dispararon, porque el CPFP period insuficiente para obtener transacciones de los padres de Feereres en la MEMPOOL.
Polvo efímero
Bitcoin Core generalmente requiere que las salidas de transacciones cumplan con el límite de polvo. Bitcoin Core V29.0 presenta una nueva política de Mempool llamada Polvo efímero: Una transacción puede tener una salida única con una cantidad inferior al límite de polvo si la transacción paga cero tarifas (que requiere que sea una transacción TRUC). Cualquier gasto de transacción no confirmado de los padres de 0 tarifas debe gastar la salida de polvo. Como la transacción principal de 0 tarifas no cumple con el mínimo de Feerate por sí mismo, lo que generalmente significa que se somete a una transacción infantil que gasta inmediatamente la salida de polvo, lo que la hace efímera.
Anclajes efímeros
Mientras que P2A se puede usar independientemente de TRUC o polvo efímero, TRUC se puede usar independientemente de P2A, y la nueva regla de envío de paquetes puede beneficiar a cualquier paquete de 2 transacciones (ver @respuesta de Glozow), Anclajes efímeros Usar todos juntos: (padre) Las transacciones TRUC pueden tener una tarifa de cero, P2A minimiza el peso de la transacción para crear paquetes CPFP, 1P1C permite que dos transacciones relacionadas se propagen como paquetes, y el polvo efímero asegura que las salidas de anclaje no se demoren en el conjunto UTXO. Por ejemplo, ahora podemos tener transacciones de compromiso LN con cero tarifas y un P2A con una cantidad de 0; Si alguna parte quiere cerrar unilateralmente el canal, adjunta a un niño que paga las tarifas apropiadas estimadas al momento de crear el niño y el paquete se propaga juntos. Además, 1P1C obtuvo una mejora en Bitcoin Core V29.0: en lugar de preguntar solo al compañero que nos envió un huérfano para la transacción principal, el nodo le pedirá a cualquier compañero que anunciara el huérfano que mejora la robustez de la propagación de 1P1C.
El script de salida P2A en detalle
Debido a que el programa de testigos es solo dos bytes, el script de salida P2A es solo cuatro bytes: 0x51024e73, OP_1, Op_pushbytes_2y el programa de testigos de dos bytes. Esto hace que la salida completa 13 bytes (8 bytes para la cantidad de salida, un byte para la longitud del script de salida, cuatro bytes script de salida). Y toda la entrada 41 bytes (36 bytes para el punto de salida que identifica qué utxo se está gastando (32 bytes para el txid, 4 bytes para el vout), 4 bytes para el nSequencey
Miremos por ejemplo en la transacción 5bad … 32dc. Tiene una entrada de teclado P2TR, una salida P2A y una salida P2TR:
Si echa un vistazo a la transacción serializada (a través de Yogh.io), ve esto:
(1) el 02 byte indica dos salidas, la siguiente (2) ocho bytes 6d 03 00 00 00 00 00 00 codifica una cantidad de 877 satoshis, el (3) 04 indica la longitud del script de salida de cuatro bytes, y (4) detectamos el script de salida P2A discutido 0x51024e73.
La transacción que gasta la salida P2A 58A8BF720444561CA4CB9AE76D117854FBED5671DBBAD0DE4C81397E9FEE05AE Por otro lado, contiene una entrada que identifica únicamente qué salida está gastando con un script de entrada vacío y un script de testimonio:
Desafortunadamente, parece que Yogh.io no puede manejar transacciones con entradas P2A todavía. De todos modos, el hexadecimal de la transacción es:
0200000001DC3244A5E18EF8B38987A375956282839F96E36F04B75F068DCF63A837C1AD5B000 0000000FDFFFFFF010000000000000000116A0F696E20666565732077652072757374AC800D00
02000000 ↦ tx model 2
01 ↦ one enter
dc3244a5…37c1ad5b ↦ spent output’s txid (little endian) 5badc137…a54432dc
00000000 ↦ output’s place 0 in prior tx
00 ↦ enter script size of 0
fdffffff ↦ nSequence MAX-2
01 ↦ one output
0000000000000000 ↦ quantity of 0
11 ↦ 17 bytes of output script to comply with
6a ↦ OP_RETURN
0f ↦ OP_PUSHBYTES_15
696e20666565732077652072757374 ↦ ASCII for "in charges we rust"
ac800d00 ↦ locktime of 884908
Como puede ver, la entrada no tiene pila de testigos, y la longitud del script de entrada es cero, por lo que la entrada tiene el peso mínimo de 41 bytes. Esto significa que una salida P2A más la entrada simplemente 64 VB, que es mucho menos uniforme que el campeón anterior entre las salidas de transacciones estándar gastables, P2WPKH, que viene en 99 VB (salida de 31 Vb + Entrada de 68 VB).
Debido a que P2A tiene muy poco peso, es una forma barata de permitir que cualquier parte aumente una transacción por transacción infantil.
Correcciones
- Una versión anterior de esta respuesta declaró que las salidas P2A no eran estándar antes de la introducción formal del script de salida P2A. Todas las salidas nativas de SEGWIT son aceptadas como válidas por cualquier versión de Bitcoin Core. Las transacciones del gasto en futuras versiones nativas de SEGWIT se consideran estándar Desde Bitcoin Core 0.19.0. Gracias @gelenor.
- Una versión anterior de esta respuesta atribuyó la no estándar previa de los anclajes efímeros a las salidas de P2A en basic. Los anclajes efímeros no fueron estándar debido a violar el límite de polvo, pero las salidas de P2A con cantidades mayores ya estaban generalmente aceptadas. Gracias @thunderbiscuit.
- Una versión anterior de esta respuesta no distinguió adecuadamente el polvo efímero y los anclajes efímeros. El polvo efímero generalmente permite una sola salida de polvo en una transacción de 0 tarifas, mientras que los anclajes efímeros se refieren a la combinación de P2A y polvo efímero en transacciones TRUC juntas. Gracias @glozow.
