An implementation of the Lightning network could allow the exchange of bitcoins from person to person (P2P) using a contract escrow or guarantee of retention funds, as in the manner of the popular exchanges LocalBitcoins and LocalCryptos.
In the most recent installment of the Bitcoin Optech Newsletter, released yesterday, February 17, 2021, An approach is highlighted on the use of the so-called Point Time Locked Contracts ( PTLC ) to develop a transaction where the figure of escrow .
If this implementation is developed, a scheduled exchange may be made to be fulfilled on a date or in a specific condition under agreement between two people .
In this transaction, illustrate an example in the aforementioned newsletter , Alice and Bob would create and share compatible signatures among themselves, in order to approve and execute a transaction with the agreed amount and Between the two.
This process called coinswap (currency exchange) would be based on the authorized exchange of compatible signatures, technically called adapter signatures, which allow to authorize any expense or operation on the Bitcoin blockchain.
If Alice and Bob agree to make a payment With a value fixed, say, at 1 BTC, the generation of common signatures can help them to make this exchange without leaving the Bitcoin blockchain and its protocol. In our case Alice will pay Bob.
The author of the proposal identifies himself with the pseudonym ZmnSCPxj . The proposal was published last year, but its discussion was resumed earlier this month and reported in the newsletter .
Smart Bitcoin contracts aim to become increasingly complex and advanced
In the report sent this Tuesday by Bitcoin Optech, point out that the Lightning network needs to be updated and improved to allow the deployment of PTLCs. Being a multi-signature protocol, it is expected that these contracts will begin to be tested once Taproot is activated in Bitcoin, which could happen this year, as we reported in CriptoNoticias.
In response to the ZmnSCPxj proposal, developers Andrés G. Aragoneses and Pedro Moreno Sánchez, sent their concerns on February 8 .
In the message thread, Aragoneses recommended simplifying some commands in the code so as not to force all Lightning implementations to be updated to use this type of contracts.
That is, allow the escrow created to know the value of each transaction generated in the exchange in order to facilitate its implementation by exchange houses non-custodial , where it is very difficult to mediate disputes between the parties.
Simplify the flow of information between Alice, Bob and the escrow , would allow t Everyone has the same awareness of everything that is happening , reducing the chances of a dispute arising between the parties that could only be resolved with a escrow guarded by a third party, as in LocalBitcoins.
In this case, the figure of the escrow configured as a smart contract , makes the custody of the funds. Its developer responds that the escrow is able to intelligently deliberate if the payment conditions were met, by verifying the validity of Alice and Bob’s compatibility signatures, but also setting a time Limit to be met, like most Lightning Network contracts.
For example, if the buyer is not satisfied with the transaction, the escrow will deliberate Who has the reason. If the buyer (Bob) is right, the escrow will reveal his ESCROW key to the buyer so that, in combination with his private key compatible with the adaptation signature, withdraw the payment to his Please.
If the seller is right, the escrow would remove the private key from your ESCROW key and by default for the Lightning network, the transaction issued would expire and the funds would return to the seller’s hands.
The inversion of De Morgan’s logical theorem allows that, from combining the buyer’s and escrow’s keys, the seller can generate a Proof of Reimbursement , where it guarantees that the funds are available and ready to be sent to the buyer when required.
In parallel, the seller can offer a proof of payment, too, although creating a escrow with both guarantees requires blocking twice as many bitcoins. As Aragonese responded, this would force a buyer to have ner from the beginning an amount of bitcoins according to the amount you want to buy, which in your opinion would limit the shipment of new users, slowing the adoption of cryptocurrency and damaging the user experience (UX).
Clearly, the argumentative constructs of these contracts are unlimited, being able to develop various scalable functionalities over time. The possibilities of creating increasingly complex smart contracts are becoming wider each time. We are still in the early stages of Bitcoin as a technology that seeks to achieve important things in the long term.