Tomar dinero a través de la web usando Bitcoin: la forma en que fue diseñado

En 2009, Bitcoin utilizó una función que permitía el intercambio de información de IP a IP. La billetera de 2009 no fue más que una prueba de concepto, y muchos de los mejores aspectos de Bitcoin se han deshabilitado ya que aquellos que desarrollaron el software no lo entendieron.

La semana pasada, discutí cómo se podría usar una clave en una tarjeta inteligente, mientras se mantenía la privacidad utilizando el modelo de identidad de Bitcoin del firewall. Para la próxima semana, mostraré tanto un método que permite que un servidor web acepte pagos de forma segura en bitcoin ingenuamente como un método que permite intercambiar fiat y otros tokens manteniendo un nivel absoluto de privacidad.

Certificados PKI: el proceso

Tal, no la minería, es el aspecto peer-to-peer de Bitcoin, y es una de las primeras cosas que los desarrolladores de Core eliminaron.

En 2009, todavía se requería mucho trabajo.

En 2009, el sistema aún no estaba completo. Debían probarse varios métodos posibles, y el método utilizado en el cliente 2009 dejó mucho que desear. Por otra parte, era simplemente una prueba de concepto.

Para solucionar estos problemas, debemos comenzar por comprender que los nodos y las billeteras están separados. Los nodos son mineros, y las billeteras son lo que usa el usuario para permitir una transacción P2P. En la publicación de hoy, explicaré cómo un certificado web basado en ECDSA, un certificado de servidor SSL / TLS que le permite navegar por Internet de manera segura, puede ser la base de un sistema de pago comercial, un sistema que permanece seguro y privado, y Sin embargo, también se construye de modo que solo envíe un pago a una dirección en particular una vez.

En otras palabras, nunca reutiliza las llaves.

Hay dos formas de enviar dinero. Si el destinatario está en línea, usted
puede ingresar su dirección IP y se conectará, obtendrá un nuevo público
clave y enviar la transacción con comentarios. Si el destinatario es
no en línea, es posible enviar a su dirección de Bitcoin, que
es un hash de su clave pública que te dan. Ellos recibirán
la transacción la próxima vez que se conectan y obtienen el bloque es
en. Este método tiene la desventaja de que no hay información de comentarios
se envía y se puede perder un poco de privacidad si se utiliza la dirección
varias veces, pero es una alternativa útil si ambos usuarios no pueden
estar en línea al mismo tiempo o el destinatario no puede recibir mensajes entrantes
conexiones

El certificado es algo que se puede usar tanto en S / MIME como en HTTPS.

Si tomamos la clave asociada con un certificado registrado por CA, podemos crear un registro público de todas las monedas que se envían al comerciante y al mismo tiempo conservar la privacidad.

Comenzaremos con Alice, un consumidor, y Bob, un comerciante web con un certificado web basado en ECDSA para su sitio HTTPS://www.bob.com.

Alice tiene una clave maestra de Bitcoin. La clave maestra no se usa para enviar o recibir bitcoins, y puede ser un método para crear una clave de identidad (e incluso podría estar en una tarjeta inteligente). Tal es la clave que llamaremos P (Alice).

El sitio web de Bob (dejaré que otros piensen en lo simple que es extender el mecanismo al correo electrónico con S-MIME) tiene una clave maestra P (Bob).

Alice tiene un conjunto de monedas (es decir, referencias UTXO) que pueden no estar relacionadas con P (Alice) y que no tienen ninguna relación con su clave principal. Lo llamaremos P (A-1-i); aquí, (i) se refiere al número de la moneda utilizada.

Alice puede crear un secreto común (s1) utilizando el proceso documentado en el siguiente documento:

DETERMINAR UN SECRETO COMÚN PARA EL INTERCAMBIO SEGURO DE INFORMACIÓN Y CLAVES CRIPTOGRÁFICAS DETERMINISTAS Y JERÁRQUICAS

Para utilizar dicho mecanismo (uno de muchos ejemplos), Alice va a la tienda web de Bob y ahora busca pagar. Alice puede calcular un secreto compartido con Bob. Para estar más segura, Alice puede usar la ID de sesión web que comparte con Bob, el número de factura o cualquier otra cosa. Se puede usar en un valor basado en HMAC para agregar más seguridad y privacidad, pero por hoy, usaré un hash simple para que el proceso sea más fácil de entender.

Alice y Bob pueden calcular un valor S, que está vinculado a las claves que Alice y Bob usan en la web. Alice puede tener una clave de identidad y autenticación que no se vincula públicamente a sus compras, pero asegura todas sus comunicaciones con Bob.

Alice envía un mensaje a Bob que está encriptado en una transacción de Bitcoin. La transacción se puede completar mediante un proceso fuera de línea o en línea. Si Bob está en línea, puede almacenar el valor de un nonce de Alice como parte de la compra web.

Si Bob no está en línea y tiene un sitio bastante simple, puede usar blockchain para registrar información sobre el pago y verificarlo.

Alice envía a Bob una transacción a P (Bob). Bob no usa esa dirección, por lo que el pago es pequeño; sin el límite de polvo, un simple satoshi será suficiente. Alice envía el mensaje para el pago a la dirección P (Bob), y Bob no lo usa para fondos. Podemos decir que Bob SOLO gastará desde la dirección (la asociada con la clave pública P (Bob)) cuando el certificado esté marcado como caducado. El proceso actúa como una forma de "lista de revocación" distribuida donde Bob puede controlar su propia clave. Más aún, si la clave y el certificado de Bob son atacados alguna vez y las transacciones de polvo aquí son gastadas por un atacante, actúa como una alerta automática. Bob podría mantener una pequeña cantidad de fondos en la cuenta como un medio para permitir que los piratas informáticos piensen que es una dirección válida para su uso (por ejemplo, $ 2,000) que solo se perdería si se piratea la cuenta, pero eso también alerta a todos los clientes de Bob al ataque

Bob puede hacer que la cuenta sea más privada utilizando una subclave; consulte la Fig. 9 en la patente:

Fig. 9 de la patente 42

Bob incluso podría tener un proceso en el que el número de factura esté asociado con una subclave.

Alice ahora envía a la dirección asociada con P (Bob), y en el script o como un valor OP_RETURN incluye un valor que ha sido encriptado (como con el uso de un algoritmo de encriptación AES). Usando el método mencionado anteriormente, Bob puede calcular (S). Los datos en el mensaje enviado a Bob con un solo satoshi (más las tarifas de minería) contienen todo lo que Bob necesita saber para saber dónde envió Alice el pago. Bob usa la clave simétrica (S) para descifrar los datos en el mensaje:

  • Cifrar (S) [M]

lo que le da a Bob el mensaje de Alice, M.

  • Descifrar (S) [M]

Bob ahora puede calcular una dirección de clave a partir de la clave derivada:

  • P (Bob-Paid) = P (Bob) + HMAC (M ~ S) xG
  • La clave del mensaje es P (Mensaje compartido) = HMAC (M ~ S) xG

SOLO Bob y Alice conocerán el nuevo secreto HMAC (M ~ S).

Alice puede demostrar que ha enviado un pago a Bob. Bob puede encontrar el dinero de Alice y verificar la transacción.

Al mismo tiempo, ninguna parte externa puede determinar la dirección desde la cual Alice envió su pago - P (A-1-i) a Bob en P (Bob-Paid).

Como Bob tiene un registro en la cadena de bloques en P (Bob), y tiene una pista de auditoría completa de todas las direcciones de pago que ha recibido. El registro se puede vincular a facturas, pedidos de compra y más, lo que le permite a Bob construir un seguimiento de auditoría completo de todos los intercambios y uno que no se puede eliminar, alterar o manipular. El método cumple con todos los problemas de contabilidad legislativa requeridos para Bob, y puede tener una dirección dividida donde el IVA y otros impuestos sobre las ventas se envían al gobierno a medida que se le paga. En otras palabras, Bob no necesita experimentar auditorías costosas, y la autoridad tributaria puede pagarse inmediatamente sin demora.

Tokens y Bitcoin

Al usar un protocolo como Tokenized o uno de los varios para los que nChain ha presentado patentes, Alice y Bob también pueden intercambiar fiat tokenizado. Significa que Alice podría pagarle a Bob usando un token GBP emitido por un banco en el Reino Unido. Tal token se transmite utilizando el proceso mencionado anteriormente, lo que permite a Alice y Bob realizar transacciones de forma segura utilizando efectivo digital en la moneda local de su elección, mientras sigue utilizando Bitcoin como "plomería" para el intercambio.

Enlace de metanet

Como tal, incluso si Bob está ejecutando un sitio web fuera de línea, es decir, un sistema simple sin una base de datos de fondo, los registros recibidos con la tecla P (Bob) ahora pueden actuar como una forma de almacenamiento de datos inmutable.

El mensaje que Alice cifra a Bob puede ser el pedido completo.

Se puede completar utilizando los tipos de mensajes EDI existentes. A diferencia de EDI, el método es seguro y privado.

Mejor, el registro es inmutable. No hay lugar para fraudes contables. Puede revertir las transacciones, pero hacerlo requiere una devolución de fondos a la fuente de origen.

Alice y Bob pueden grabar todo el proceso comercial.

Bob puede mantener una serie de direcciones jerárquicas que registran todas las etapas del pedido, desde la facturación y el pago hasta el envío y la entrega. Si Bob ahora tiene una clave maestra secundaria para cada cliente (consulte la patente anterior y la Fig. 9), también puede construir una subclave separada, que él mismo, el cliente y la autoridad tributaria conocen para fines de auditoría, pero no otros, lo que le permite mantener un nivel absoluto de privacidad, donde otros clientes y proveedores ni siquiera saben cuántas transacciones está haciendo. Además, puede construir pagos de una manera que le permita aislar a los empleados internos y hacer que conozcan solo la información relacionada con sus propios departamentos.

Si bien no se toca la tecla vinculada a CA, las cuentas se pueden enviar a la dirección anterior. Una clave sub-CA podría vincularse con el año contable y acumular también cada período impositivo. Cierra el certificado, recoge los pagos realizados como polvo y, al mismo tiempo, cierra los libros listos para el nuevo año contable.

Mensaje EDI

EDI es un esquema de codificación existente para el comercio.

Podemos ver los formatos de mensaje ANSI y EDIFACT en la imagen a continuación:

ANSI vs EDIFACT

En nuestro sistema, utilizamos la clave de cifrado para los datos en el mensaje (no el pago) como el "mensaje grupal". No hay necesidad de un mensaje de intercambio. Tal sería un intermediario, y en Bitcoin, hemos eliminado la necesidad de él.

EDI estándar

El nuevo modelo para el comercio es uno en el que todos los registros son inmutables, no se pueden perder y permiten que Alice y Bob negocien en privado.

Intercambio de datos de Bitcoin

Y, las herramientas para asignar EDI a una transacción de Bitcoin simplemente se verían como herramientas EDI como lo son hoy.

Incluso incrustado en una transacción de Bitcoin, el formato XML EDI cifrado simplemente se puede extraer y mostrar o imprimir como cualquier otra factura o pedido:

Factura mostrada

En el mundo EDI existente, a los clientes se les cobra utilizando modelos que operan dentro de las bandas de precios basadas en volúmenes anticipados de Kilo-Personajes (KC) o documentos. También hay cargos ocultos, como longitudes de registro mínimas con muchos proveedores que especifican una longitud de registro de 128 a 512 caracteres. El resultado es que si envía 12 documentos de 12 caracteres, se le cobrarán hasta 5.120 caracteres, aunque solo envíe 144 caracteres.

Para los comerciantes con un gran volumen de pequeñas transacciones, pueden agregar una cantidad sustancial a su cargo mensual.

Tal cosa no es un problema con Bitcoin.

Aunque el tamaño máximo de mensaje permitido para los mensajes EDI NACCS es de 500,000 bytes, la realidad es que los mensajes EDI y otros mensajes relacionados son generalmente del orden de 150 bytes. El envío de un sistema de facturación y contabilidad inmutable, privado y seguro para fracciones de un centavo por factura: compare hacerlo con 2 a 3 dólares para algunas soluciones EDI e incluso $ 0.20 para una transacción simple de Visa, y ... es hora de comenzar a repensar cómo haces negocios

En tal modelo, ninguna dirección de Bitcoin debe usarse más de una vez, y los pagos y las facturas están vinculados de forma privada, lo que incluso puede ser seudónimo, ya que la identificación no necesita estar en un certificado de usuario.