Published on: 2015-12-08T02:10:46+00:00
In a thread on the Lightning Development mailing list, Andrew Miller suggests that using a SNARK (Succinct Non-Interactive Argument of Knowledge) may be unnecessary for a specific application. The reason for this is unclear, but Miller asks if the required messages are too large or if verification takes too long. He also wonders if an interactive zero-knowledge (ZK) proof using Yao garbled circuits would be sufficient for their needs.The post discusses the use of SNARKs to increase privacy in Lightning network transactions. The idea is to create a proof that a hash value was computed from a specific input, without revealing the input itself. This can be used to improve privacy in HTLCs for atomic swaps across chains. A Zcash engineer replicated the experiment from the original post using libsnark and reported efficient results. However, there are limitations such as the time and computational resources required to generate the proof data and the need for trust in the original random numbers used to generate the verification key.In a discussion over email, Anthony Towns suggested a method for adding privacy to how hash time-locked contracts (HTLCs) are cleared on the blockchain. By revealing P/Q/R, it is possible to add privacy at the cost of extra bytes per HTLC per channel when cleared on the blockchain. The extra cost is approximately 3 cents per HTLC. Towns also mentioned that it may be more economical to forget a small HTLC than to commit it.The discussion also involves finding cleaner solutions for revealing private keys in complicated scenarios with multiple HTLCs or payments. Different approaches were proposed, including using stack operations in scriptPubkey and having scriptSig contain Q, R, and three signatures. There were discussions about the complexity and security of these approaches.Rusty Russell suggested two approaches for forcing someone to reveal a private key corresponding to a secp256k1 public key P. One approach involved generating a signature with P that has 15 leading zero bytes or more. The other approach was more complicated but faster and involved assuming two keypairs and having a scalar p such that r = p * q. Greg Maxwell pointed out a quicker way to calculate P using the incoming HTLC public key Q.The email thread also discussed the segregated witness proposal and the introduction of new opcodes. There were different opinions on how easy it would be to introduce new opcodes with the proposal.In a conversation between Anthony Towns and Rusty Russell, they discussed whether the segregated witness proposal makes introducing new opcodes easier. They concluded that the proposal involved the first byte of SW script being a version byte, allowing for adding ops that change the contents of the stack as a soft fork instead of a hard fork.Anthony Towns discussed the possibility of dividing QN by (r2*..*rN) to get back to Q1 in Bitcoin transactions. He suggested using SHA(ECDH_SEC || 3) as the r values at each stage. However, a problem arises if a transaction routes through multiple parties, as extra payload must be added to each hop.A proposal for a payment system was made by Anthony Towns, using elliptic curve (EC) keys to ensure correct payment. The user would be given two key pairs: K1 and K2, such that K2 = K1 * p. By knowing p, the user can verify the relationship between K1 and K2. The user can then construct r2, r3, etc., and route the HTLC payable to qN at the first hop, q[N-1] at the second, all the way to q1 when it gets to the merchant. If the user divides QN by (r2*..*rN), he or she will get back to the original receipt/proof of payment. The burden for keeping the payment private falls entirely on the consumer, rather than the merchant.The author discusses several issues and proposed solutions related to improving privacy and functionality in the Lightning Network. Firstly, it is important to ensure the correct implementation of the payment system. The author suggests the introduction of a new operator, OP_CHECKPRIVPUBKEYPAIR, to enforce a payment with a private-public key pair. Additionally, two generic crypto operations, OP_CHECK_SECP256K1_MUL_VERIFY and OP_CHECK_INLINE_SIGNATURE_VERIFY, may be useful for future soft-forkability.Another proposal by Mats Jerratsch involves using EC keys instead of preimage-hash verification to achieve similar results without using SNARKs. This would utilize the arithmetic operations inherited from the elliptic curve field. However, there is currently no way to enforce a payment with a priv/pub key pair, so the introduction of a new operator or opcode is suggested.To address the privacy limitation in the Lightning Network, the author suggests using zero-knowledge proofs (ZKPs) to prove that certain values are equal without revealing those values.
Updated on: 2023-07-31T18:27:54.320395+00:00