Investigate BLS Signatures

[quentinlesceller]

Opening this issue to gather ressources and discuss the possibility of using BLS signatures in Grin.

Pro

• Kernel aggregation
• Simpler multi-signatures schemes.

Cons

• Loss of the current form of scriptless script
• Change of security assumption
• Possibly slower to verify than Schnorr signatures
• Few available libraries with little code review

Ressources:

• List of current implementations: BLS12-381 curve and aggregation libraries ethereum/eth2.0-pm#13
• BLS Signatures implementation from Chia
• BLS Multi-Signatures With Public-Key Aggregation

[GandalfThePink]

All of the cryptography based on Weil pairings is extremely interesting and I think there is a lot of open potential that should be studied.

However, Grin only uses very simple and well tested cryptographic concepts and I think this should be preserved.

That said I am very interested to explore and discuss. I understand how to build mutlisignatures in BLS, but fail to see how it allows for kernel aggregation. Can you point me to how this can be achieved in an non-interactive way.

[lehnberg]

Relevant forum thread: https://www.grin-forum.org/t/bls-signatures-implementation-from-chia/609

Can you point me to how this can be achieved in an non-interactive way.

@GandalfThePink see here https://eprint.iacr.org/2018/483

[ignopeverell]

Relevant paper:

https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html

[GandalfThePink]

Hi, I have studied BLS signatures a little and then found some interesting ideas that I pursued furhter enabling user-issued assets. If you find any flaws, please let me know. Otherwise I am happy to discuss.

MWpp.pdf

[ignopeverell]

I'll need a couple more reads to fully parse this, especially security arguments, but you tickle me pink Gandalf.

[antiochp]

Reading through that MWpp.pdf paper. There's a lot to digest in there. Interesting reading.

[lehnberg]

Ditto. @GandalfThePink, for deeper scrutiny, you might want to consider posting the paper to the MW mailing list.

[0xb100d]

@GandalfThePink public txs take up just as much space on the chain as private ones? Same cutthrough requirements? And public address can send to private address? So you could give someone public address for them to send to you, and then you send it to yourself privacy (which would be simple to interact with onesself).

Also hanging outputs take up space and cannot be pruned right? Is there any way to incentivize people to spend them quickly to minimze the time they are on chain taking up extra space?

[GandalfThePink]

@0xb100d Public transactions would be slightly larger due to the extra address. Immediate through is a good question I have not really thought much about.

You can restore privacy by sending yourself a private transaction from your public address. Best combine 1 public and one private into 2 private and all information is lost.

Hanging outputs are a bit more complex than normal ones. But I think this would not be a big problem since they are still UTXO's. If we want theoretical scaling with the UTXO size then that is perfectly fine. We are just talking about a constant factor. I think there is no simple way to incentivise spending them faster.

[ignopeverell]

Correct me if I'm wrong @GandalfThePink (or anyone else who had a look) but there seems to be an important privacy regression with hanging transactions. Specifically, for the hanging transaction to be published and included in the chain, all output commitments must be known. And until the transaction is finalized they're all of the form C=vL without blinding.

I've tried to see if things could be rearranged a bit but it seems vL will be leaked no matter the arrangement?

[GandalfThePink]

Hi @ignopeverell

can you be a bit more specific. I think it is possible to build private hanging transactions. The only time all commits must be known is when they are also sent offline. In that case the amount must be committed unblinded.
To be more specific, all participants that are offline can only receive unblinded.

[ignopeverell]

@GandalfThePink

To be more specific, all participants that are offline can only receive unblinded.

That's what I meant. For hanging transactions to be included in the chain to be completed later, as you seem to propose in section 4 Building Non-Interactive Transactions and following, their output amounts can't be blinded (yet). This same setup can surely be done off-chain but then you lose most of the advantages of non-interactivity from a user experience standpoint (i.e. user has to be online or an intermediary needs to be involved to keep the hanging transaction).

[GandalfThePink]

I think there is a way to blind it even in that case.

The problem is that in order to blind the sender must be able to generate valid signatures. And that is easily avoided by simply not blinding. But in fact the output could be blinded by a shared secret. We already know a public key of the receiver. Assuming that the sender also commits to a public key, a shared secret is quickly established and that secret can be signed for by the sender or the receiver alone.

Now in order to spend the output, both the private key and the shared secret is needed, which means that only the receiver can spend it. And in case of conflict for third party verification, the sender can also generate proof that the blinding is in fact to a shared secret. I.e. the sender can prove that the receiver can spend the output.