The original medium.com/swlh/taking…
Back in 2009, Bitcoin allowed IP to IP information exchange. In 2009 the wallet was still in the prototype stage, and many of its best features were turned off as developers failed to understand Bitcoin.
Last week, I discussed how bitcoin could be used on smart cards, an ID model with a firewall that protects privacy. This week, I’ll show you how to use a Web server to securely accept Bitcoin payments, and how to ensure privacy while conducting fiat or other token transactions.

That’s the peer-to-peer part of Bitcoin, not mining, and that’s one of the things the Core developers removed.

In 2009, the system wasn’t finished. A few possible features need to be tested, and the 2009 client left a lot of suspense and was nothing more than a prototype.
To solve these problems, let’s be clear: nodes and wallets are separate. The node is the miner, and the wallet is used by the user, and has P2P transaction function. In this article, I’ll explain that ECDSA-based network certificates, SSL/TLS server certificates, which allow you to surf the Web securely, can be the foundation of a commercial payment system that guarantees security and privacy, based on a single address being paid only once.
In other words, don’t duplicate the key.
There are two ways to transfer money. When the receiver is online, he can enter his IP address, get a new public key, and send the transaction. If the recipient is not online, you can send it to his Bitcoin address, which is a hash of his public key, given to you in advance. The next time he connects and gets the block the exchange is in, he can receive it. The disadvantages are that no remarks are sent, and privacy is compromised due to address reuse. But it’s also a useful alternative if you can’t be online at the same time, or if the recipient doesn’t have an Internet connection.
Certificates are something that can be used in S/MIME and HTTPS.
If we use the key associated with the CA registration certificate, we cannot create a public record of merchant receipts while preserving privacy.
For example, Alice is a consumer and Bob is a web merchant whose website HTTS://www.bob.com is ECDSA certified.
Alice has Bob’s master key. Instead of sending and receiving bitcoin, the key can be used to create an identity key (which can be used on a smart card). Such a key is called P(Alice).
The master key of Bob’s web site is P(Bob). (S-MIME is an easy way to apply this mechanism to email, but I’ll leave you to think about it.)
Alice has some coins (UTXO index) that have nothing to do with P(Alice), that is, P(Alice) has nothing to do with her base key. We’ll call it P(A-1-i), and I stands for the coins we’ve used.
Alice can create a common password using the process described in the following document (s1) :
DETERMINING A COMMON SECRET FOR THE SECURE EXCHANGE OF INFORMATION AND HIERARCHICAL, DETERMINISTIC CRYPTOGRAPHIC KEYS
One use case for this mechanism is Alice making a payment at Bob’s online store. Both parties can calculate a common password. To be more secure, Alice can use their shared Web-session ID, invoice number, or anything else. You can use an HMac-based value for more security and privacy, but I’ll use a simple hash here for ease of understanding.
Both Alice and Bob can calculate the value of S, which is related to the key used by both parties on the Internet. Alice has a key for authentication, which is not publicly linked to her payment, but is able to secure communication with Bob.
Alice sends an encrypted message via a Bitcoin transaction. This transaction can be used either offline or online. If Bob is online, he can keep the NOnce from Alice as part of the network check.
If Bob is not online and his website is simple, he can use blockchain to record payment information and check it.
Alice sends a transaction to P(Bob). Bob is not going to use this address, so the payment is small; If there is no dust limitation, only a cong is ok. Alice just sends the information about the payment to P(Bob) address, Bob will not use the funds inside. Suffice it to say that Bob spends the money in this address (associated with the P(Bob) public key) only when the certificate is marked as expired. This process is similar to a distributed “revocation list,” where Bob controls his own keys. Also, if Bob’s keys and certificates are attacked and the dust transaction is cost by the hacker, this is an automatic alarm. Bob can put some money in the account to make the hacker think it is a legitimate address in use (say $2,000), and if the account is hacked, it warns Bob’s users.
Bob can use a subkey to make the account more private — see this picture in the patent:
Bob can even have a process that relates the invoice number to a subkey.
Alice sends a message to an address associated with P(Bob) — in the script, or in OP_RETURN with an encrypted value (using an encryption algorithm such as AES). Using the previous method, Bob can calculate S. The Icong (plus the processing fee) transaction sent to Bob contains all the information Bob needs to know where Alice initiated the payment from. Bob uses symmetric ciphers (S) to decrypt the data in the message:
- Encrypt(S)[M]
M is the information that Alice is going to give Bob.
- Decrypt(S)[M]
Bob can now derive a key address from the key:
-p (Bob-paid) = P(Bob) + HMAC(M ~S)xG
– The Message password is P(Shard Message) = HMAC(M ~S)xG
The new password HMAC(M ~S) is known only to Bob and Alice.
Alice can prove that she has already paid Bob. Bob can find the money Alice sent and verify the transaction.
Meanwhile, no third party can determine the address that Alice uses to pay — P(A-1-i) to Bob’s P(Bob-paid).
Bob has a record of P(Bob) on the blockchain, along with a complete account of all payment addresses it has received. These records can be linked to invoices, orders, etc., let Bob can construct a nobody can delete, add, or control, complete of all trading accounts, this method can meet the Bob is legally required of all audit problems, and he also can have a separate address, sent to the government for VAT and other tax. In other words, Bob can pay taxes immediately without going through an expensive audit.
Tokens and Bitcoin
Using either of the protocols such as Tokenized or nChain patents, Alice and Bob can trade Tokenized fiat coins. This means that Alice can pay Bob in the UK using a GBP token issued by a bank. This token can be sent using the process above, allowing Alice and Bob to safely send digital currency in their local currency while using Bitcoin as a “conduit” for the transaction.
Metanet link
Even if Bob is running an offline website — there is no back-end database — the records received by key P(Bob) can serve as an immutable data store.
Alice sends an encrypted message to Bob, which can be a complete order.
This can be done using existing EDI message types. And more secure, reliable and private than EDI.
Better yet, records are immutable. There is no room for audit fraud. You can undo the deal, but you need to send the money back to where it came from.
Bob can hold a series of tiered addresses that record every step of the order — from billing and payment to shipping and receiving. If Bob owns each customer’s sub-master key (see patent in Fig.9 above), he can also construct another subkey that only he, the customer, and the tax auditing agency will know about. This allows him to maintain complete privacy, and other customers and suppliers will not know exactly how many transactions he has made. In addition, he can structure payment processes to separate internal employees so that they only know information relevant to their own department.
Accounts can be sent to the old address as long as the CA-associated key has not been tampered with. A sub-CA key can be associated with the accounting year and invoked during each tax cycle. You can close this certificate, collect all dust payments, and at the same time, close your books and prepare your accounts for the New Year.
EDI is an existing commercial coding format.
Here is the format of ASNI and EDIFACT messages:
In our system, we use keys to encrypt the data in the message in the form of “group messages”. An “exchange message” is no longer required. In Bitcoin, we eliminate the need for a middleman.
The new business model makes all records immutable and unmissable, and allows Alice and Bob to conduct private transactions.
Moreover, EDI tools for transactions using Bitcoin are as simple as existing EDI tools.
Even embedded in bitcoin transactions, the encrypted EDI XML format can be easily parsed and displayed or printed on invoices or orders:
In the existing EDI world, customers pay based on the number of characters or documents. And many vendors set minimum lengths, ranging from 128 to 512 characters. The result is that if you send 12 documents with 12 characters, you will be charged up to 5120 bytes, even if only 144 characters are sent.
For merchants with a lot of small transactions, this can cause a lot of expense.
These are not problems in Bitcoin.
Although the maximum message size specified by NACCS EDI is 500,000 bytes, in reality this EDI and other related messages are usually 150 bytes.
The ability to send an immutable, private, reliable invoice for a fraction of a cent, with an accounting system; Compared to spending $2 or $3 on some EDI scheme, or $0.20 to send a simple Visa transaction… It’s time to rethink your business practices.
In this model, no Bitcoin address is used more than once, and payments and invoices are privately linked together — even pseudonyms can be used if the ID doesn’t need to be placed in the user’s certificate.