Jeremy Rubin [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-28 📝 Original message: Negotiating & Committing ...
📅 Original date posted:2015-08-28
📝 Original message:
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 <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150828/d00b7587/attachment.html>;
📝 Original message:
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 <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150828/d00b7587/attachment.html>;