Hey Natanael, Thanks for your response.
> It's the chain of signatures always published in an accessible way so that
> the original members can't "doublespend" and claim to be the task group?
> Otherwise the blockchain approach is useful for you.
>
I think the naive solution I proposed in my first message is more efficient
than using Bitcoin, because it does not involve proof of work or flooding
stuff.
Shortly: Whenever a person is added to the band, all the members sign on
the new list. Whenever a member leaves the band,
all the members sign on the new list. The band members keep the signatures
forever, so they can always prove they where formed originally
from the original band S.
Example:
If the original band, band_0 = {a_0,a_1,a_2,a_3}, and a new member (a_4)
joins, we get a new band {a_1,a_2,a_3,a_4}.
If we denote the new list as band_1 := (a_0, a_1,a_2,a_3,a_4) then we need
the following signatures to prove the change:
sign[a_0](band_1), sign[a_1](band_1), sign[a_2](band_1), sign[a_3](band_1)
If the member a_1 now leaves the band, we denote band_2 =
(a_0,a_2,a_3,a_4), and we need the following signatures to prove the change:
sign[a_0](band_2), sign[a_2](band_2), sign[a_3](band_2), sign[a_4](band_2)
(Note that we might not be able to get a_1's signature, because maybe he
just failed somehow).
So far, after those two changes, we have to carry about 8 signatures.
If someone asks the group to prove that they have a majority of correct
nodes, they can just prove their current
identities, and send the 8 signatures.
(I can probably get away with less than 8 signatures, but the asymptotic
nature of the amount of signatures needed doesn't really change).
The band S doesn't publish the signatures. They only show the signatures
whenever I ask them.
The group setting is also solved as-is thanks to both the multisignature
> support (m-of-n for up to 15 people), and thanks to ECDSA threshold group
> signatures if you prefer these (I'm assuming they also don't limit you to
> 15 members).
>
Using a multisignature scheme I can probably get much shorter signatures,
which is cool.
I will still have to remember the identities of all the signers, and the
set of signatures to be remembered grows linearly with respect to time.
Assuming that I use some kind of Threshold signature scheme, how can I
transfer the secret parts to the next members in the band, so that parts of
the secret don't leak to previous members?
Most of what I read about threshold signatures assumes that some that some
trusted dealer deals the secret parts to the participants.
How can I move the secret parts to the new band without a trusted dealer?
Someone in this thread has mentioned Shamir secret sharing. Considering
this idea,
How can I avoid the possibility that some set of corrupt ex-band members
will gather and combine their secret parts?
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
