Back in 2009, Bitcoin used a feature that allowed for the IP-to-IP exchange of information. The 2009 wallet was not more than a proof of concept, and many of the best aspects of Bitcoin have been disabled as those developing the software failed to understand it.
Last week, I discussed how a key could be used in a smart card, whilst privacy was maintained using the firewall’d identity model of Bitcoin. For the coming week, I will show both a method allowing a web server to securely accept payments in bitcoin naively and a method allowing fiat and other tokens to be exchanged whilst maintaining an absolute level of privacy.
Such — not mining — is the peer-to-peer aspect of Bitcoin, and it is one of the first things that the Core developers removed.
In 2009, the system was not yet complete. Several possible methods needed to be tested, and the method used in the 2009 client left a lot to be desired. Then again, it was merely a proof of concept.
To fix such issues, we need to start by understanding that nodes and wallets are separate. Nodes are miners, and wallets are what is used by the user to allow for a P2P transaction. In today’s post, I will explain how an ECDSA-based web certificate, an SSL/TLS-server certificate that allows you to surf the internet securely, can be the basis of a merchant payment system — a system that remains secure and private, and yet is also constructed such that it only sends a payment to a particular address once.
In other words, it never reuses keys.
There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They'll receive the transaction the next time they connect and get the block it's in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections.
The certificate is something that can be used in both S/MIME and HTTPS.
If we take the key that is associated with a CA-registered certificate, we can create a public record of all coins that are sent to the merchant and at the same time retain privacy.
We will start with Alice, a consumer, and Bob, a web merchant with an ECDSA-based web certificate for his site HTTPS://www.bob.com.
Alice has a Bitcoin master key. The master key is not used to send or receive bitcoin, and can be a method to create an identity key (and could even be on a smart card). Such is the key which we will call P(Alice).
Bob’s website (I will leave it to others to think on how simple it is to extend the mechanism into email with S-MIME) has a master key P(Bob).
Alice has a set of coins (that is, UTXO references) that can be completely unrelated to P(Alice) and which have no relation to her main key at all. We will call it P(A-1-i); here, (i) refers the number of the coin used.
Alice can create a common secret (s1) using the process documented in the following document:
To use such a mechanism (one of many examples), Alice goes to Bob’s web store, and now seeks to pay. Alice can calculate a shared secret with Bob. To be more secure, Alice can use the web-session ID that she shares with Bob, the invoice number, or anything else. It can be used in an HMAC-based value to add further security and privacy, but for today, I will use a simple hash to make the process simpler to understand.
Alice and Bob can both compute a value S, which is linked to keys that Alice and Bob use on the web. Alice can have an identity and authentication key that does not link publicly to her purchases, but secures all of her communications with Bob.
Alice sends a message to Bob that is encrypted in a Bitcoin transaction. The transaction can be completed using either an offline or online process. If Bob is online, he can store the value of a nonce from Alice as a part of the web checkout.
If Bob is not online and has a rather simple site, he can use the blockchain to record information about the payment and check it.
Alice sends Bob a transaction to P(Bob). Bob does not use such an address, so the payment is small; without the dust-limit, a mere single satoshi will suffice. Alice sends the message for the payment to the P(Bob) address, and Bob does not use it for funds. We can say, Bob ONLY will spend from the address (the one associated with the P(Bob) public key) when the certificate is marked as expired. The process acts as a form of distributed “revocation list” where Bob can control his own key. More, if Bob’s key and certificate are ever attacked and the dust transactions here are spent by an attacker, it acts as an automated alert. Bob could keep a small amount of funds in the account as a means to allow hackers to think it is a valid address for use (e.g. $2,000) that would only be lost, if the account was hacked, but that also alerts all of Bob’s customers to the attack.
Bob can make the account more private using a subkey — see Fig. 9 in the patent:
Bob could even have a process where the invoice number is associated with a subkey.
Alice now sends to the address associated with P(Bob) — and in the script or as an OP_RETURN value includes a value that has been encrypted (such as with the use of an AES encryption algorithm). Using the method noted above, Bob can calculate (S). The data in the message to Bob sent with a single satoshi (plus mining fees) contains all Bob needs to know to find where Alice has sent the payment. Bob uses the symmetric key (S) to decrypt the data in the message:
- Encrypt(S)[M]
which gives Bob the message from Alice, M.
- Decrypt(S)[M]
Bob can now compute a key address from the derived key:
- P(Bob-Paid) = P(Bob) + HMAC(M ~S)xG
- The message key is P(Shared Message) = HMAC(M ~S)xG
ONLY Bob and Alice will know the new secret HMAC(M ~S).
Alice can prove that she has sent a payment to Bob. Bob can find the money from Alice and verify the transaction.
At the same time, no outside party can determine the address that Alice sent her payment from — P(A-1-i) to Bob at P(Bob-Paid).
As Bob has a record on the blockchain at P(Bob), and has a complete audit trail of all the payment addresses he has received. The record can be linked to invoices, purchase orders, and more, allowing Bob to construct a complete audit trail of all exchanges and one that cannot be deleted, altered, or manipulated. The method fulfils all the required legislative accounting issues for Bob, and he can have a split address where VAT and other sales taxes are sent to the government as he is paid. In other words, Bob does not need to experience costly audits, and the tax authority can be paid immediately without delay.
Tokens and Bitcoin
Using a protocol such as Tokenized or one of the various ones that nChain has filed patents for, Alice and Bob can also exchange tokenised fiat. It means that Alice could pay Bob using a GBP token issued by a bank in the UK. Such a token is transmitted using the process listed above, allowing Alice and Bob to safely and securely transact using digital cash in their local currency of choice, whilst still using Bitcoin as the “plumbing” for the exchange.
Metanet linking
As such, even if Bob is running an offline website — that is, a simple system without a back-end database — the records received against the P(Bob) key can now act as a form of immutable data store.
The message that Alice encrypts to Bob can be the complete order.
It can be completed using existing EDI message types. Unlike EDI, the method is safe, secure, and private.
Better, the record is immutable. There is no place for accounting frauds. You can reverse transactions, but doing so requires a return of funds to the originating source.
Bob can hold a series of hierarchical addresses that record all stages of the order — from invoicing and payment to sending and delivery. If Bob now has a sub-master key for each client (see the patent above and Fig. 9), he can also construct a separate subkey, that is known to himself, the client, and the tax authority for audit purposes, but no others, allowing him to retain an absolute level of privacy, where other clients and suppliers do not even know how many transactions he is doing. More, he can construct payments in a manner that allows him to isolate internal employees and have them know only the information related to their own departments.
While the CA-linked key is not touched, the accounts can be sent to the old address. A sub-CA key could be linked to the accounting year and rolled each tax period, too. You close out the certificate, collect any payments made as dust, and at the same time, close the books ready for the new accounting year.
EDI is an existing encoding scheme for commerce.
We can see the ANSI and EDIFACT message formats in the image below:
In our system, we use the encryption key for the data in the message (not the payment) as the “group message.” There is no need for an interchange message. Such would be a middle man, and in Bitcoin, we have removed the need for him.
The new model for commerce is one where all records are immutable, cannot be lost, and allow Alice and Bob to trade privately.
And, tools to map EDI to a Bitcoin transaction would simply look like EDI tools as they are today.
Even embedded into a Bitcoin transaction, the encrypted EDI XML format could simply be extracted and displayed or printed as any other invoice or order:
In the existing EDI world, clients are charged using models that operate within price bands based on anticipated volumes of Kilo-Characters (KCs) or documents. There are also hidden charges such as minimum record lengths with many providers specifying a record length of 128 to 512 characters. The result is that if you send 12 documents of 12 characters, you would be charged for up to 5,120 characters, even though only sending 144 characters.
For merchants with a large volume of small transactions, they can add a substantial amount to your monthly charge.
Such a thing is not an issue with Bitcoin.
Though the maximum message size allowable for NACCS EDI messages is 500,000 bytes, the reality is that EDI and other related messages are generally in the order of 150 bytes. The sending of an immutable, private, secure invoicing and accounting system for fractions of a cent per invoice — compare doing so to 2 to 3 dollars for some EDI solutions and even $0.20 for a simple Visa transaction, and… it is time to start rethinking how you do business.
In such a model, no Bitcoin address need ever be used more than once, and the payments and invoices are linked privately — which can even be pseudonymous, as the ID need not be in a user cert.