Open JFWooten4 opened 4 months ago
Transactions with extra signers are rejected for a number of reasons. ❌
Despite this reality, the present docs only lightly cover the extra signer case.
Without adequate documentation, the community may not fully understand the real-world implications of disallowing extra signers.
Flesh out the documentation for extra signers, possible including a new section in the docs.
Details should include traditional liability, distributed computation, and account privacy considerations. 👀
Ideally provide edge case examples for problematic examples, in code.[^some] [^some]: See, e.g., reaching quorum, config, and peers.
There seems to be lingering confusion in the community as to why transactions with too many signature should be and are rejected.
If we leave this undocumented, the network risks the introduction of proposals aimed at allowing unlimited signers, hurting scalabitlity. 📉
Might we contemplate where to place any new page detailing this material protocol design choice? 💭
Per Wayback, this used to be at https://developers.stellar.org/docs/glossary/transactions/#list-of-signatures
https://developers.stellar.org/docs/glossary/transactions/#list-of-signatures
JFWooten4
commented
2 weeks ago
What problem does your feature solve?
Transactions with extra signers are rejected for a number of reasons. ❌
Despite this reality, the present docs only lightly cover the extra signer case.
Without adequate documentation, the community may not fully understand the real-world implications of disallowing extra signers.
What would you like to see? 🔍
Flesh out the documentation for extra signers, possible including a new section in the docs.
Details should include traditional liability, distributed computation, and account privacy considerations. 👀
Ideally provide edge case examples for problematic examples, in code.[^some] [^some]: See, e.g., reaching quorum, config, and peers.
What alternatives are there?
There seems to be lingering confusion in the community as to why transactions with too many signature should be and are rejected.
If we leave this undocumented, the network risks the introduction of proposals aimed at allowing unlimited signers, hurting scalabitlity. 📉
Might we contemplate where to place any new page detailing this material protocol design choice? 💭