Three technical requirements for connecting to a blockchain without using a token

Three technical requirements for connecting to a blockchain without using a token

Until there is a cloud blockchain or a centralized system for authentication, there is no justification for not connecting the blockchain to one another.

Dr. Julian Hosp, author of the article, says: "In my last post, I was talking about how connecting all blocks to each other is the final step in the process of accepting digital currencies." In this article, I want to explain the technical schema of how to implement this idea.

Since I saw many failures in having a cloud deck to connect all of them, I focused on a non-token solution. This has many advantages, including:

• There is no need for an additional token.
• Users can stay in their blockade.
• There is no need to trust a centralized third party.

However, this approach has many problems. Until there is a cloud blocker or a centralized system for authentication, there is no justification for not blocking blocks to one another. For example, if I want to transfer some of my inventory from Blockhcn Ethereum to Bitcoin, then I need someone at the same time to send Bitcoin to Etherium (a kind of bargain). For such large blocks, such people can always be found, but how will the situation be for sending from Ethereum to a smaller blockade or from a small blockade to a small blockade? Before I offer my solution to the problem, I want to emphasize that the deployment is a key economic factor for secure cryptographic networks with a variety of digital exchanges.

Block Basic Diagrams

Below we will look at the block diagram of elementary diagrams for the three different modes of connecting two blockades:

• 1 Multi-signature option (Multisig)
• 2 Computing function (hashing)
• 3 Time-lock function

Review each item separately and then combine them for a single image.

1 Multisig is an old and reliable concept, something like a multi-signature bank check. A multi-signature transaction allows absolute signature rules (without preconditions) to be merged. In the subject of the Secure, Outside, Multi Asset, and Comprehensive Transit Encryption Network (COMIT), each person uses multi-signature transactions of 2 to 2 in order for each party to sign, sign, and accept the transaction and is accepted by the network. . (An example is given below). This process means that multi-signature transactions between the two parties must be signed by either party so that its output is valid and accepted by the network.

In the following figure, a transaction is created, for example, a bitcoin as an input. Either way, both parties (Alice, Bob) have to sign the transaction in order for this transaction to be removed.

2 Hash functions are standard concepts in cryptography. These are one-way functions that convert a string of data (for example, a "s" here) to a single hash, for example, "h". Now h can be sent to others without worrying about the fact that no one is able to calculate the initial password string (s). In order to navigate through different blockings, the same cryptographic functions should be used in the conventional intelligent language that participate in each blocking routing.

In the figure below, an individual puts a bitcoin in a contract, but Alice can only take it if he has a code (which naturally comes from Bob).

3 Time-lock is a primitive requirement for a transitional asset, the same amount of transaction, to be locked up to the next date (because the same transaction can not be copied and re-sent - avoid double spending). There are two different types of time-lock mechanisms in the blocking mechanisms: relative and definitive. In a definite kind, an outbound transaction is locked up to a fixed time in the future, while in the relative type instead of a specific time, the output transaction is locked to an occurrence or a time point. In other words, it is defined in a relative type rather than an emphasis on a specific time point on an interval. Time-lock is one of the requirements for credit payment channels, and their relative type is proposed to allow open pay channels.

In the example below, one person will put an incoming transaction at a rate of one bitcoin, but Alice will have to wait for the preset time to receive it.

Composition of the above scenarios
If we want to combine these three block diagrams, we will get a term called "Hashed Time-Lock Contracts" (HTLC), which will update the status of the individuals (individuals) on a multi-signature basis. The HTLC combines the time locking concept with the Hash-lock for cancellation. If the receiver can provide the "s" password for the hash-lock operation before the time-lock expiration, it can receive the sent amount. Otherwise, the sender can safely reimburse the amount. That is, if one party wants to update the HTLC status, it needs to be verified (signed) by the other party.

In the following example, Alice will provide bitcoin during a contract with Bob. Bob can get that bitcoin by catching Alice's hash at a given time, or Alice will automatically redeem this amount after a certain time frame.

Two HTLCs can be combined and lead to something called atomic transactions. For this purpose, the recipient first generates the password and then calculates it (h). Subsequently, the recipient of the hash (h) shares with the sender where he initially created the conditional transaction (for example, the output has been locked (hashed)). This output can be exploited only by knowing the password. In general terms, it means that if Bob wants to send a Bitcoin to Alice and get back to Etrème, they have to open two payment channels (one for bitcoin and one for etherium) and put them in pairs with a hash h They do. That means Bob is still sending Alice bitcoin for Bob Etherium. In these circumstances, each one who opts out, the initial value is virtually returned.

Complete path
Now we can send certain values ​​of transactions to others, in which each node in the chain can be sure of the same hash for the transaction. Transaction that is conditional or has a password. The hash is initially shared with the sender, which will then send him a conditional payment to the first Node that needs to know the password, so that he can reimburse it. Then, each of the 90s in this path can simultaneously refer the transaction to another with the addition of the same condition for redeeming the transaction.

Using the HTLC mechanism, we can ensure that all transactions are paid in this or that way, or that all payment channels can not be repaid (guaranteeing a full transaction or refunding the amount to its original holder). There is no requirement for reassurance for middle nodes. At the end, you have a sequence of transactions that are dependent on completing (paying) for the same code.

When the receiver receives the last transaction and uses the same token (s) for settling (receiving amount), they will see all the nodes of the password tracked and then can redeem their incoming transactions.

After the password has been shared along the way, each paid channel will return the settlement of the transaction to the previous channel. This will be done by updating the status of the paid channel to the last inventory, and then by invalidating the HTLC transactions by retrieving the k-cancellation key associated with the contract-side payment channel, which will ultimately lead to the completion of the transaction.

The time-lock mechanism is used to perform the extraction mechanism in the event of interruption of the route. Time-locks should be stacked from recipient to sender in order to prevent tricking someone from manipulating the desired time (reducing time) so that someone can not track the sequence of transactions Move

Conclusion
These transactions can be expanded within the same blockade, but if there are people who can exchange transactions in other blocks, they can also be redirected to both blockages. This is the same concept of blocking and blocking routing. If we go back to where we were talking about connecting two small blocks, we now see that there is no need for a direct transfer of transaction to the two.

With the accumulation of pay-as-you-go channels, money (the digital currency amount) can go from a weak chain (low liquidity) to a strong chain (high liquidity) and then eventually shifted to the weak chain.

This concept connects paid channels to networks with the following features:
Secure Cryptography (Based on Cryptographic Standards)
Out of chain (like Lightning or Raiden networks)
Multiple Assets (Multi-Chain)
Annie (There is no need for a transaction to be settled after the release until the parties update in BlockChin)

A transaction network like COMIT

.good luck.

BRO 🆔 @triplej
Me 🆔 @haji