Bitcoin Wiki
Bienvenido a Bitcoin Wiki
Texto original en inglés. (87 páginas, algunas entradas no están finalizadas aún)
Aquí nuestro objetivo es proporcionar un conjunto correcto y actualizado de información sobre la red Bitcoin y sus características y funcionalidades.
Bitcoin
Bitcoin es un sistema de efectivo electrónico de igual a igual creado por el Dr. Craig Wright bajo el seudónimo de Satoshi Nakamoto . Se detalló por primera vez en el documento técnico de Bitcoin en octubre de 2008, y el código fuente se lanzó en enero de 2009. El primer bloque se extrajo el 3 de enero de 2009.
Bitcoin permite que los pagos electrónicos se envíen directamente de una parte a otra, sin necesidad de que una institución central o servidor procese transacciones y / o almacene fondos.
La estructura sin líder de la red se ve como una resolución al Problema de los Generales Bizantinos que permite a las entidades desconectadas seguir una dirección común sin instrucción centralizada. Esto resuelve varios problemas que antes se consideraban insolubles en redes distribuidas, incluido el problema de evitar el doble gasto de monedas en la red
Aplicaciones
Bitcoin es principalmente un sistema de pago que admite conexiones punto a punto y transacciones instantáneas . Al principio de la historia de los pagos de Bitcoin , los usuarios debían comprender detalles técnicos complicados de los fundamentos tecnológicos de Bitcoin para realizar transacciones. Pero desarrollos como Paymail y Verificación de pago simplificada están cambiando el panorama y facilitando la conexión de los usuarios.
Bitcoin también admite el desarrollo de protocolos de capa de aplicación que utilizan Bitcoin Transactions como una capa de transporte para el intercambio de información. Ya existen varios protocolos de capa de aplicación para BitcoinSV; para obtener más detalles, consulte Creación de Bitcoin . Metanet fusiona las transacciones por debajo del centavo altamente seguras e instantáneas de Bitcoin con el almacenamiento de datos en cadena y la transferibilidad, lo que permite un uso web eficiente y seguro. Esto generará una Internet de valor donde los micropagos se convierten en un medio para acceder y monetizar los datos.
Las aplicaciones que hacen uso de la naturaleza inmutable del Bitcoin Ledger para almacenar y recuperar datos están surgiendo a un ritmo cada vez mayor. Las secuencias de comandos de retorno falso y otras secuencias de comandos que utilizan códigos de operación Pushdata para insertar datos en transacciones de Bitcoin están creando nuevas formas de registrar datos para el consumo público. Bitcoin actúa como un servidor de marca de tiempo que permite validar y hacer referencia a los datos mediante transacciones.
El libro mayor
El libro mayor de Bitcoin es un registro de todas las transacciones que se han marcado en la red. El libro mayor se forma como un gráfico acíclico dirigido (DAG) donde cada transacción es un nodo. El gráfico comienza en la transacción de Coinbase del primer bloque encontrado y a través de cadenas de firmas digitales traza el historial completo de acciones de intercambio válidas, lo que permite el seguimiento de todos los bitcoins hasta su creación.
Las transacciones válidas que se transmiten en The Bitcoin Network están comprometidas con el libro mayor por los mineros en Blocks . Un bloque consiste en una lista ordenada de hashes de transacciones y un encabezado que incluye la raíz generada al trocear las transacciones enumeradas en un árbol Merkle , una marca de tiempo, una referencia al bloque sobre el que se basa y los medios para validar la Prueba de trabajo necesaria para otros mineros para aceptar el bloque como válido.
Los bloques forman un DAG de segunda capa llamado la cadena de bloques que es construida por los mineros de la red en un proceso competitivo. Cada bloque forma un nodo en el gráfico con un solo borde entrante del bloque sobre el que está construido. Un bloque puede tener más de un borde saliente en un caso en el que se construyeron varios bloques sobre él, pero solo uno de esos bordes puede convertirse en parte de la cadena de prueba de trabajo más larga. Un bloque sin borde para la cadena más larga de prueba de trabajo se llama Bloque huérfano .
La estructura de la cadena de bloques DAG significa que hay una ruta claramente rastreable de regreso al primer bloque extraído . Los bloques se descubren en promedio cada 10 minutos, y los mineros usan un algoritmo matemático predefinido para controlar la dificultad del proceso de prueba de trabajo para mantener ese período de tiempo.
Las transacciones se pueden intercambiar de igual a igual utilizando Verificación de pago simplificada (SPV) para administrar la confianza. SPV implica el envío de información adjunta con una entrada de transacción que demuestra que es de una transacción que ha sido marcada en el libro mayor.
Los usuarios pueden intercambiar transacciones no finalizadas sin enviarlas a la red para extraerlas, creando lo que se llaman canales de pago . Los canales de pago permiten a los usuarios realizar intercambios de información dentro de transacciones válidas de Bitcoin, solo transmitiendo una transacción finalizada que incluye el intercambio de valor total a la red minera una vez que se completa la transferencia de información.
Una vez que se envían las transacciones a la red, se puede llegar a un consenso global sobre la validez en menos de 2 segundos. Si los mineros no aceptan una transacción y se agrega a un bloque, no se convierte en parte del libro mayor.
Transacciones
Todas las transacciones de Bitcoin son pagos de algún tipo. Las transacciones se escriben en un lenguaje flexible de secuencias de comandos que se utiliza para asignar el control de custodia a cada salida de transacción mediante la creación de condiciones de gasto arbitrarias definidas por secuencias de comandos.
Cada transacción usa ‘ monedas ‘ como entradas y las gasta en un nuevo conjunto de monedas como salidas . Cuando las monedas se gastan en una transacción, se destruyen.
El lenguaje de secuencias de comandos de Bitcoin se puede usar de una manera que sea completa para Turing , creando una máquina de Turing que use el libro mayor de Bitcoin como una cinta, leyendo y escribiendo desde el gráfico de transacción según sea necesario.
El script también incluye códigos de operación que permiten a los usuarios incrustar datos arbitrarios en las transacciones, lo que permite la creación de protocolos de capa de aplicación que usan transacciones de Bitcoin como capa de transporte .
Las recompensas pagadas a los mineros por la creación de un bloque se inscriben en lo que se llama una transacción de Coinbase . Esta transacción tiene un formato específico y siempre es la última transacción en el árbol Merkle del bloque .
Nodos y Minería
El libro mayor se mantiene en una red distribuida de nodos que utilizan la Prueba de trabajo basada en hash para competir por el derecho de extenderla y como un medio para hacer cumplir las reglas de la red. La prueba de trabajo de cada bloque en la cadena de trabajo más larga se incorpora en su bloque posterior para formar la estructura de la cadena.
Durante el proceso de minería, un nodo reúne transacciones de la red y evalúa si son rentables para minar antes de colocarlas en una plantilla de bloque. Las plantillas de bloque se crean calculando la raíz de un árbol Merkle que contiene todas las transacciones que se extraen. El orden de las transacciones en el árbol de Merkle no está relacionado con su posición en el DAG de la transacción. A medida que llegan nuevas transacciones, se agregan al árbol, creando una plantilla nueva y actualizada. Se encuentra un bloqueo cuando un minero descubre con éxito un valor que genera un hash menor que el objetivo de dificultad . El minero debe propagar el nuevo bloque al resto de la red, que luego debe construir 100 bloques adicionales encima de él antes de que el ganador pueda reclamar la recompensa del bloque.
Los nodos son operados por las empresas mineras de Bitcoin que construyen la red. Los incentivos económicos de Bitcoin están estructurados de tal manera que para que los nodos sean más rentables en la construcción del libro mayor, deben estar tan estrechamente conectados con otros nodos con buen rendimiento como sea posible. Esto lleva a los mineros a formar una Red del Mundo Pequeño que tiende hacia un Gráfico Casi Completo donde todos los mineros están conectados con todos los demás mineros. Los mineros recolectan transacciones de usuarios que se conectan en una red en capas a través de los nodos en el núcleo que forma una Red Mandala . En esta red shell, los pares utilizan la Verificación de pago simplificada para formar una estructura mucho menos densa en la que se intercambia información en los Canales de pago .
A medida que se escala Bitcoin, los nodos que componen la red se dividirán en compartimentos en hardware especializado. Estos sistemas agrupados se distribuirán globalmente, cada uno de ellos ubicado en una ubicación optimizada para su tarea.
Como organizaciones empresariales, los mineros de Bitcoin deben operar como entidades legales dentro de una jurisdicción determinada y, como tales, están sujetos a las leyes y procesos legales que existen en esa jurisdicción. A través de esto, los mineros pueden verse obligados a promulgar ciertas reglas o realizar ciertas acciones para cumplir con la ley. Esto puede incluir la congelación o transferencia de bitcoins almacenados en el libro mayor, o el rechazo de transacciones o bloques que intentan gastar bitcoins identificados como producto del delito.
Unidad de cuenta
Satoshis es la unidad de cuenta nativa del libro mayor y 100,000,000 satoshis se abstraen en un bitcoin. Los Satoshis se guardan en rompecabezas de guiones llamados Salidas de transacciones no gastadas o UTXO . Estas son salidas de transacciones que los mineros mantienen en una base de datos de acceso rápido llamada conjunto UTXO. Durante el proceso de gasto, los UTXO que se usan en una transacción se consumen y la solución a su script de rompecabezas se registra en la transacción.
Satoshis son emitidos por los mineros a sí mismos como un pago de subsidio durante la fase de establecimiento de la red. A medida que la red madura, el subsidio se disipa obligando a los mineros a encontrar fuentes alternativas de ingresos. El pago permite a los mineros financiar sus operaciones mediante el pago de bienes y servicios en bitcoin, extendiéndolo a través de la economía.
Reglas de red
Bitcoin opera en un conjunto de reglas fijo. Las llamadas reglas de consenso incluyen cosas como la operación de los códigos de operación en Bitcoin Script, la velocidad a la que se emiten los nuevos bitcoins, la función matemática utilizada para calcular el objetivo del algoritmo de Dificultad y más. El protocolo es acordado por los mineros que controlan la operación de la red.
No hay límites en el protocolo Bitcoin . Los mineros imponen los límites impuestos y se les incentiva a capturar los mayores grupos rentables de transacciones que puedan. Los mineros compiten para ofrecer un mejor servicio a los usuarios que pagan tarifas al escalar sus propias capacidades.
Historia
Bitcoin tiene una rica historia y ha sido atacado de muchas maneras desde su inicio. Por ejemplo, al momento de escribir, ciertos otros grupos están usando erróneamente el nombre ‘Bitcoin’ para referirse a sus propios proyectos. El más famoso de estos utiliza una implementación de software conocida como ‘núcleo de Bitcoin’ con tokens del libro mayor comercializados como ‘BTC’ (más información) .
Herramientas y construcción en Bitcoin
Bitcoin tiene un conjunto rico y diverso de herramientas que se agregan todo el tiempo.
Texto original en inglés: https://wiki.bitcoinsv.io/index.php/Main_Page
Bloque de Génesis
El Genesis Block es el primer bloque en la cadena de Bitcoin Block y se puede encontrar en Block Height zero. El hash del bloque Genesis es 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
El bloque Génesis es el ancestro común de todos los demás bloques. Está conectado al software del cliente del nodo Bitcoin y no se puede eliminar ]
El bloque Genesis tiene una marca de tiempo del 3 de enero de 2009, 18: 15: 05h UTC.
Coinbase
El parámetro coinbase contiene, junto con los datos normales, el siguiente texto:
The Times 03 / Jan / 2009 Canciller al borde del segundo rescate financiero para bancos
La cita es del siguiente artículo de The Financial Times (copia en caché archive.org)
El artículo se refiere a la intervención del estado en la banca en tiempos de crisis y la devaluación de las monedas emitidas centralmente en tiempos de rescate como un incentivo para los malos actores. El Dr. Craig Wright analiza este tema en este artículo escrito bajo el seudónimo ‘Adam Selene’.
Marca de tiempo
Aunque el tiempo promedio entre los bloques de Bitcoin es de 10 minutos, la marca de tiempo del siguiente bloque es de 6 días completos después del bloque de génesis. El Dr. Craig Wright ha indicado que el retraso se produjo porque Microsoft lanzó un parche programado para Windows que provocó que todas sus computadoras se apagaran a la vez, y requirió varios días antes de que pudiera volver a funcionar.
Datos de bloque sin procesar
La versión hexadecimal cruda del bloque Génesis se ve así:
00000000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
00000020 00 00 00 00 3B A3 ED FD 7A 7B 12 B2 7A C7 2C 3E …. ; £ íýz {.²zÇ,>
00000030 67 76 8F 61 7F C8 1B C 3 88 8A 51 32 3A 9F B8 AA gv.a.È.ÈŠQ2: Ÿ¸ª
00000040 4B 1E 5E 4A 29 AB 5F 49 FF FF 00 1D 1D AC 2B 7C K. ^ J) «_ Iÿÿ … ¬ + |
00000050 01 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 …………….
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …………….
00000070 00 00 00 00 00 00 FF FF FF FF 4D 04 FF FF 00 1D …… ÿÿÿÿM.ÿÿ ..
00000080 01 04 45 54 68 65 20 54 69 6D 65 73 20 30 33 2F .. EThe Times 03 /
00000090 4A 61 6E 2F 32 30 30 39 20 43 68 61 6E 63 65 6C Ene / 2009 Chancel
000000A0 6C 6F 72 20 6F 6E 20 62 72 69 6E 6B 20 6F 66 20 lor al borde de
000000B0 73 65 63 6F 6E 64 20 62 61 69 6C 6F 75 74 20 66 segundo rescate f
000000C0 6F 72 20 62 61 6E 6B 73 FF FF FF FF 01 00 F2 05 o bancosÿÿÿÿ ..ò.
000000D0 2A 01 00 00 00 43 41 04 67 8A FD B0 FE 55 48 27 * …. CA.gŠý ° þUH ‘
000000E0 19 67 F1 A6 71 30 B7 10 5 C D6 A8 28 E0 39 09 A6 .gñ¦q0 ·. \ Ö¨ (à9.¦
000000F0 79 62 E0 EA 1F 61 DE B 6 49 F6 BC 3F 4C EF 38 C4 ybàê.aÞ¶Iö¼? Lï8Ä
00000100 F3 55 04 E5 1E C1 12 DE 5C 38 4D F7 BA 0B 8D 57 óU.å. Á.Þ \ 8M ÷ º..W
00000110 8A 4C 70 2B 6B F1 1D 5 F AC 00 00 00 00 ŠLp + kñ ._¬ ….
Desglosado se ve así:
01000000 – versión
0000000000000000000000000000000000000000000000000000000000000000 – bloque anterior
3BA3EDFD7A7B12B27AC72C3E67768F617FC81BC3888A51323A9FB8AA4B1E5E4A – raíz de merkle
29AB5F49 – marca de tiempo
FFFF001D – bits
1DAC2B7C – nonce
01 – número de transacciones
01000000 – versión
01 – entrada
0000000000000000000000000000000000000000000000000000000000000000FFFFFFFF – salida anterior
4D – longitud del script
04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73 – scriptsig
FFFFFFFF – secuencia
01 – salidas
00F2052A01000000 – 50 BTC
43 – longitud de pk_script
4104678AFDB0FE5548271967F1A67130B7105CD6A828E03909A67962E0EA1F61DEB649F6BC3F4CEF38C4F35504E51EC112DE5C384DF7BA0B8D578A4C702B6BF11D5FAC – pk_script
00000000 – tiempo de bloqueo
Atribución
Este contenido se basa en el contenido de https://en.bitcoin.it/wiki/Genesis_block bajo Creative Commons Attribution 3.0 . Aunque puede haber sido ampliamente revisado y actualizado , reconocemos a los autores originales.
Texto original en inglés: https://wiki.bitcoinsv.io/index.php/Genesis_block
El problema de los generales bizantinos
El problema de los generales bizantinos fue propuesto por primera vez por Leslie Lamport, Robert Shostak y Marshall Pease como parte de la investigación que se realiza en la NASA. El problema trata de cómo definir cómo dirigir una red de unidades desconectadas en una situación sin líder. Se ha adaptado un poco al problema de Bitcoin para esta descripción, sin embargo, el documento original se puede encontrar aquí .
El problema define cómo los generales pueden emitir comandos sin una estructura de comunicación centralizada mientras permanecen robustos frente a los malos actores que podrían intentar emitir comandos maliciosos al ejército.
El ejército bizantino está acampado fuera de una ciudad dividida en divisiones, cada una controlada por un general. Los generales no tienen medios para comunicarse que no sea a través de mensajeros. Hay generales traidores en el ejército que intentarán emitir órdenes que eviten que los generales leales lleguen a un acuerdo sobre un plan razonable, por lo que el protocolo de mensajería debe garantizar que los receptores de mensajes puedan saber que son de un general leal.
Cualquiera puede presentar un mensaje a un general alegando que es de otro general, por lo que el protocolo debe tener un medio para que los generales sepan con certeza que cualquier movimiento propuesto es de otro general. Se necesita un cifrado que demuestre que el mensaje proviene de un general real. En Bitcoin, Prueba de trabajo demuestra la autoridad de un nodo para escribir bloques en el libro mayor. Este es un elemento central del Consenso de Nakamoto .
El ejército a veces se divide cuando dos generales encuentran movimientos válidos aproximadamente al mismo tiempo. Las órdenes se propagan por un corto período de tiempo para que los generales puedan terminar siguiendo movimientos divergentes.
Si el ejército comienza a separarse, los generales en el grupo que está detrás del frente detendrán lo que están haciendo y se pondrán al día. Esto es lo que sucede en una red Re-org , con el movimiento abandonado creando un Bloque huérfano .
La necesidad de que los generales estén siempre al frente del ejército incentiva a los mejores generales a formar líneas directas de comunicación entre ellos que conduzcan a una comunicación mucho más rápida. En Bitcoin, este incentivo impulsa a los mineros a encontrar la mejor manera de conectarse entre sí, lo que lleva a los miembros de la red principal de Bitcoin a formar una red de mundo pequeño con grandes sistemas altamente conectados. Este núcleo tiende hacia un gráfico casi completo donde todos los nodos están conectados a casi todos los demás nodos.
Encontrar soluciones válidas para la prueba de trabajo generalmente se limita a 6 nodos por hora, por lo que el centro del mandala tiende hacia un tamaño máximo limitado por la ley de Metcalfes . A medida que más nodos se unen a la competencia, se vuelve más costoso mantener las conexiones, por lo que los mineros cortarán instintivamente los lazos con los mineros que no funcionan para conectarse con nodos más nuevos y más potentes. Este elemento de construcción constante para mantener la posición puede describirse como una carrera de la Reina Roja en la que los participantes deben acelerar continuamente para mantener su posición en el campo.
Texto original en inglés: https://wiki.bitcoinsv.io/index.php/The_Byzantine_Generals_Problem
Doble gasto
Definición
El doble gasto es el acto de enviar una transacción que contiene entradas que ya se han gastado, en un intento de cometer fraude en la red.
Consecuencias
El doble gasto es uno de los ataques más comúnmente discutidos en Bitcoin, sin embargo, aún no se ha documentado un caso de alguien que ejecute un doble gasto exitoso usando Bitcoin en el comercio.
La razón de esto es que el doble gasto es un delito y análogo a rebotar intencionalmente un cheque; la diferencia es que el comerciante tendría una prueba criptográfica de que el cliente intentó tal acto.
Incentivos económicos
Bitcoin resuelve el problema del doble gasto a través de sus incentivos económicos. Los mineros tienen un fuerte incentivo para no incluir estas transacciones en un bloque porque corren el riesgo de que otros mineros rechacen su bloqueo y también serían cómplices de llevar a cabo un delito.
Estos factores destacan por qué la solución para duplicar el gasto es una solución económica, no técnica. Los desarrolladores han presentado muchos argumentos en el pasado acerca de que los cambios son necesarios en el protocolo para solucionar este problema, pero todos son innecesarios.
Texto original en inglés: https://wiki.bitcoinsv.io/index.php/Double-spending
Pagos en Bitcoin
Los pagos son un aspecto importante de Bitcoin. Cada transacción es un pago de algún tipo. Las transacciones son el único medio a través del cual se puede escribir información en el libro mayor.
Los eventos de descubrimiento de bloques se acuerdan mediante la aceptación de una transacción de Coinbase como un pago válido. Un bloque es simplemente el proceso de tener una colección de pagos establecida, cotejada y acordada como válida.
Existen muchos métodos para solicitar y realizar pagos.
BIP-0270
BIP270 es una versión simplificada del Protocolo de pago BIP70 introducido en 2013. Es un protocolo para la comunicación entre un host de pagos (generalmente un comerciante, un procesador de pagos o simplemente la billetera del destinatario) y su cliente (el remitente de los fondos) . Permite:
- Mejor experiencia
- Infraestructura de billetera más simple
- Salidas múltiples
- Mejor seguridad contra ataques de hombre en el medio
BIP-270 está diseñado para billeteras que usan Verificación de pago simplificada para lograr grandes mejoras a escala. Las transacciones pueden intercambiarse parcialmente o en iteraciones. Esto es mucho más rápido cuando se realiza punto a punto entre el pagador y el beneficiario, escribiendo al libro mayor solo al final para liquidar la (s) transacción (es).
Este BIP es una optimización de BIP-0070. Los cambios incluyen:
- Mueve todo el intercambio de firmas y validación a la comunicación más tarde (generalmente HTTPS)
- Agregar múltiples salidas
- Una biblioteca optimizada para la gestión de transacciones punto a punto
BSVAlias
BSVAlias es un conjunto de protocolos que establecen una estructura para realizar y recibir pagos utilizando la identidad como medio para vincular remitente y receptor.
Paymail es la primera implementación práctica de BSVAlias.
Canales de pago
Cualquier transacción que tenga un nLocktime en el futuro y una nSequence que sea menor que 0xFFFFFFFF no se finaliza, y potencialmente desde un canal de pago . La transacción se puede actualizar una vez, o muchas veces entre pares hasta que se finalice nSequence o se agote nLocktime y una de las partes transmita la transacción a blockchain. Los canales de pago son útiles para transmitir datos, operar una secuencia de eventos u operar con un conjunto de datos en vivo en aplicaciones como juegos y más. Los canales de pago no han estado disponibles desde las primeras versiones de Bitcoin y se han vuelto a habilitar desde la actualización de Genesis , lo que permite muchos casos de uso potenciales.
Protocolos de pago heredados
Estos son protocolos de pago en los que se le pide al pagador que transmita una transacción a la red (en lugar del beneficiario) para que el beneficiario pueda escanear la red en busca de transacciones relevantes en lugar de manejar la transacción de igual a igual como con SPV .
Pagos de IP a IP
La versión original del cliente de nodo de Bitcoin tenía la facilidad de realizar pagos IP-IP donde un receptor podía dar al pagador su dirección IP. El cliente del pagador se comunicaría con el cliente del Beneficiario y solicitaría una clave pública para que se dirija el pago. Este método de pago fue una de las primeras características eliminadas por el equipo de Bitcoin Core cuando se hicieron cargo del proyecto. Se están desarrollando nuevos procesos de pago que se basan en esta idea original y permitirán a los pares de la red interactuar de forma segura utilizando direcciones IP verificadas criptográficamente.
BIP-0021
BIP-0021 ha sido uno de los medios predominantes para realizar pagos móviles en Bitcoin a lo largo de su historia. Casi todas las pasarelas de pago basadas en códigos QR utilizadas en Bitcoin son o son una extensión de BIP0021. BIP0021 en sí es una extensión de RFC-3986 , el estándar RFC para URI (Universal Resource Identifiers).
BIP-0070
BIP-0070 fue un protocolo de pago para llegar a los receptores utilizando una extensión de BIP-0021 que agregó una URL. La URL le indicó al dispositivo que se acercara a un servidor que le proporcionaría un script o una dirección vinculada al código QR.
Texto original en inglés: https://wiki.bitcoinsv.io/index.php/Payments_in_Bitcoin
Paymail
Paymail es una implementación práctica de la familia de protocolos relacionados que se denominan colectivamente BSVAlias . En resumen, es un protocolo de identidad que elimina las direcciones de Bitcoin de la experiencia del usuario. En lugar de direcciones, Paymail utiliza nombres legibles por humanos que se parecen exactamente a las direcciones de correo electrónico. Los correos de pago son mucho más fáciles de escribir en un dispositivo que las direcciones de Bitcoin y pueden usarse para identificar a un individuo a través del identificador de correo de pago.
El protocolo describe un procedimiento en el que un proveedor de billetera podrá ser descubierto y contactado, y puede responder a pagos y solicitudes de pago en tiempo real para que los receptores de pagos no tengan que reutilizar sus direcciones de Bitcoin , manteniendo así la privacidad.
Como ejemplo simplificado, para que Alice envíe algo de bitcoin a Bob, Alice envía el pago a Bob@paymail.com. El protocolo de correo de pago implementado por la billetera de Bob proporcionará un script de Bitcoin para pagar la creación real de la transacción de Bitcoin en lugar de depender del concepto de la dirección de Bitcoin, que en realidad es solo una codificación compacta de un script, pero limita la forma del script a uno genero particular. Esto se hace detrás de la experiencia del usuario. Tenga en cuenta que la seguridad dependerá de una infraestructura de clave pública.
Al momento de escribir, los protocolos cubren:
- Especificaciones de BRFC
- Descubrimiento de servicio
- Infraestructura de Clave Pública
- Direccionamiento de pago
Para obtener más información, visite el sitio web de BSVAlias .
Paymail es el nombre para la implementación de los siguientes protocolos:
- Descubrimiento de servicio
- Infraestructura de Clave Pública
- Resolución básica de direcciones del grupo de protocolos de direccionamiento de pagos
La marca Paymail está reservada para productos y servicios que, como mínimo, implementan cada uno de los protocolos anteriores.
Moneybutton ha publicado contenido que describe Paymail y por qué se necesita aquí
Texto original en inglés: https://wiki.bitcoinsv.io/index.php/Paymail
Verificación de pago simplificada
La verificación de pago simplificada (SPV) se describe en la sección 8 del documento técnico de Bitcoin . Permite que un destinatario de la transacción demuestre que el remitente tiene el control de los fondos de origen del pago que está ofreciendo sin descargar la cadena Block completa , utilizando las propiedades de las pruebas de Merkle . Esto no garantiza que los fondos no se hayan gastado previamente, esta garantía se recibe al enviar la transacción a los mineros de Bitcoin. Sin embargo, en tal caso, la prueba SPV actúa como una fuerte evidencia de fraude respaldada por tecnología de firma digital legalmente reconocida.
SPV permite a los usuarios realizar transacciones seguras entre ellos, de igual a igual, mientras que los nodos actúan para formar la capa de liquidación.
Ventajas
Las ventajas de usar SPV son claras en términos del volumen de datos requerido:
- una billetera puede almacenar todos los encabezados de bloque necesarios en alrededor de 50 MB, esto cubre toda la cadena de bloques (a partir de enero de 2020, con 80 bytes por bloque y alrededor de 620,000 bloques en la cadena). El total crece linealmente a alrededor de 4 MB por año (es decir, aumenta en 80 bytes con cada bloque extraído, independientemente del tamaño de ese bloque).
- contraste esto con los cientos de gigabytes que se necesitarían para almacenar toda la cadena, si no se usará SPV.
- El tamaño de los datos requeridos para las rutas de Merkle es de bytes máximos , donde es el número total de transacciones en un bloque.
Como se explica en la Sección 8 del documento técnico de Bitcoin :
«… [Un cliente SPV] solo necesita conservar una copia de los encabezados de bloque de la cadena de prueba de trabajo más larga, que puede obtener al consultar los nodos de la red hasta que esté convencido de que tiene la cadena más larga y obtener el Merkle rama que vincula la transacción al bloque en el que está marcada la hora …
Y en la Sección 7:
«… Un encabezado de bloque sin transacciones sería de aproximadamente 80 bytes. Si suponemos que los bloques se generan cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4.2MB por año …»
Acercarse
Ha habido muchos malentendidos previos sobre SPV y las transacciones entre pares. Anteriormente, la costumbre era que el remitente del pago simplemente transmitiera el pago a los nodos de la red Bitcoin. El receptor del pago necesitaría filtrar de alguna manera todas las transacciones que ingresan a la cadena de bloques para transacciones específicas relacionadas con ellas (una tarea extremadamente difícil en sí misma). Incluso si el remitente envió la transacción al receptor, así como a los nodos de la red, la costumbre ha sido que el receptor siempre espere a que la transacción sea enterrada en la cadena de bloques al menos a 6 bloques de profundidad, sea cual sea el tipo de transacción, la cantidad o la situación.
El mejor enfoque es que las transacciones entre clientes SPV se negocian de igual a igual y se liquidan en la cadena de bloques a través de los nodos de la red. Una analogía para esto es una transacción realizada utilizando cheque a una velocidad mucho más rápida. El cliente entrega el cheque firmado (transacción) al comerciante, quien luego deposita o cobra el cheque (liquida la transacción en cadena). Cuando / si el comerciante está satisfecho de acuerdo con el riesgo situacional de la transacción, puede entregar los bienes o servicios.
No existe la seguridad absoluta, siempre existe un riesgo contra el costo de ser defraudado (que disminuye exponencialmente a medida que pasa el tiempo). Si la transacción es solo por una taza de café, entonces el comerciante estará expuesto a un riesgo menor que si la transacción es comprar un automóvil, por ejemplo, y se comportarían de manera diferente. Si venden una taza de café, pueden asegurarse de que la transacción que recibieron parece ser válida usando el proceso SPV detallado anteriormente, y enviar la transacción a la red (o incluso a un minero de confianza si usa una API de comerciante ). Dado que probablemente recibirán notificaciones y pruebas de un intento de fraude en cuestión de segundos, no querrán conservar una copia de toda la cadena de bloques para verificar, porque el riesgo que enfrentan no justifica el costo. El SPV es adecuado como un pago sin contacto instantáneo sin un número PIN, aunque podría decirse que la seguridad del SPV es muy superior dado que el descubrimiento de intentos de fraude es rápido. Del mismo modo, no querrán detener a su cliente mientras esperan 6 confirmaciones, simplemente no es necesario, han recibido una transacción que parece ser válida y la red la ha aceptado sin una alerta de doble gasto. Esto probablemente será suficiente para que arriesguen el costo del café.
Árboles Merkle, Raíces Merkle, Caminos Merkle y Pruebas Merkle
Un árbol de Merkle es una estructura utilizada en informática para validar datos; consulte la definición de Wikipedia para obtener más información.
La raíz de Merkle en un bloque de Bitcoin es el hash contenido en el encabezado del bloque , que se deriva del hash de todas las demás transacciones en el bloque.
Una ruta de Merkle en SPV representa la información que el usuario necesita para calcular el valor esperado para la raíz de Merkle para un bloque, a partir de su propio hash de transacción contenido en ese bloque. La ruta Merkle se utiliza como parte de la prueba Merkle.
Una prueba de Merkle en SPV demuestra la existencia de una transacción específica en un bloque específico (sin que el usuario necesite examinar todas las transacciones en el bloque). Incluye la raíz de Merkle y la ruta de Merkle.
- Para crear una prueba Merkle, un usuario o (o su billetera) simplemente necesita la ruta Merkle de la transacción, así como el encabezado del bloque para un bloque determinado (80 bytes).
- Para validar una prueba, un usuario (o su billetera) solo necesita la cadena de encabezados de bloque (a diferencia de toda la cadena de bloques). Es decir, necesitan su propia copia de los encabezados de bloque para todos los bloques, que saben que son precisos. Usando su propia cadena de encabezado de bloque, junto con la transacción (o su hash / id) que desean verificar, así como su prueba Merkle (también conocida como prueba de inclusión), un usuario puede verificar que la transacción aparezca en el bloque encadenar en un bloque específico, sin examinar cada transacción en ese bloque.
Un artículo publicado en marzo de 2019 titulado Merkle Trees y SPV (Craig Wright, 2019) aclaró algunos malentendidos anteriores sobre SPV y la verificación de transacciones. El artículo incluía el siguiente diagrama que muestra cómo los hashes de transacciones pueden relacionarse con la raíz de Merkle en un encabezado de bloque:
Billetera SPV
Una billetera SPV es una billetera liviana que utiliza el mecanismo de SPV para construir transacciones y pagos de Bitcoin.
Para gastar un UTXO, un usuario de una billetera SPV pasará la siguiente información al receptor:
- – the transaction that contains the UTXO as an output,
- The Merkle path of {\displaystyle Transaction_{0}}
- The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)
- {\displaystyle Transaction_{1}} – the transaction that spends the UTXO
Para validar la información, un usuario calcula la raíz de Merkle a partir de la ruta de Merkle de la 
Pago fuera de línea
Tenga en cuenta que al almacenar localmente la
Texto original en inglés: https://wiki.bitcoinsv.io/index.php/Simplified_Payment_Verification
Protocolo de capa de aplicación
Introducción
Los protocolos de capa de aplicación en Bitcoin son conjuntos de reglas definidos y almacenados en transacciones como datos arbitrarios. Los desarrolladores de aplicaciones han implementado varios protocolos para almacenar sitios web, publicaciones en redes sociales, imágenes, identidad y otros tipos de datos, ya que el límite de datos push OP_RETURN se incrementó a 100 KB .
Ejemplo práctico
Con el tamaño del soporte de datos de una salida expandida a 100 KB, podemos almacenar varios tipos de datos creando una salida de retorno falso en una transacción de Bitcoin.
Bitcom es una propuesta de un protocolo para definir protocolos. Bitcom propone almacenar una dirección de Bitcoin como prefijo, asegurando la unicidad y un espacio de nombres.
Un protocolo muy utilizado es el protocolo B: // creado por el desarrollador _unwriter. Este protocolo define cómo se pueden almacenar los archivos en cadena, aprovechando la construcción de Bitcom también definida por _unwriter.
Por ejemplo, para almacenar una foto de un pato, utilizamos el prefijo de protocolo para B: \\:
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
Seguido por los diferentes campos B: \\ define como datos de inserción adicionales:
Aquí está el ejemplo .
Tamaño de transacción ilimitado
Estas construcciones se crearon para trabajar con un tamaño de transacción de 100 KB, pero con la actualización de Genesis se pueden escribir datos mucho más grandes en una sola transacción. Además, los códigos de operación OP_PUSHDATA se pueden usar correctamente en la secuencia de comandos, eliminando la dependencia del uso de OP_RETURN como el único medio para insertar datos en la cadena de bloques .
Protocolos ampliamente utilizados
- Protocolo Metanet : define una estructura gráfica dirigida que almacena datos en la cadena de bloques donde otras aplicaciones pueden consultar y hacer referencia a esos datos fácilmente.
- Protocolo tokenizado : define el protocolo y la plataforma donde los emisores y los usuarios pueden crear, administrar e intercambiar tokens aprovechando los contratos inteligentes incorporados.
- Bitcom : registro descentralizado de protocolos de aplicación, identificado de forma única por una dirección de entrada, lo que demuestra la propiedad. Los protocolos de Bitcom se pueden concatenar junto con un | personaje.
- B: // , C: // , D: // , BCAT : varios protocolos para almacenar archivos en cadena y detalles sobre cómo hacer referencia a ellos en una página web o aplicación.
- AIP: Protocolo de identidad del autor : protocolo simple para firmar datos OP_RETURN arbitrarios y desacoplar la dirección de firma de la dirección de origen de financiación.
- MAP: Protocolo de atributos mágicos : protocolo que asigna datos arbitrarios a través de pares clave / valor en cadena.
- HAIP: protocolo de identidad de autor de hash : similar a AIP, pero hash los datos firmados para dispositivos de menor capacidad.
- Memo SV : protocolo que define varias acciones en la red social en cadena de Memo incrustada en las transacciones OP_RETURN.
- Póngase en contacto con la Asociación de Bitcoin para agregar su protocolo estable y publicado.
Texto original en inglés: https://wiki.bitcoinsv.io/index.php/Application_layer_protocol
Transacciones de Bitcoin
Una transacción de Bitcoin consta de un número de versión, un valor de tiempo de bloqueo, una lista de entradas y una lista de salidas.
La funcionalidad principal de una transacción de Bitcoin es transferir la custodia de bitcoin de una a otra.
Una transacción de Bitcoin también puede servir como vehículo para contratos inteligentes, registro de datos, certificación y muchas otras funcionalidades secundarias.
Se puede crear e iterar una transacción dentro de un canal de pago utilizando los enclavamientos nLocktime y nSequence , o enviarla directamente a The Bitcoin Network para su inscripción en un bloque . Una transacción utiliza salidas de transacciones no gastadas (UTXO) como entradas y distribuye su valor a las nuevas salidas. Los UTXO son las ‘monedas’ en las que se almacenan todos los bitcoins.
Las transacciones no están encriptadas, por lo que es posible navegar y ver todas las transacciones que se hayan recopilado en un bloque. Una vez que las transacciones han sido vistas y validadas por la mayoría de los nodos que crean bloques en la red de Bitcoin, pueden considerarse resueltas. Cuando finalmente se extraen en un bloque, los mineros acuerdan en colaboración el orden en que fueron vistos por la red.
Se hace referencia a las transacciones utilizando su TXID, que es un hash SHA-256 doble de la transacción completamente serializada.
Los resultados de las transacciones son scripts de rompecabezas llamados ScriptPubKeys que generalmente se usan para bloquear el valor de bitcoin contenido, a veces también llamado script de bloqueo. Los resultados se canjean convirtiéndolos en entradas para nuevas transacciones y proporcionando un ScriptSig (a veces llamado script de desbloqueo) que es una solución válida que desbloquea el bitcoin contenido en el ScriptPubKey (script de bloqueo). Las salidas pueden tener un valor cero en bitcoin, pero pueden llevar valor en otra forma, como datos o tokens. Los scripts pueden ser complejos y especializados y pueden tener más de una forma de canjearse.
Todas las transacciones se capturan en el libro mayor en bloques en la cadena de bloques y se pueden ver con un explorador de bloques . Esto puede ser útil para ver los detalles técnicos de las transacciones en acción y para verificar los pagos.
Formato general de una transacción de Bitcoin
A continuación se describen los elementos que se serializan para crear una transacción válida de Bitcoin.
| Campo | DESCRIPCIÓN | Tamaño |
|---|---|---|
| Version no | currently 2 | 4 bytes |
| In-counter | positive integer VI = VarInt | 1 – 9 bytes |
| list of inputs | Input Structure | <in-counter> qty with variable length per input |
| Out-counter | positive integer VI = VarInt | 1 – 9 bytes |
| list of outputs | Output Structure | <out-counter> qty with variable length per output |
| nLocktime | if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final | 4 bytes |
Entradas y salidas de transacciones
Cada transacción de Bitcoin se compone de entradas y salidas. Las entradas proporcionan los fondos que se gastarán en la transacción, y las salidas definen dónde se deben asignar esos fondos.
Entradas
Una entrada es una referencia a una salida de una transacción anterior, y una transacción puede incluir entre 1 y 2 32 entradas.
Todo valor de entrada de la nueva transacción (es decir, el valor de la moneda total de las salidas anteriores referenciados por las entradas de la nueva transacción) se suman, y el total (menos cualquier transaction_fees ) se consume por las salidas de la nueva transacción.
El tx anterior es el TXID de una transacción anterior.
El índice es la salida específica en la transacción referenciada.
ScriptSig es la primera mitad de un script que se proporciona cuando se gasta un UTXO como entrada para una transacción.
Un ScriptSig de entrada puede contener muchos componentes. Para canjear un script P2PKH, la entrada debe proporcionar una clave pública y una firma ECDSA . La clave pública se duplica en hash (Primero SHA-256 luego RIPEMD-160 ) y el hash resultante debe coincidir con el hash incrustado en ScriptPubKey de la salida que se canjea.
La clave pública se usa para verificar la firma del redentor. Dependiendo de los indicadores SIGHASH utilizados, la firma puede cubrir un hash que representa parte o la totalidad de la transacción. Combinado con la clave pública, esto prueba que la transacción fue creada por una persona o proceso que controla las claves necesarias para gastar el bitcoin en la entrada.
Formato de una entrada de transacción
También conocido como TXIN, la siguiente tabla describe los elementos necesarios de una entrada de transacción válida.
| CAMPO | DESCRIPCIÓN | TAMAÑO |
|---|---|---|
| Previous Transaction hash | TXID of the transaction the output was created in | 32 bytes |
| Previous Txout-index | Index of the output (Non negative integer) | 4 bytes |
| Txin-script length | Non negative integer VI = VarInt | 1 – 9 bytes |
| Txin-script / scriptSig | Script | <in-script length>-many bytes |
| Sequence_no | Used to iterate inputs inside a payment channel. Input is final when nSequence = 0xFFFFFFFF | 4 bytes |
La entrada describe suficientemente dónde y cómo obtener el monto de bitcoin para canjear. Si es la (única) entrada de la primera transacción de un bloque, se llama el mensaje de Coinbase e incluye información sobre en qué bloque se extrajo y un elemento de datos configurable del minero.
Salidas
Una salida contiene un fragmento de secuencia de comandos de Bitcoin que se puede usar para bloquear bitcoins, lo que requiere que se proporcione un cierto conjunto de claves o información para desbloquearlos. Las salidas también se pueden usar para inscribir datos en el libro mayor.
Este ScriptPubKey es la segunda mitad de un script completo y solo se completa cuando se gasta la salida. Puede haber más de una salida, y comparten el valor combinado de las entradas. El valor de cada salida es el número de Satoshis que el script desbloquea cuando se resuelve. Como cada salida de una transacción solo puede ser referenciada una vez por una entrada de una transacción posterior, el valor completo de las entradas combinadas debe asignarse a las salidas de la transacción. Cualquier Satoshis que no se haya asignado se considera que se paga en tarifas de minería y se otorga al minero cuyo nodo genera el bloque en el que se incluye la transacción.
Si la entrada de un usuario es mayor que el valor que desea enviar, la transacción debe crear al menos dos salidas, una enviando los fondos necesarios al destino y otra enviando el cambio al usuario.
Las salidas pueden tener un valor de cero satoshis. Actualmente, estas salidas están limitadas a los scripts de False Return y se usan típicamente para transportar otra información o tokens para protocolos de capa de aplicación .
Formato de una transacción de salida
También conocido como TXOUT, la siguiente tabla describe los elementos necesarios de una salida de transacción válida.
| Campo | Descripción | Talla |
| valor | entero no negativo que da el número de Satoshis a transferir | 8 bytes |
| Txout-script length | entero no negativo | 1 – 9 bytes VI = VarInt |
| Txout-script / scriptPubKey | Guión | <longitud del script de salida> -muchos bytes |
El scriptPubKey de la salida establece las condiciones para liberar esta cantidad de bitcoin más tarde. La suma de los valores de salida de la primera transacción es el valor de los bitcoins extraídos para el bloque más las posibles tarifas de transacción de las otras transacciones en el bloque.
Validación de transacciones
Para verificar que las entradas estén autorizadas para recopilar los valores de las salidas referenciadas, Bitcoin utiliza un sistema de secuencias de comandos similar a Forth . El scriptSig de la entrada y el scriptPubKey de la salida a la que se hace referencia se evalúan (en ese orden), con scriptPubKey que utiliza los valores que deja scriptSig en la pila. La entrada está autorizada si scriptPubKey devuelve verdadero. A través del sistema de secuencias de comandos, el remitente puede crear condiciones muy complejas que deben cumplirse para reclamar el valor de la salida.
Por ejemplo, es posible crear una salida que pueda ser reclamada por cualquier persona sin ninguna autorización. También es posible exigir que una entrada esté firmada por diez claves diferentes o que se pueda canjear con una contraseña en lugar de una clave.
Rompecabezas y soluciones
El lenguaje flexible de secuencias de comandos habilitado por el protocolo de Bitcoin permite crear una multitud de diferentes tipos de transacciones. Cada par scriptSig / scriptPubKey es validado por los mineros de la red y extraído en un bloque si el script devuelve verdadero. A continuación se describen algunos tipos de rompecabezas de Bitcoin de uso común:
Pagar a clave pública (P2PK)
scriptPubKey: <pubKey> OP_CHECKSIG scriptSig: <sig>
Al canjear monedas que se han enviado a una clave pública de Bitcoin, el script valida que la firma proporcionada fue generada por la clave privada que también corresponde a la clave pública.
Proceso de verificación:
| Apilar | Guión | Descripción |
| Vacío. | <sig> <pubKey> OP_CHECKSIG | scriptSig y scriptPubKey se combinan. |
| <sig> | <pubKey> OP_CHECKSIG | La firma se agrega a la pila. |
| <sig> <pubKey> | OP_CHECKSIG | Pubkey se agrega a la pila. |
| cierto | Vacío. | La firma está marcada. |
Pagar al hash de clave pública (P2PKH)
Una dirección de Bitcoin es solo un hash, por lo que el remitente no puede proporcionar una clave pública completa en scriptPubKey. Al canjear monedas que se han enviado a una dirección de Bitcoin, el destinatario proporciona tanto la firma como la clave pública. La secuencia de comandos verifica que la clave pública proporcionada genera el hash en la secuencia de comandos en scriptPubKey, y luego también comprueba la firma con la clave pública.
Proceso de verificación:
| Apilar | Guión | Descripción |
| Vacío. | <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | scriptSig y scriptPubKey se combinan. |
| <sig> <pubKey> | OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | Las constantes se agregan a la pila. |
| <sig> <pubKey> <pubKey> | OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | El elemento de la pila superior está duplicado. |
| <sig> <pubKey> <pubHashA> | <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG | El elemento de la pila superior está en hash. |
| <sig> <pubKey> <pubHashA> <pubKeyHash> | OP_EQUALVERIFY OP_CHECKSIG | Constante añadido. |
| <sig> <pubKey> | OP_CHECKSIG | La igualdad se verifica entre los dos primeros elementos de la pila. |
| cierto | Vacío. | La firma se verifica para los dos elementos principales de la pila. |
Pagar a R-Puzzle Hash (P2RPH)
Los bitcoins encerrados en un script de R-Puzzle requieren que la parte que gasta firme con un valor conocido para ‘ k ‘ en lugar de un número aleatorio. Para canjear el guión, la parte que gasta proporciona tanto la firma como la clave pública.
El script verifica que la firma proporcionada fue firmada usando el valor k correcto, luego verifica la firma con la clave pública. Debido a que la clave pública no se verifica como parte de la solución de script, es posible firmar la transacción utilizando cualquier par de claves.
Esto puede ser útil cuando se trata de tokens asociados con una dirección de Bitcoin, ya que la clave de pub que corresponde a esa dirección se puede usar para firmar la transacción sin el requisito de que haya bitcoin en la dirección. La técnica también es relevante para la firma de nodos de Metanet, ya que las claves de Metanet se pueden firmar con un R-Puzzle sin necesidad de una firma por separado.
Proceso de verificación:
| Apilar | Guión | Descripción |
| Vacío. | <sig> <pubKey> OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG | scriptSig y scriptPubKey se combinan. |
| <sig> <pubKey> | OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG | Las constantes se agregan a la pila. |
| <sig> <pubKey> <sig> | OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG | El segundo elemento de la pila superior está duplicado. |
| <sig> <pubKey> <3 bytes> <sig ‘> | OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG | Los primeros 3 bytes de firma se dividen |
| <sig> <pubKey> <sig ‘> | OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG | Se elimina el elemento de datos de 3 bytes. |
| <sig> <pubKey> <R Longitud> <sig «> | OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG | 1 byte que contiene la longitud R se divide de sig ‘ |
| <sig> <pubKey> <sig «> <R Length> | OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG | El parámetro R Length se mueve a la parte superior de la pila |
| <sig> <pubKey> <R> <sig ‘»> | OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG | R se separa de sig « |
| <sig> <pubKey> <R> | OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG | sig ‘»== se cae de la pila |
| <sig> <pubKey> <rHashA> | <rHash> OP_EQUALVERIFY OP_CHECKSIG | R tiene doble hash (SHA256 seguido de RIPEMD160) y el resultado se deja en la pila |
| <sig> <pubKey> <rHashA> <rHash> | OP_EQUALVERIFY OP_CHECKSIG | R-Hash previamente definido se inserta en la pila |
| <sig> <pubKey> | OP_CHECKSIG | El script verifica si rHashA = rHash |
| cierto | Vacío. | La firma se verifica para los dos elementos principales de la pila. |
Pagar a la firma múltiple (P2MS)
OP_CHECKMULTISIG ofrece a los usuarios la capacidad de bloquear monedas con el requisito de que varias partes firmen el scriptSig antes de que se puedan gastar las monedas. OP_CHECKMULTISIG puede verificar muchas firmas con muchas claves públicas siempre que las firmas en el scriptSig se proporcionen en un orden que corresponda al orden en el que las claves públicas se ordenan en la pila cuando se ejecuta. El primer código de operación en ScriptPubKey define cuántas firmas se deben proporcionar para que la moneda se gaste con éxito. El último antes de OP_CHECKMULTISIG indica al motor de secuencias de comandos con cuántas claves públicas evaluar esas firmas. Debe haber al menos tantos elementos en la pila como sean necesarios para que se procese el código de operación OP_CHECKMULTISIG o el script no será válido.
Nota: La versión actual del motor de secuencias de comandos también incluye un error que requiere que se coloque un valor adicional en la pila antes de las firmas. En este ejemplo, OP_1 se ha utilizado para empujar un 1 a la parte superior de la pila, pero en teoría se puede usar cualquier dato. El proceso de verificación consume este valor, pero no se evalúa.
Proceso de verificación:
| Apilar | Guión | Descripción |
| Vacío. | OP_1 <sig1> <sig2> <sig4> OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey4> OP_5 OP_CHECKMULTISIG | scriptSig y scriptPubKey se combinan. |
| 1 <sig1> <sig2> <sig4> | OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG | Las constantes de scriptSig se agregan a la pila. |
| 1 <sig1> <sig2> <sig4> 3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 | OP_CHECKMULTISIG | Las constantes de scriptPubKey se agregan a la pila. |
| cierto | Vacío. | Se realiza una evaluación de secuencia de comandos de firma múltiple |
Otros tipos de rompecabezas
El lenguaje de scripting de Bitcoin es rico y diverso y permite al usuario crear casi cualquier tipo de instrumento financiero que tenemos hoy, y muchos que no tenemos. Los rompecabezas no necesitan ajustarse a ningún estándar o plantilla en particular, sin embargo, se espera que la gran mayoría de las transacciones se construyan utilizando scripts de plantilla.
Aquí se pueden encontrar ejemplos de guiones más complejos
Se pueden combinar piezas de secuencia de comandos para realizar transacciones más grandes y complejas, y las secuencias de comandos se pueden construir dentro de bucles condicionales que permiten canjear una sola salida de transacción de múltiples maneras diferentes.
Antes de la actualización de Genesis, las secuencias de comandos complejas que quedaban fuera del esquema de prueba ‘isstandard’ debían comprimirse en un formato de transacción llamado ‘ Pagar al script Hash (P2SH) ‘. Este formato ahora está en desuso a favor de utilizar la secuencia de comandos completa y rica lenguaje dentro de las transacciones.
Ver también
- Opcodes utilizados en el script de Bitcoin
- Reglas de protocolo – mensajes «tx»
- Documentación de protocolo – Verificación de transacciones
- Malleabilidad de la transacción
Atribución
Este contenido se basa en el contenido de https://en.bitcoin.it/wiki/Transaction bajo Creative Commons Attribution 3.0 . Aunque puede haber sido ampliamente revisado y actualizado, reconocemos a los autores originales.
Texto original en inglés: https://wiki.bitcoinsv.io/index.php/Bitcoin_Transactions
La Metanet
El ecosistema de Metanet
Metanet es el término dado a un internet basado en valores construido en la cadena de bloques de Bitcoin SV. Metanet se puede utilizar para referirse a cualquiera de:
- El concepto de internet basado en el valor construido en Bitcoin SV .
- El protocolo Metanet .
Metanet fue anunciado por primera vez como un concepto por el Dr. Craig Wright en la conferencia CoinGeek Week en Londres el 30 de noviembre de 2018.
La motivación para Metanet es la creación de un internet en cadena que funciona como una red de valor eficiente, que ha mejorado las propiedades y capacidades en comparación con la infraestructura existente de Internet. La metanet como concepto ha sido ampliamente adoptada por el ecosistema Bitcoin SV y muchos protocolos y aplicaciones se han desarrollado para implementar la visión de un Internet altamente conectado basado en blockchain para la creación de contenido entre pares y la monetización.
Principios básicos
Las motivaciones para Metanet están vinculadas a problemas bien conocidos con Internet y comercio electrónico existentes, que incluyen lo siguiente:
- Dependencia de intermediarios para los pagos.
- Falta de una capa granular de micropagos.
- Aplicaciones de jardín amurallado y silos de datos.
- Preocupaciones sobre la privacidad de los datos y la propiedad de los usuarios.
- Prevalencia de spam, trolling y bots en plataformas sociales en línea.
Los dos primeros problemas, relacionados con los intermediarios de pago y la falta de micropagos, se abordan mediante el uso de la cadena de bloques de Bitcoin SV para pagos simples. El objetivo de Metanet es resolver los problemas restantes combinando pagos en línea con datos inmutables almacenados en la cadena de bloques pública de Bitcoin SV.
La combinación de pagos y datos, tanto usando la cadena de bloques de Bitcoin SV como una fuente universal de verdad, teóricamente permite un ecosistema de Internet más equitativo en el que:
- La información se le atribuye valor.
- La calidad se incentiva sobre la cantidad.
- El costo del comportamiento deshonesto (por ejemplo, trolling) aumenta.
- Los usuarios poseen sus datos.
El protocolo Metanet
El protocolo Metanet es un protocolo para estructurar datos dentro de la arquitectura de Internet en cadena de Metanet. El protocolo Metanet utiliza un modelo de datos gráficos para crear estructuras de datos en cadena para aplicaciones, sitios web y casos de uso de Metanet. El protocolo permite a los usuarios almacenar, distribuir y monetizar sus datos utilizando su marco de permisos nativo.
El protocolo Metanet es un protocolo de estructura de datos basado en gráficos. El protocolo utiliza el modelo de datos de gráfico acíclico dirigido (DAG) nativo de la cadena de bloques subyacente de Bitcoin SV para crear estructuras DAG superpuestas que existen de forma nativa en la cadena.
Tarifas por transacción – Fees
Las tarifas de transacción son tarifas que los usuarios de Bitcoin pueden incluir en cualquier transacción de Bitcoin . Los honorarios pueden ser cobrados por el minero que incluye la transacción en un Bloque .
Las tarifas de transacción son un cargo por servicio pagado a los mineros que registran el libro mayor de Bitcoin. Los servicios proporcionados por los mineros son la validación de transacciones, el almacenamiento del libro mayor y la construcción y seguridad de la red Bitcoin.
Visión general
Cada transacción de Bitcoin transfiere uno o más satoshis a uno o más destinatarios. La diferencia entre la cantidad que se gasta de las salidas anteriores y la cantidad que se envía a las nuevas salidas es la tarifa de transacción (que debe ser cero o más).
El diseño de Bitcoin hace que sea fácil y eficiente para la parte que envía especificar la cantidad que debe pagar, sin embargo, en teoría, es posible que un comerciante pague las tarifas de minería en nombre de sus clientes como un incentivo para usar su servicio. Se han propuesto servicios que lo hacen posible.
Cuando un minero crea una plantilla de bloque , tiene derecho a especificar dónde deben enviarse las tarifas pagadas por las transacciones en esa propuesta de bloque. Si la propuesta resulta en un bloque válido que se convierte en parte de la cadena de bloques , la recompensa de bloque completo, incluidas las tarifas de transacción y el subsidio de bloque , se enviarán al destinatario especificado. Los mineros se ven obligados a esperar 100 bloques antes de que puedan usar las monedas recibidas en una transacción de Coinbase .
Pérdida de honorarios
Si un bloque válido otorga a su buscador menos de las tarifas disponibles más el subsidio de Bloque , los Satoshis que no se cobran se destruyen permanentemente. Esto ha sucedido en más de 1,000 ocasiones en la historia de Bitcoin reduciendo el suministro de tokens en más de 50 Bitcoins.
Un ejemplo de esto se puede ver en el bloque 164246 donde el minero perdió 1.76 Bitcoins al no reclamar las tarifas.
El mercado de tarifas de Bitcoin
Por lo general, se necesita una tarifa mínima predeterminada para que una transacción se propague a través de la red y se extraiga en un bloque, sin embargo, ha surgido un mercado que ofrece transacciones con descuento para generadores a granel. El próximo paquete de API de comerciante brindará a los mineros un medio para interactuar con los usuarios habituales y ofrecer sus propios precios únicos por nodo. Las billeteras de los usuarios podrán hacer uso de este servicio para presentar a los usuarios tarifas que presenten un ‘tiempo estimado de confirmación’ que les da flexibilidad para elegir tarifas más bajas para transacciones más grandes o menos importantes, sin tener que preocuparse de que esas transacciones no se propaguen.
Este artículo contiene una perspectiva más profunda sobre este aspecto de las tarifas de Bitcoin.
Cadena de bloques – Blockchain
La cadena de bloques de Bitcoin es la base de datos de transacciones construida por los nodos que participan en el proceso de minería en la red de Bitcoin. La cadena de bloques contiene todas las transacciones ejecutadas en la red. Con esta información, uno puede calcular y rastrear el registro de propiedad de todos los bitcoins administrados en el libro mayor en cualquier momento de la historia.
Cada bloque contiene una referencia al bloque sobre el que se basa. Esto tiene el efecto de crear una cadena de bloques desde el bloque de génesis hasta el bloque actual. Los bloques se vuelven poco prácticos desde el punto de vista informático para modificarlos, sobre los que se han construido durante un período de tiempo debido a la cantidad de trabajo que necesitaría ser regenerado.
Los mineros extienden la cadena de bloques construyendo sobre lo que consideran el bloque válido más reciente en la cadena de prueba de trabajo más larga. Los mineros pueden disputar bloques eligiendo no construir sobre ellos. Un bloque que no se construye se llama Bloque huérfano .
Para cualquier bloque en la cadena, solo hay una ruta al bloque de génesis. Viniendo del bloque de génesis, sin embargo, puede haber tenedores. Se pueden crear horquillas de vez en cuando cuando se crean dos bloques válidos con solo unos segundos de diferencia. Cuando esto sucede, los nodos intentarán construir un nuevo bloque, cualquiera de los bloques que recibieron primero. Cuando se encuentra un nuevo bloque, el bloque sobre el que se construyó se convierte en parte de la cadena más larga, dejando huérfanos a su competidor.
Las bifurcaciones también pueden ocurrir cuando los nodos no están de acuerdo con las reglas de la red. Se han producido dos tenedores notables en Bitcoin, el primero en 2017 cuando Bitcoin se bifurcó en la red BCH cuando los nodos BTC eligieron adoptar a Segregated Witness en las reglas de la red BTC, y nuevamente en noviembre de 2018 cuando los nodos BCH eligieron implementar nuevos códigos de operación y reglas de consenso que no estaban alineados con el protocolo original.
Los bloques en cadenas más cortas (o cadenas no válidas) no se utilizan para nada. Si un nodo detecta la creación de una cadena más larga que la que está trabajando, todas las transacciones válidas de la plantilla de bloque dentro de la cadena más corta se vuelven a agregar al grupo de transacciones en cola y se incluirán en otro bloque. La recompensa por los bloques en la cadena más corta no estará presente en la cadena más larga, por lo que prácticamente se perderán, por lo que existe un tiempo de maduración de 100 bloques forzado por la red para las generaciones.
Debido a que un bloque solo puede hacer referencia a un bloque anterior, es imposible que dos cadenas bifurcadas se fusionen.
Los bloques se transmiten a todos los nodos en la red utilizando el protocolo de red Bitcoin.
Cadena de tiempo – Timechain
La palabra cadena de tiempo se puede usar para referirse a la naturaleza de la cadena de bloques de Bitcoin como una cadena de eventos con marca de tiempo en la historia. Las transacciones en sí mismas no tienen un componente de marca de tiempo y, como tales, se atribuyen a la marca de tiempo del Bloque en el que terminan siendo incluidas. Es posible incluir información de marca de tiempo más precisa en una transacción de Bitcoin como parte de un protocolo de capa de Aplicación, sin embargo, esto debe ser hecho con la intención explícita de un sistema secundario existente que puede interpretar el tiempo en el formato utilizado en la carga útil de la transacción.
El documento técnico de Bitcoin describe una moneda electrónica como una cadena de firmas digitales. Estas firmas digitales confieren control práctico y, en la mayoría de los casos, propiedad sobre las monedas contenidas en cualquier secuencia de comandos, y se pueden usar como un registro de control de custodia para rastrear las transferencias de control a través de la historia del libro mayor.
Una firma digital no es simplemente un mensaje firmado con un par de claves dado, sino que es un enlace a una identidad. La legislación de la Unión Europea sobre Firmas Digitales establece que las firmas corresponden a «datos en forma electrónica que se adjuntan o asocian lógicamente con otros datos electrónicos y que sirven como método de autenticación». Para obtener más información, consulte este artículo del Dr. Craig Wright.
El script de Bitcoin permite a los usuarios bloquear / desbloquear su bitcoin de diferentes maneras.
Algoritmo de firma digital de curva elíptica (ECDSA)
El algoritmo de firma digital de curva elíptica es el tipo de firma más utilizado en Bitcoin. Utiliza los pares de claves de criptografía de curva elíptica a los que se hace referencia en las direcciones de Bitcoin para generar firmas seguras a partir de un hash de mensaje dado.
Con Bitcoin Script, es posible crear sistemas novedosos que utilizan firmas digitales de curva elíptica, incluidos R-Puzzles , scripts de múltiples firmas y firmas de umbral .
Umbral de firmas
También ha habido implementaciones prácticas de firmas de umbral en billeteras y bibliotecas de Bitcoin que extienden las firmas de la curva elíptica para permitir que múltiples partes participen en la creación de una firma creada a partir de una clave privada que nunca se calculó o existió explícitamente. Cuando se utiliza en una transacción, una firma de umbral no es diferente de una firma ECDSA normal y puede validarse utilizando OP_CHECKSIG y códigos de verificación de firma relacionados.
Rabin Firmas
Los investigadores de nChain han comenzado a desarrollar métodos para validar las firmas de Rabin en el script de Bitcoin. En teoría, estas firmas podrían permitir que los datos recopilados fuera del libro mayor de Bitcoin SV se evalúen y firmen, lo que permite la funcionalidad de Oracle en las transacciones de Bitcoin. Actualmente no existe una implementación práctica de una firma Rabin en Bitcoin Script.
INFORMACIÓN OFICIAL:
Craig Wright
ANÉCDOTAS DE PERSONAS QUE ESTUVIERON EN CONTACTO CON SATOSHI NAKAMOTO:
- Si hubiera sabido lo que estábamos empezando. (Ray Dillinger)
- Interview with Ray Dillinger
- Bitcoin and me (Hal Finney)
- Confesiones de Laszlo Hanyecz.
CRAIG ES SATOSHI:
- Creo que Craig S. Wright es la persona que inventó Bitcoin. (Gavin Andresen)
- SATOSHI ESTÁ MUERTO – LARGA VIDA A SATOSHI. (Ian Grigg)
- Cómo conocí a Satoshi. (Jon Matonis)
- ¿Es él Satoshi o es mi hermano? (Danni DeMorgan)
- La saga Satoshi continúa: Joseph Vaughn Perling
QUIÉN ES…?:
ARTÍCULOS DE CRAIG:
- BTC y la censura. (Craig Wright)
- Evidencia y ley. (Craig Wright)
- La historia de Bitcoin, continuación… (Craig Wright) (Segunda parte)
- Cuidado con lo que deseas… (Craig Wright)
ENLACES:
- Compilation of +440 Craig Wright´s Post, Papers & Books
- Craig Wright´s Post Compilation in Alphabetical order.
- Only Craig Wright
- TELEGRAMS CHANNELS: Names in alphabetical order
- Ramon Quesada – Links
Dejar un comentario
¿Quieres unirte a la conversación?Siéntete libre de contribuir!