From jr at mit.edu Fri Aug 28 22:36:25 2015 From: jr at mit.edu (Jeremy Rubin) Date: Fri, 28 Aug 2015 18:36:25 -0400 Subject: [Lightning-dev] Negotiating & Committing Signatures Message-ID: Negotiating & Committing Signatures ============================ In this proposal, I suggest the addition of new types of signature schemes to Bitcoin, and running lightning over multi signature of the variants to utilize the advantages of multiple signature schemes without the drawbacks. Secure Construction of Signature Variants ================================ Suppose you have a signature scheme A and a signature scheme B. Assume we can categorize A as a "better to commit to" scheme (ie, it is easier to put on the blockchain) and B as a "better to negotiate with" scheme (ie, it is easier to renegotiate with). Assume these advantages and disadvantages are somewhat disjoint, and we would like to leverage both. Therefore, we can operate lightning where each parties key is a 1 of 2 merkelized multisig (or H(H(PK_A)+H(PK_B)) ). Now, in this scheme, only either a signature with A or B would be needed for the payment to be valid, and the space hit for the merkle proof is marginal. What this enables a user to do is to use signature scheme B for the main set of negotiations, and when it is time to settle, request switching to A. If the settlement is in the case where parties disagree and are not cooperating, the version signed with scheme B would still allow for settlement. However, assuming this case is infrequent, B should rarely be needed. Signature Schemes ================= ECDSA is the only signature scheme available in Bitcoin currently. However, there exist a multitude of signature schemes with many unique properties. SecureRF (Derek Atkins, CTO is cc'd) has developed a novel signature algorithm based on the Braid Group (it's a new paper -- not purely based on the conjugacy problem) which promises to be significantly more efficient to verify. (I do not have the know-how to audit their claims and cryptosystem, so assuming it is correct my analysis follows...). The size of their keys/signature is approximately an order of magnitude larger, but their verfication time is approximately 200x faster. Thus, were one to use this signature scheme as "B", it would have the property of being better to negotiate with but worse to settle on as it would contribute to blockchain bloat. There may be other such schemes B that would be interesting to explore, but I have limited knowledge here. Motivation ======== So why put effort into making the negotiation phase easier? By lowering the requirements to verify a payment, embedded systems could be made less expensive that can verify a lightning network payment. This capability would mean that it would be easier to have a large collection of devices which can receive and verify micropayments easily, eg, anywhere you might have a coin slot. It's unclear if this would provide great value over having the devices outsource verification, but is worth discussion as their may be other benefits derived from a negotiation v.s. committing key. Drawbacks ======== Such a scheme requires that new signature algorithms be added to Bitcoin; this may be difficult to get implemented. However, if the benefits of having distinct negotiating v.s. committing keys has a tangible effect on the usability & scalability of layer 2 systems such as lightning it may be a worthwhile pursuit. Happy to hear your thoughts on the usefulness of such a scheme, and if it has applications outside of lightning. Cheers, Jeremy -- @JeremyRubin -------------- next part -------------- An HTML attachment was scrubbed... URL: