Jeremy Rubin · #1 ·
Linked below, a high level paper on how covenants could be introduced to Bitcoin without a soft fork using a mix of Functional Encryption and Zero Knowledge Proofs, posted here for discussion.
An archive of delvingbitcoin.org · view original topic →
Jeremy Rubin · #1 ·
Linked below, a high level paper on how covenants could be introduced to Bitcoin without a soft fork using a mix of Functional Encryption and Zero Knowledge Proofs, posted here for discussion.
Adam Gibson · #2 ·
Hi Jeremy,
thanks for this, looks very interesting. As I’m reading I’m seeing something that looks like a typo:
"Next, encrypt m " - should that be p ? and,
UniqueSecKey(p, TX) = Add(m, CTVHash(TX))
Same, shouldn’t m be p here?
Adam Gibson · #3 · · in reply to #2
Also, a clarifying question for the end of that section:
You write:
" \sigma \leftarrow C_F(C_p, Encrypt(M, TX))
\sigma can be used as a signature of u over TX".
Would this be correct?
\sigma = Decrypt(C_F, C_p, Encrypt(M, TX))
… where I’m taking the definition of Decrypt from the start of the paper and extending to the two-argument case, i.e. defining for an encryption public key of M, Decrypt(q, c_1, c_2) = X where the function has been previously defined F(a, b) = X and c_1, c_2 are ciphertexts of a, b and q is the output of EncryptFunc(M, F).
So anyway, if I got that right, let me try to translate into English what this machine does:
The basic building block is the ability to create a decryption key that decrypts a given ciphertext to the output of F when its plaintext is used as input.
The way you’re using it here (seems pretty clever!) is that you define a function which is " F(private key, transaction) = the ECDSA signature of a transaction by a private key tweaked by the hash of the transaction". This means that given the ciphertext of that tweaked private key, and “given” the ciphertext for the transaction (anyone can generate ciphertexts; this is public key cryptography), you can pass those two arguments into the output of the “basic building block above”; you’ll get a signature on that transaction. But, because of the tweak, if you try to do the same with any other transaction, it’ll fail.
(Deleted earlier misunderstanding)
Adam Gibson · #4 · · in reply to #3
So have I got this right:
Given C_F, the “functional encryption” and C_p, it allows anyone to create a signature for only the specified transaction for a given tweaked key.
So the flow is like:
The point being that this process is repeatable, for any transaction so it doesn’t require statically signing in advance, expecting certain outcomes.
Jeremy Rubin · #5 · · in reply to #2
astute read – yes it’s a typo.
Jeremy Rubin · #6 · · in reply to #3
yes this is correct understanding, and I think your decrypt function looks correct.
I think it’s more intuitive to think of Decrypt as just the actual function call, but the normal FE papers don’t do this for various reasons.
Jeremy Rubin · #7 · · in reply to #4
Yeah that sounds right.
The whole program instance stuff is designed to handle cases where the covenant instance (the program key) and the transaction are a one-key-to-many-transaction case.
Jeremy Rubin · #8 ·
@AdamISZ the deleting/editing is kind of confusing. But I think one other point to consider is normal signing federations have to actively sign this stuff, ongoing trust concern.
Whereas with FE’d Up Covenants, it’s a one-time compiler build for all eternity (until quantum computers tell us we can’t have fun ever again?).
My spookchains writeup is… spookily similar to this kind of setup, so maybe worth reading for a more thorough discussion (end section " Commentary on Trust and Covenantiness") Spookchains: Drivechain Analog with Trusted Setup & APO · Jeremy Rubin