abstract | author | title | |
---|---|---|---|
Semi-Honest batch generated N-of-N ECDSA threshold single signatures are
a useful new tool for building backwards-compatible smart contracts for
Bitcoin.
Protocols for N-of-N threshold ECDSA have been demonstrated previously,
but are usually inefficient because of requirements for expensive
consistency checks which add new assumptions and complexity to these
protocols. This protocol is unique because it does not require any
consistency checks by working a semi-honest model sufficient for a broad
class of applications.
Non backwards compatible schemes – such as Schnorr Signatures, which
requires modifications to Bitcoin – have also been demonstrated
previously, but because they require changes they are not guaranteed to
be available or accepted.
|
|
Efficiently Batch Generating N-of-N ECDSA Threshold Single Signatures\
in a Semi-Honest Model\
and Uses for Bitcoin
|
Assume a curve with a base point denoted
We demonstrate a protocol whereby two participants with a secret
We denote this scheme
We show how such a scheme can be built from a 1 of 2 Oblivious Transfer assumption. HL17 presents an efficient scheme for 1-of-N Oblivious Transfer under the Computational Diffie Helman assumption.
Alice with an
Alice then picks a set of
Alice’s secret share
Alice then computes
For each row of this table, Alice does a
If
Bob, then inputs his value
Thus,
An optimal selection of parameters for this protocol is
And Bob learns, through oblivious transfer:
The cost of this is $256256 = 65536$ Oblivious Transfers, and
approximately $256256*2$ bits, or
With an optimized 1-of-N OT which transfers 256 Bit Keys, like HL17, we
are free to pick a more agressive radix such as
$$x = \alpha \begin{bmatrix} 0 & 1& \cdots & 255\ \vdots & \vdots & \ddots & \vdots &\ 0 & 2^{8i} & \cdots & 255 \cdot 2^{8i}\ \vdots &\vdots & \ddots & \vdots\ 0 & 2^{248} & \cdots & 255 \cdot 2^{248}\ \end{bmatrix} - \begin{bmatrix} \phi_0 \ \vdots\ \phi_i\ \vdots\ \phi_{31} \end{bmatrix}$$ And Bob learns, through oblivious transfer:
The signature algorithm has three components, Reusable Nonce Generation, Single Use Key Generation, and Signing.
Our goal is to generate a nonce
Let each party generate a secret
Each party also computes the multiplicative modular inverse of
All parties compute the group element
Precommits are not needed in this ring compution because breaking the
nonce generation would reduce to a break in ECDLH assumption. An
adverasy at
The public nonce
Additional nonces may be cheaply generated by participants by generating
securely among all participants (perhaps using an efficient protocol
like fair coin flipping over the phone) a second nonce
This blinds the nonce from the public network which reduces linkability between transactions using the same nonce.
First, all parties generate a public key private key pair denoted.
Let
Next, parties sum their public keys to produce an aggregate public key
Let
It is critical that every
It is also possible to use MuSig Key Aggregation as follows:
Let
The security of this construction is in the MuSig paper.
The other benefit of this is that the keys would be compatible with Schnorr signatures once merged.
Our goal is to compute the standard ECDSA signature equation
without any party learning
We set the desired message to be signed as
First we substitute the shares of
To simplify this expression, we distribute the
For convenience, we rewrite the right-hand factors as secrets
Then, we distribute a nonce share
And replace each individual operation with an oblivious transfer multiplication.
$$s \equiv (q_2 \cdots q_n)\cdot({\pi_{}}(q_1,\eta_1) + \ldots + {\pi_{}}(q_1,\eta_n)) \mod N$$
We can optimize the term when
$$s \equiv (q_2 \cdots q_n)\cdot(q_1\eta_1 + {\pi_{}}(q_1,\eta_2) + \ldots + {\pi_{}}(q_1,\eta_n)) \mod N$$
Running the Oblivious Transfer Multiplication operations results in
This can be reduced back down to
After iterating the above step with every factor
The participants reveal their
Revealing
Lastly to finish constructing the signature, we compute:
Now, we verify
If the signature verifies, this serves as a consistency check that the signature was honestly computed and no key data was leaked.
The total number of Oblivious Transfer Multiplications required of this
protocol is
With an application-specific optimization, where for each subsequent
signature there are
If we run a single round of Reusable Nonce Generation, we may run
This signature scheme is secure for pre-signing a tree of transactions and then creating the root parent transaction. Because of the semi-honest model, it is not secure for non-presigned use cases.
All of these use cases work with either Schnorr signatures (with modification to Bitcoin), or in plaintext multisig (with cost of scalability and bound on number of participants).
A group of participants can construct a tree of presigned transactions that they are willing to accept as a payment from another set of participants.
The payees submit to the payers a request for an unsigned transaction which pays out the desired balance to an aggregated key.
The payer builds such a transaction, selecting their preferred inputs.
They payees, upon receiving this TXID, generate a binary tree of presigned transactions which pays out each participant at the leafs.
The payees, upon finishing the tree construction, instruct the payer to complete the payment.
The overall overhead of this protocol is
This is sort of like a Certified cheque in that the balance is guaranteed, and is like a post-dated cheque in that the balance is only redeemable at some time later, hence the name. CPDU for short!
CPDU payments efficacy as a scaling solution is difficult to model, but in a maximal use case, there could be a single output per ’high volume’ block, which could support 40 unique payers/per second paying to a practically unlimited number of recipients. In practice, this protocol is limited by the number of cooperating recipients and the need of recipients to eventually redeem.
An untrusting group of participants can perform the above CPDU protocol with all of their outstanding UTXOs.
Then, at a time later, only when needed, they can quickly (
This is similar to UTXO Commitment Proofs, but it uses on-chain bandwidth to expand the transactions.
Using Mixnets to mask which participant selects which outputs, CPDU protocol can be used to make a more efficient CoinJoin which has delayed revelation of what the outputs are. Because of the key-aggregation, the branches of the coinjoin are indistinguishable from future payments.
If the CPDU protocol is done with multiple alternative branches (requiring a number of reusable nonces equal to the max branch width), CPDU can be used to develop complicated smart contracts which depend on other data or UTXOs which may be only potentially available.
Assuming we want to transfer 1-of-N
Alice encrypts each entry
$$enc(m_{\texttt{0xAA}}) = \epsilon_{k^{1}{0}}(\epsilon{k^{0}{1}}(\epsilon{k^{1}{2}}(\epsilon{k^{0}{3}}(\epsilon{k^{1}{4}}(\epsilon{k^{0}{5}}(\epsilon{k^{1}{6}}(\epsilon{k^{0}{7}}(m{\texttt{0xAA}}))))))))$$
Alice encrypts each entry as above and sends all the ciphertexts to Bob.
Alice then puts each keypair
Bob selects one out of two for each bit and after selecting
Any encryption scheme may be selected, but a XOR one-time-pad is sufficient.