Since none of the participants have access to the private key, is it possible to create a bitcoin wallet address that requires knowing the private key?

Is this a BUG REPORT or FEATURE REQUEST?:
BUG REPORT

What happened:
Using the example provided in alice, signing a message with 32 characters or less works fine. However, verifying a signed message of >32 characters fails.

What you expected to happen:
Expected to be able to successfully verify signature, regardless of message length.

How to reproduce it (as minimally and precisely as possible):
Running in Python 3.6.5
verify succeeds for msg1, but fails for msg2.

from ecpy.curves     import Curve,Point
from ecpy.keys       import ECPublicKey, ECPrivateKey
from ecpy.ecdsa      import ECDSA
import ecpy
from hashlib         import sha256

x = 82413025421550975780465452441471161579661032066499417714228771730090744271913
y = 77571870843403463763751119133059698966486723073744225522787423143129206189894

r1 = 32695600450337335906409614685668869399586796812718975177037483691275486581146
s1 = 82626493698088701273493631120474244794368213158721442704511347257757089426086

r2 = 16059247622785756262933476254168544184547141890459315662517063489502002819228
s2 = 67558261624811019589051140398882107624531221420268322720544033809973798414645

msg1 = b'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEF'
msg2 = b'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFG'

cv   = Curve.get_curve('secp256k1')
pu_key = ECPublicKey(Point(x, y, cv))

sig1 = ecpy.ecdsa.encode_sig(r1, s1, 'DER')
sig2 = ecpy.ecdsa.encode_sig(r2, s2, 'DER')

signer = ECDSA(fmt='DER')

print(signer.verify(msg1,sig1,pu_key)) # returns True
print(signer.verify(msg2,sig2,pu_key)) # returns False

Also ran an example from ECPy to make sure this wasn't an issue with the Python library. Here is that code below you can run if you'd like to double check yourself.

pu_key = ECPublicKey(Point(0x65d5b8bf9ab1801c9f168d4815994ad35f1dcb6ae6c7a1a303966b677b813b00,

                           0xe6b865e529b8ecbf71cf966e900477d49ced5846d7662dd2dd11ccd55c0aff7f,
                           cv))
pv_key = ECPrivateKey(0xfb26a4e75eec75544c0f44e937dcf5ee6355c7176600b9688c667e5c283b43c5,
                      cv)
msg3 = b'ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFG'
sig    = signer.sign(msg3, pv_key)
r3, s3 = ecpy.formatters.decode_sig(sig, fmt='DER')
sig3 = ecpy.ecdsa.encode_sig(r3, s3, 'DER')
print(signer.verify(msg3, sig3, pu_key)) # returns True

Is there any processing I need to do to longer messages to prepare it for tss signing?

Thanks for taking a look.

why I got this error in run-time?
I import gg18.singer and frost.singer in example.

`panic: proto: file "github.com/getamis/alice/crypto/tss/eddsa/frost/signer/message.proto" has a name conflict over signer.Type
previously from: "github.com/getamis/alice/crypto/tss/ecdsa/gg18/signer"
currently from: "github.com/getamis/alice/crypto/tss/eddsa/frost/signer"
See https://developers.google.com/protocol-buffers/docs/reference/go/faq#namespace-conflict

goroutine 1 [running]:
google.golang.org/protobuf/reflect/protoregistry.glob..func1({0x4bfc640, 0xc0002194d0}, {0x4bfc640, 0xc000219510})
/Users/walker/work/golang_work17/pkg/mod/google.golang.org/[email protected]/reflect/protoregistry/registry.go:54 +0x1f4
google.golang.org/protobuf/reflect/protoregistry.(*Files).RegisterFile.func1({0x4c20848, 0xc000249f80})
/Users/walker/work/golang_work17/pkg/mod/google.golang.org/[email protected]/reflect/protoregistry/registry.go:152 +0x28f
google.golang.org/protobuf/reflect/protoregistry.rangeTopLevelDescriptors({0x4c297e0, 0xc000246000}, 0xc0006ef738)
/Users/walker/work/golang_work17/pkg/mod/google.golang.org/[email protected]/reflect/protoregistry/registry.go:396 +0xab
google.golang.org/protobuf/reflect/protoregistry.(*Files).RegisterFile(0xc00011a2b0, {0x4c297e0, 0xc000246000})
/Users/walker/work/golang_work17/pkg/mod/google.golang.org/[email protected]/reflect/protoregistry/registry.go:147 +0x750
google.golang.org/protobuf/internal/filedesc.Builder.Build({{0x4816b2a, 0x36}, {0x51e98c0, 0x27f, 0x27f}, 0x1, 0x3, 0x0, 0x0, {0x4c08b48, ...}, ...})
/Users/walker/work/golang_work17/pkg/mod/google.golang.org/[email protected]/internal/filedesc/build.go:113 +0x1d6
google.golang.org/protobuf/internal/filetype.Builder.Build({{{0x4816b2a, 0x36}, {0x51e98c0, 0x27f, 0x27f}, 0x1, 0x3, 0x0, 0x0, {0x0, ...}, ...}, ...})
/Users/walker/work/golang_work17/pkg/mod/google.golang.org/[email protected]/internal/filetype/build.go:139 +0x198
github.com/getamis/alice/crypto/tss/eddsa/frost/signer.file_github_com_getamis_alice_crypto_tss_eddsa_frost_signer_message_proto_init()
/Users/walker/work/common_work/tss/alice/crypto/tss/eddsa/frost/signer/message.pb.go:433 +0x238
github.com/getamis/alice/crypto/tss/eddsa/frost/signer.init.0()
/Users/walker/work/common_work/tss/alice/crypto/tss/eddsa/frost/signer/message.pb.go:372 +0x17`

for this scene, if i lose my share private key, how can i recover the lost share private key。

Observation

What happened:

1. In matrix.go the following comment seems out of place: Line 171.

2. In cl.go the following comment seems out of place: Line 515.

3. In utils.go the following comment does not fit the code: Line 62.

Observation

What happened:
In paillier.go, the function computeRangeProof(n) actually computes (n − 1)^2. Even
if the function is private, this might sound misleading, also because range proofs are
not used in the current Alice scheme.

mySigner, err = signer.NewSigner(signerPeerManager, publicKey, homo, share, bks, msg, listener)
if err != nil {
    // handle error
}
mySigner.Start()
// send out public key message...
mySigner.Stop()
signerResult, err := mySigner.GetResult()
if err != nil {
    // handle error
}

Q1: Can the parameter msg be other information？
Q2:Can msg be included in the signerResult after the signature is successful?
Q3:What did msg do during the signing process？

Severity: Low:

What happened:
In cl.go, CL encryption is implemented as per Algorithm 20, but without checking the
size of the input plaintext.

Severity: Low

Description and Impact Summary:
In the red-alert #1 algorithm in the paper (Fig. 11), the μi,j values are computed modulo Ni while in the implementation they are computed modulo nsquare. The same happens for red-alert #2 algorithm (Fig. 12) in round_6.go.
Even if the proof psiMuProof later on is reduced modulo N correctly, having the mu proofs belonging to a larger group might leak undesired information. At a very minimum invalidates the security proof of the scheme.

Severity: Medium

Description and Impact Summary:

At the second step of round 2 of the presign phase, both in the 3-round and the 6-rounds variants (Fig. 7 and 9 of the paper, respectively), the two psi proofs should be computed and sent only when the enc-elg proof has been verified for all parties.In the implementation, they are instead sent after passing their sender’s verification only, without waiting for all others. This is actually done in round_1.go rather than round_2.go. In addition to make the code difficult to parse, this might introduce the possibility of (ZKP counterpart of) rogue key attacks, see for example here. The idea is that an adversary could delay their response until they manage to see every other parties’ response, and craft ad-hoc proofs adaptively on those responses to, e.g., pass a subsequent verification step without a proper witness. Even though we are not able to provide a specific attack in this case, we consider this a serious deviation from the original protocol, so the issue is marked as medium severity.

Severity: High

Description and Impact Summary:

At the end of the first round of the presign phase, both in the 3-round and the 6-rounds variants (Fig. 7 and 9 of the paper, respectively), there is certain data that must be sent (privately, e.g., on a secure channel) to some other peers, and some data that must be reliably broadcast to all peers.

However, in the code (sendRound1Messages) there is no such distinction, and all these messages are communicated peer-to-peer to every other party. This introduces potentially serious vulnerabilities, as there is no way to make sure that a malicious party is not sending the same “public” values to everyone else. In fact, a malicious party could “segment” the pool of other participants by sending a certain value to some of them, and another value to all the others. This is similar to the “forget-and- forgive” attack described for example in https://eprint.iacr.org/2020/1052.pdf (more information here).

@markya0616 @cychuang0924 could you take a look at this: too many sign verify failed in ed25519 example.

git repo: https://github.com/alexSmallWorld/alice-ed25519/tree/ed25519Example
git branch: ed25519Example
in this branch I add ed25519 example and batch test script.

how to run batch test: 1, use go 17; 2, cd example && ./rerun.sh
you will see the test processing and result. ** false mean how many case verify sign failed. ** true mean how many case verify sign success.
like:

thanks a lot.

Observation

What happened:
Although we do not consider them to be vulnerabilities given the scope of the audit,
there are many points in the code where the implemenetation of certain functions
leaks information about the input through timing side channels. This happens in
particular in matrix.go and birkhoffinterpolation.go. Some examples:

• in matrix.go: lines 258, 337, 414, 502, 566.
• In birkhoffinterpolation.go: lines 79, 82, 102, 138, 164.

Severity: Low

What happened:
In paillier.go the function NewPaillier implements Algorithm 11 of the protocol
specs document.
L115 func NewPaillier(keySize int) (*Paillier, error) {
L116 p, q, n, lambda, err := getNAndLambda(keySize)
L117. if err != nil {
L118 return nil, err

However, keySize is not checked. Extremely low and insecure values of keysize will
thus be accepted.

Is this a BUG REPORT or FEATURE REQUEST?:
Feature Request

What happened:
We have our own blockchain, and We are using Alice to generate MPC Shares needed for signatures for different blockchains (BTC, ETH). Currently we can smoothly generate Signatures on non-encrypted transaction data.
But our Transaction data would be actually be in an encrypted form for Production release and therein lies our blocker.

What you expected to happen:
We are trying to achieve the same result when generating Signatures for encrypted transaction data.
Any support or direction along these lines would be really helpful.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Severity: Low

What happened:
In ecgrouplaw.go the function ComputeLinearCombinationPoint at line 54 can skip
cycles if an element is zero.
This is done to save on performance but it can leak information on the number of
non-zero coefficients of the linear combination.

Severity: Low

What happened:
In cl.go the function NewCL generates new CL encryption parameters.
Algorithm 24 in the protocol specs document does not take a prime p as input as in
the code above, but generates it internally instead. This is fine, however NewCL should
perform a sanity check on p (primality and size) to avoid misbehavior. Moreover, there
is no check enforced on the size of safeParameter nor derived values

FEATURE REQUEST:

Verification of signed messages requires v,r,s components of signature. Currently, a tss signature produces only r and s. The v needs to be computed separately. v can have 4 values. The encoding for v (called recid) depends on the blockchain, whether the address is compressed etc. For bitcoin uncompressed address, the value is 27 or 28 in almost all cases. From compressed addresses it would be 31,32

https://en.bitcoin.it/wiki/BIP_0137#Specification

Ideally, there is a way to generate the v part as well. Blockchain specific encoding is optional. Only values 0,1,2,3 is needed.

Observation

What happened:
In polynomial.go, the function Differentiate first checks if the order of the derivative
is greater or equal to the degree of the polynomial, and if so returns the zero
polynomial. This is clearly not constant-time as it can leak the degree of the polynomial,
which is not a problem in this particular application as the degree is known, but it might
be in general.

Observation

What happened:
In the function getNAndLambda (Algorithm 16) two large primes p and q are generated and then it is checked that GCD(pq, (p − 1)(q − 1)) = 1. This is done also in paillier.go line 221. But this check is redundant: if p and q are two large primes then it will always be GCD(pq, (p − 1)(q − 1)) = 1.

In alice, there a lot of test case in one package, but i just want to run only one test case, like in tss/dkg, i just want to test dkg_test.go.
Like in go.testing, I run go test -run NewDKG will only run one case.

Severity: Low

What happened:
In integerfactorization.go the security parameter is provided by the prover (public
key). The proof verification does not enforce minimal security (parameter length), nor
does it check for degenerate cases 0 and 1.

Observation

What happened:
In dbns.go the two initial loops could be unified (except for the first index case i=0 that
could be unrolled outside) to save on performance.

Severity: High

Description and Impact Summary:
In the code, each party’s own public key value Yi is computed during round 1 of signing, and transmitted to each other party to be used in round 2. However, this is a deviation from the FROST protocol. In the paper, every party is responsible for reconstructing each other parties’ public key using information exchanged during the key generation phase (Step 4 of Round 2 of Key Generation, Fig.1), and public keys of all participants are stored as an indicator of that party’s identity.
If this public key is first computed by each party during signing, instead, this gives no security guarantee because it implicitly assumes that every party behaves honestly at that step, by sending to everyone else their correctly computed public key.

the protobuf version that using in alice is old and have conflict with new version please update pb.protos and add a protoc compiling script.

Observation

What happened:
One might expect that, when available, the ZK factorization proof be verified when encrypting (as a validation that the sender knows the private key), but this check is not performed.

Hi
In the DKG algorithm of HTSS , the second step of pseudocode says to "compute birkoff coefficeint for each participant".
What is birkoff coefficient here?
Are we regenerating the secrets during verification of public key?
Please elaborate

Severity: Medium

What happened:
In hash.go the function getDigest computes the (keyed) hash function Blake2 of a byte
array originData using another byte array salt as cryptographic salt.

L114 checkData := append(originData, salt...)
L115 digest := blake2b256.Sum(checkData)

However, there is no check on the size of salt and no domain separation between
salt and data. This would allow to call the function maliciously and generate collisions,
because, e.g., the hash of (foo , bar) and (fo , obar) would be the same.

Is alice can handle 2 key sign/keygen requesed at same time ?

Observation

What happened:
In mta.go we observe the following comment (that also matches the code):
// Compute gets the encrypted k with a random beta
// alpha = (E(encMessage) * a) + E(beta), where * is [...]
func (m *mta) Compute(publicKey homo.Pubkey, encMessage []byte) (*big.Int, *big.Int,
􏱮→ error) {
Looking at the protocol spec documentation, Algorithms 37 and 38, it seems that the function above should rather compute c = (E(encMessage) ∗ b) + E(β). We understand that this is a specular situation from each participant’s point of view, but we suggest changing the names of the variables involved to make it easier to follow the specs.

Severity: High

Description and Impact Summary:
In the code implementation, the peers just set the new share to the sum of the decrypted shares received from other parties and its own refresh share, basically ending up with a new set of shares of 0. The same happens for the refresh of the partial public keys
This is very serious, because it means that after a refresh, or before any signature, the secret key is basically reset to a zero value.

Description and Impact Summary:
We observe that in the CGGMP implementation, the various files round_X.go do not completely reflect the corresponding steps as described in the paper. For example, round_4.go contains both proof generation from the paper’s round 4 and verification of the same proofs which appear in the paper’s round 5. This makes the flow of the program hard to parse to the paper.

I wonder how can I verify the correctness of the signature?:

Is there a corresponding verification method provided?:

can alice support EDDSA ?

Hello!
I'm still trying to use the library and playing a bit with the /example code.

I'd like to ask you this, when doing a resharing how can I increment/decrement the number of shares?
Moreover, when resharing is it possible to modify the threshold? if yes, how?

Thanks and sorry for the inconvenience

I was trying to implement OnStateChanged (master branch) but MainState type is in internal package, and I cannot access it without cloning the repo and manually exporting it... Is there any workaround for this?

go version:
go version go1.16.6 darwin/amd64

Is this a BUG REPORT or FEATURE REQUEST?:
Bug report

What happened:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x14b3572]

goroutine 1 [running]:
github.com/gogo/protobuf/proto.makeOneOfMarshaler.func1(0xc00046e220, 0x0, 0xa)
/go/pkg/mod/github.com/gogo/[email protected]/proto/table_marshal.go:2598 +0x132
github.com/gogo/protobuf/proto.(*marshalInfo).size(0xc0001c2480, 0xc00046e1e0, 0xc0001c4360)
/go/pkg/mod/github.com/gogo/[email protected]/proto/table_marshal.go:200 +0xa2
github.com/gogo/protobuf/proto.(*InternalMessageInfo).Size(0xc0001c4360, 0x9e37c60, 0xc00046e1e0, 0x0)
/go/pkg/mod/github.com/gogo/[email protected]/proto/table_marshal.go:131 +0x66
github.com/gogo/protobuf/proto.Marshal(0x9e37c60, 0xc00046e1e0, 0xc00046e1e0, 0x0, 0x0, 0x100cd00, 0x179d580)
/go/pkg/mod/github.com/gogo/[email protected]/proto/table_marshal.go:2952 +0xfe
github.com/gogo/protobuf/io.(*fullWriter).WriteMsg(0xc0003019e8, 0x9e37c60, 0xc00046e1e0, 0x9e37c60, 0xc00046e1e0)
/go/pkg/mod/github.com/gogo/[email protected]/io/full.go:64 +0x215
github.com/getamis/alice/example/peer.send(0x1a69e70, 0xc00012e0b8, 0x1a722e0, 0xc000149600, 0xc000156b90, 0x4b, 0x1817e60, 0xc00046e1e0, 0x185daea, 0xa, ...)
/go/src/github.com/getamis/alice/example/peer/node.go:113 +0x6af
github.com/getamis/alice/example/peer.(*peerManager).MustSend(0xc000355780, 0xc000371a38, 0x8, 0x1817e60, 0xc00046e1e0)
/go/src/github.com/getamis/alice/example/peer/pm.go:62 +0xf2
github.com/getamis/alice/crypto/tss/dkg.(*peerHandler).broadcast(0xc000384310, 0x1a66ed0, 0xc00046e1e0)
/go/src/github.com/getamis/alice/crypto/tss/dkg/0_peer_handler.go:203 +0xb1
github.com/getamis/alice/crypto/tss/dkg.(*DKG).Start(0xc00030c6c0)
/go/src/github.com/getamis/alice/crypto/tss/dkg/dkg.go:108 +0x6c
github.com/getamis/alice/example/dkg.(*service).Process(0xc0003c50b0)
/go/src/github.com/getamis/alice/example/dkg/service.go:78 +0x45
github.com/getamis/alice/example/dkg.glob..func1(0x1f275e0, 0xc00038e060, 0x0, 0x2, 0x0, 0x0)
/go/src/github.com/getamis/alice/example/dkg/main.go:71 +0x509
github.com/spf13/cobra.(*Command).execute(0x1f275e0, 0xc00038e040, 0x2, 0x2, 0x1f275e0, 0xc00038e040)
/go/pkg/mod/github.com/spf13/[email protected]/command.go:826 +0x472
github.com/spf13/cobra.(*Command).ExecuteC(0x1f27d60, 0xc000000180, 0xc00045ff78, 0x1007925)
/go/pkg/mod/github.com/spf13/[email protected]/command.go:914 +0x30b
github.com/spf13/cobra.(*Command).Execute(...)
/go/pkg/mod/github.com/spf13/[email protected]/command.go:864
main.main()
/go/src/github.com/getamis/alice/example/main.go:39 +0x31

What you expected to happen:
I run 2 nodes, 10001 and 10002, when they try to send msg to each other, marshal error happens

How to reproduce it (as minimally and precisely as possible):
should I change to golang/protobuf?

Anything else we need to know?:

golang/protobuf#1005
it seems like the same problem

Will the addshare feature be released in July?

I tried to verify an ecdsa signature produced by the library, and the verification fails.
This is the python script that I used to verify

from ecpy.curves     import Curve,Point
from ecpy.keys       import ECPublicKey, ECPrivateKey
from ecpy.ecdsa      import ECDSA
import ecpy
from hashlib         import sha256

x = 47143094896967716337843669989860432144962851204356940818421228324575441222601
y = 23336444423741848139737884993242101588835841992098573257496438799812162311375

r = 27879350651684890904379932074025120345051153878425154998302508662105071749243
s = 25794953212301227856184311444869449493787798218601311881180217027281849030507

cv   = Curve.get_curve('secp256k1')
pu_key = ECPublicKey(Point(x, y, cv))
sig = ecpy.ecdsa.encode_sig(r, s, 'RAW', 32)
signer = ECDSA(fmt='RAW')
msg = sha256(b'hello tss')
msg = msg.digest()
print(signer.verify(msg,sig,pu_key))

It is weird since with the parameters generated by the Alice library the verification fails, instead if I use parameters from a simple ecdsa signature it succeeds.
Is there something different that I should do when verifying a signature produced with threshold signatures?
Is there any processing done to the message or it is enough to convert "hello tss" to a byte array?

Thanks and sorry for the inconvenience

Observation.

What you expected to happen:
In schnorr.go, the challenge c is computed as H(G, V, R, α) instead of H(G, α, V, R)
as from protocol specification (Algorithm 29, pag. 15. This is not a vulnerability per se but we always suggest to closely match the specs.
Same inversion happens in Verify at line 197

Severity: Low

What happened:
In cl.go the function MulConst does not perform a validation of the correct form of
the ciphertexts as from Algorithm 23 of the protocol specs document.

Observation

What happened:
In polynomial.go the function NewPolynomial takes as input a slice of random elements and then all of them are reduced modulo fieldOrder. This behavior in this context is OK. However, it might be a good idea to include a comment warning the user that this function can introduce modulo bias if applied directly to slices that have not previously undergone rejection sampling. For example, the function RandomPolynomial does this correctly by sampling uniform slices from the
correct range.

Severity: Medium

Description and Impact Summary:
The function computeB fetches a pre-stored tuple comprising of a party’s identity and stored commitments to their precomputed nonces. The resulting string is supposed to be unique and can be used through the signature generation. However, we found two problems.
The first one is that in one case, only the x coordinate of one point is used, while in the other case only the y one is used:
The second one is that the corresponding fields are not fixed size and are just divided by a comma separator. When transforming this into a string, collisions can occur. For example, suppose that two point coordinates are represented as two byte-vectors of length 32 as:
[0x00 A1 ... A31] [B1 ... B32]
where B1 is a byte representation of a comma. Now, suppose to have two other points:
[A1 ... A31 B1] [0x00 B2 ... B32]
After being processed by the function, in both cases we end up with the same bytestring:
[ B1 A1 ... A31 B1 B1 ... B32]
therefore, subsequent collisions will occur.

Observation

What happened:
In hash.go it is enforced that the length of the salt is at least as that of the data to be
hashed. This seems overkill, a minimum bound on the salt size should be enough.

Severity: Low

Description and Impact Summary:

There are two modular reductions that are supposed to map to random elements of Z*, but since the output is not checked to be nonzero, there is a slight possibility that the result will end up in Z instead (zero element).
At a very minimum, this formally breaks the correctness guarantees of the protocol.

Severity: Low

What happened:
In matrix.go the function Transpose does not perform checks on the number of rows
and columns.
This might cause a huge memory allocation if called with large inputs.

@markya0616 @cychuang0924
I want to sign my TX in algorand with Alice ed25519, but I don't know how to get valid compressed publickey bytes from dkg output (only two big ints: X, y).

I use the following code to get it, but it doesn't seem right. They always fail in the signature verification.
pubkey := edwards.NewPublicKey(edwards.Edwards(), result.PublicKey.GetX(), result.PublicKey.GetY()) log.Info("dkg result", "publickey", hex.EncodeToString(pubkey.Serialize()), "Share", result.Share.String())

algorand doc: https://developer.algorand.org/zh-hans/docs/
my code: https://github.com/alexSmallWorld/alice-ed25519/tree/ed25519Example
run test: cd example && ./tidy.sh && ./build.sh && ./dkg.sh && ./algoTransfer/algoTransfer 0

thanks!

Severity: Low

What happened:
In utils.go the function HashProtos takes as input an array (slice) of arbitrary messages, packs them into a single string, feeds the string to Blake2 to get a hash, and
then reduces this hash modulo the field order to obtain a field element.
This function per se does not enforce uniformly distributed outputs, so this is not a
vulnerability per se here. However, as a result HashProtos is not uniform because
of the modulo reduction, and this is used in many other places in the code with this
purpose, for example as a random oracle implementation in the Fiat-Shamir euristics.
Although we believe this is a minor concern in terms of exploitability, at a very minimum
it breaks the cryptographic security proof.

Feature request

Possible to have 1 share key with multiple public key addresses?

According to Fast Multiparty Threshold ECDSA with Fast Trustless Setup,
"Our key sharing is compatible with BIP32 public derivations, and we leave it as future work to prove security in this setting."

Tss-ecdsa-cli seems to have support for HD keys
https://github.com/cryptochill/tss-ecdsa-cli

Severity: Low

What happened: