To separate the wallets (mobile users) from the nodes, I think I'll change it so that the treasury is one multi-sig address. Each private key is protected and backed up by a shared secret algorithm. I explain in detail here:
i woud not recommend a single address multisig requiring 10of15
because 10 can collude and share out the value associated with all 15.. meaning 5 just see their balance disapear and then have those 5 liable to all of its sub-users of their 5 branches
its the typical exchange 'we got haxxed' excuse
..
try a new scheme. 15 addresses for 15 nodes 'treasury' but were its not a 10 of 15 but instead:
a treasury block of 15 addresses/UTXO updates
each address assigned to a node manager. where the 'secret' is a build up of the specific manager plus 10 others.
(m1)+10of14 (still 15 but but the special contingent 1 is the specific manager assigned that address)
that way the manager cant raid his own pot without other authorisation. but now nor can other managers raid the pot without him
users then are either randomly assigned to a manager or choose their favourite manager due to what services they are associated with. and each manager then 'controls' its own userbase.
much like brank branches
also you can have users in the offchain. have their addresses be multisig. but also contingent on the user+plus their manager+9other treasurers.. all cross signing off on the payment
(u)+(m1)+9of14
that way users have some control and its not all managed/abused by a manager or collusion of managers
a payment wont be valid unless a users sig is part of the deal
in practice this is hard because most users dont read raw tx data to check if their key is put into the contingent position or just part of the regular collective 14.
but you can easily code some checker for that
I really like the idea of having the users work together with nodes on the network in order to deposit into or withdraw from the treasury. I might be misreading your post but it sounds like the treasury is rather dependent on these 15 manager nodes. How about each deposit into the network has its own multi-sig address? The address can formed like this:
1. The user generates a private key using a shared secret algorithm.
2. The nodes on the network generate a private key:
a. Each node creates a random shared secret
b. The nodes elect a random node
c. The elected node puts together 2/3 of the shared secrets to generate a new secret. This will be the network's private key.
3. The elected node and the user both create a public key from their respective private keys
4. The multi-sig address is formed from the public keys and propagated through the network
5. The user sends a shared secret to each node online at the time. It would take 2/3 of the nodes online at the time to reconstruct the private key.
At the end of this process each node should have the address, their own shared secret, and a shared secret from the user. All the multi-sig addresses generated this way are the "treasury". If someone needs to transfer funds outside the network, the nodes can coordinate to recover bitcoin in these addresses. The private keys are backed up on the network without any one node knowing all two keys required to unlock the address. Since the treasury is spread out across different addresses, there isn't a single point of failure. If one address in compromised, the other addresses are likely to be safe.
A malicious actor could take funds out of an address in two ways:
1. Control 2/3 of the network at the time the address was made
2. Control the user and the randomly elected node at the time the address was made
First one could be deterred through normal anti-Sybil attack countermeasures like staking or PoW. The second one is tougher. Sybil attack countermeasures can help keep the bad actor from spamming nodes. The randomness makes it less likely the bad nodes get picked the larger the network becomes. I'm having trouble thinking of other ways around this. Another thing is that I would be worried about how much bandwidth a protocol like this could take up.
