Stellar have potential to cover more wider use cases than payment network, such as stakes, assets which can represent weights of multisig of massive crowds and send dividends. It looks not possbile with current stellar network implementation.

Can you describe more what you mean? It might actually be possible.

    You can send dividends quite easily, but you have to do it manually. I.e., there's no dividend operation, so you have to write the code to make individual payments.

    Multi-sig for massive crowds is a bit tougher. Currently there's a limit of twenty signers per account, and twenty signers per transaction envelope.

    With hash(tx), that's being rolled out as we speak, you can make a transaction be dependent on a previous transaction, that way you could get more signatures.

    A lot more complicated, but more scalable, is a threshold signature scheme based on Shamir secret sharing.

      jed
      For example,

      I issue 10000 asset as stocks of accompany address and set a voting threshold portion 0.5. Alice has 3000 . Bob has 2000. Charlie has 4000. David has 1000. They can vote to send other assets, like USD, from accompany address or make a smart contract run if total signing weights exceed the settled threshold.
      more specifically, if Alice and Charlie vote to agree a smart contract, their total signing weights (3000 + 4000 = 7000) exceeds settled threshold (0.5 * 10000 = 5000), this will let the smart contract run.

          dzham
          I wonder whether it's possible to let signing weights reference to the quantity of specific asset owned. Like how stakes work for voting

            t3476

            The maximum threshold is 256, so that limits you in a way.
            Alice: 30, Bob: 20, Charlie: 40, David: 10, with a threshold of 50 wold work

                dzham But when the quantity of stakes owned change, the weights should change simultaneously. I mean assets that represent signing weights.

                    t3476

                    I get what you mean, it's just something that's not possible to do the way you're thinking.
                    Assets don't have signers, accounts do, transactions do.

                      There are some cumbersome ways to do this now. One of the things in the back of my mind is how to do some voting system like this efficiently.

                        jed Could you share more technical details about that voting system?

                          What you're looking for is a way to have asset holders sign transactions for the asset issuer, with weights that depend on the balance of each holder, with a voting threshold, right?

                          I'm not sure what Jed is hinting at, but there are probably ways you can use hash(tx) in combination with a voting asset, where you set up the asset issuer with a hash(tx) signer, using a transaction like tx = send THRESHOLD number of VOTES from account "YES" to issuer.

                          That way you have one signature instead of one per asset holder.

                            dzham That's what I actully mean, but this solution looks the issuer can still execute the arbitrary operation rather than permited operation after receiving enought votes. Am I wrong?
                            I think extending stellar with voting system which could permit operations makes it becomes fund raising and stock system rather than just payment network.

                              How about three "tally bots" to tally the votes for the txns and sign for the account?
                              Basically a "consensus algorithm" in miniature; until the three bots agree, they don't sign.

                              • The three bots would create a private key for each Account they sign for and provide the signing hash.
                              • An Account has its Voting Assets and thresholds marked on its Managed Data.

                              It would be best if the bots received txns already authorized by the "Holding Account" (can someone explain how this might be done?) so it doesn't have to compute "Account Approval" on its own (though it can do it if needed).

                              Lastly, as part of the submitted txn each bot generates a new signing key for the next txn. It appends operations to the txn to add its new key and remove its existing key to the proposed txn.

                              Once all three bots have appended the operations to change to the signing keys along on the signed txn; the txn gets submitted to the system.