Projects

Python/Django/React Application.
WebSocket Implementation, via React on the client side and Channels WebSocket Consumer on the server side.
The purpose of this simulation is to demonstrate the WebSocket functionality. WebSocket Consumer is currently synchronous, but asynchronous capability can be implemented.

The Context is the client requesting an app to open a Lighting Channel with another LN Node and the simulation of the response.

Page loads and automatically establishes a WebSocket.

Server responds and app waits for Button to be clicked to start the Open Channel process.

Button activation sends client request to app to simulate directing an LN Node to open a channel with another LN node. The Open Channel request will receive a streaming response. That streaming response is simulated via time delays on the server side. The simulated response is forwarded to the Client upon receipt via the WebSocket and React updates the status.

WebSocket Implementation

WebSocket Implementation. React for client side. Channels WebSocket Consumer on the server side.

Read More

Python program to read, encrypt and sign a contract using RSA

This application walks through the contractual process of Titan (my cat) selling Charlie (my dog) 1 dog bowl for 1 BTC.

1. Loads the Contract--a text file right now.

2. Charlie (the Buyer) and Titan (the Seller) each generate RSA private public key pairs for separate encryption and signature keys.

3. Charlie sends encryption public key to Titan.Titan receives the key, saves and loads it.

4. App verifies that loaded key is the same as Charlie's public key.

5. Titan encrypts the contract using Charlie's public key, sends it to Charlie along with his public encryption key.

6. Charlie receives from Titan. Uses his private encryption key to decrypt the contract.

7. App verifies it is the same as the original contract.

8. Charlie hashes the contract (SHA256) and uses his private signature key to sign the contract. The he uses Titan's encryption public key to encrypt the contract.

9. Charlie sends the encrypted contract, signature, and his signature public key to Titan.

10. Titan decrypts the contract and verifies it is the same as the original.

11. Titan verifies Charlie's signature using Charlie's signature public key.

Binding Contract. Titan can now ship the goods. But how will he get paid? Maybe see the LNContract App for that!

Contract Sign

Python App to read, encrypt and sign a contract using RSA.

Read More

LNContract is a Python/Django app with a bit of React on the front-end to enable WebSocket functionality. It uses Polar for the Bitcoin/LN nodes. Currently, it has LND node functionality, but I will add Core-Lightning nodes soon.

The app models a contract in terms of the Party, Counterparty, Performance Obligations and Monetary Obligations. A user Party can view all contracts it manages or a specific one. For a specific contract, a Party can track Performance Obligations—the phases in a contract such as material procurement, assembly and testing. The app allows a Party to connect to its LN Node, direct its node to connect to the Counterparty’s node, and establish a channel. I am currently working on the payment functionality, which will enable a Party to pay its Monetary Obligation via the appropriate LN channel.

For the next phase, I will build out a minimal viable product. At the least, this will entail publicly serving the skeletal implementation using actual Bitcoin/LN Nodes (both LND and Core-Lightning) under testnet.

Subsequent development will include:

1. Incorporate the actual contract into the application.

i. Track different versions during contract negotiations. Provide a negotiations management functionality.
ii. Cryptographically sign the contract. (I developed a script to provide this, but haven’t yet included it in the skeletal implementation. For production, this would need to be more closely looked at.)
iii. Automatically extract the agreed to terms to populate the application models for use. (This automation would be very desirable for those who are managing the contracts.)
iv. These are not directly related to Bitcoin/LN protocols, but will be needed, nevertheless.

2. Provide sign-off functionality. Internal approvals are often required for process management. For example, purchasing, engineering, manufacturing, finance, legal, management personnel might be required to sign off at various stages of a manufacturing contract. Similarly, various buyer personnel might be required to approve a payment. Knowledge of signature status can give insight into contractual progress.
i. Model the individual approvals as Schnorr signatures using a MuSig scheme. The aggregate Schnorr signature act as a representation or notice of product completion. Functionality requires key generation, signature creation, tracking, and transmitting pubkeys and signatures to the Counterparty.

3. Consider use of Bolt 12. A Bolt 12 Offer could be made to have contractual significance. An Offer from the seller as a Request for Invoice could be part of tender of delivery. The actual Request for Invoice could act as contractual acceptance. An Offer as a Send Me Invoice could be final settlement or payment of deposit surplus. Similarly, an Offer from the buyer as a Request for Invoice could act as contractual acceptance. A Officer as Send Me Invoice could be final settlement on the buyer side.

4. Channel Splicing. Consider channel splicing as the mechanism to update contract funding. Here it is important to understand that the LN Channel could be given contractual meaning, i.e. it could act as a contractual representation that funds are sufficient for a particular purpose. Channel splicing could be a means to incrementally fund a contract phase, adding to the funding while maintaining an existing channel and in the process acting as an updated contractual representation.

5. Covenants. Consider use of Covenants as a way to ensure payment of subcontractors.

6. Use of Fedimint/Taro as the payment network? LN Contract uses direct channels between the parties rather than relying on the LN payment network. This is appropriate because the parties contemplate a relationship. Direct channels might become uneconomical as adoption increases, given the requirement for an on-chain transaction. If so, alternatives should be considered, including perhaps Fedimint and Taro.

LNContract: Work in Progress

The LNContract manages the business contracts within the context of Bitcoin and Lightning protocols.

Read More