06:31 <stellar-slack> <buhrmi> "understand the rationale" implies that there exists such a thing

08:30 <stellar-slack> <graydon> 3 reasons: XDR has a canonical bit-level encoding, is an internet standard, and supports disjoint unions (sum types).

08:34 <stellar-slack> <graydon> I'm not sure about the pattern you're noting. I mean I see it I just don't know why it's an empty union rather than an enum itself. possibly just for uniformity with the treatment of other (non-empty) result-code-keyed unions.

08:36 <stellar-slack> <graydon> discriminant unions do not always save memory; the representation in memory is up to the programming language. the important thing they do is exclude cases. in an encoding without disjoint unions, you have to put all fields for all variants in a structure and guess (or leave to documentation) which combinations of fields can meaningfully be active simultaneously, and what the combinations mean. with disjoint

08:36 <stellar-slack> cases explicitly, excluding the illegal ones.

08:55 <stellar-slack> <sacarlson> I just published my multi sign websocket server system with examples https://github.com/sacarlson/stellar_utility/tree/master/multi-sign-websocket. original websocket idea from dzham

08:57 <stellar-slack> <sacarlson> it still needs at least one more added item that would be to verify an incomeing signature to be valid before publishing it to the server.

10:46 <stellar-slack> <sacarlson> with my experiments with sig = key_pair.sign("hello world") and keypair.verify(sig,"hello world") I get the basics of signature verification. but how can I use this to verify that a transaction was signed by a keypair? wanted function verify_signature(envelope_b64, account_address) or just verify_signature(envelope_b64)

11:16 <stellar-slack> <dzham> well, you *would* need the public key… verify_signature() would just take the hash of the txenv, and use that as the signed message

11:18 <stellar-slack> <sacarlson> I can experiment with that and see what comes of it

11:20 <stellar-slack> <sacarlson> what i'm presently expermenting with is pulling the tx and signature from the envelope to try to find what is needed to verify them sigs = envelope.signatures sig = sigs[0].signature

11:23 <stellar-slack> <sacarlson> I'm not sure but it looks that this Digest::SHA256.digest(string) wants a string as input

11:24 <stellar-slack> <sacarlson> the tx is a complicated structure

11:28 <stellar-slack> <sacarlson> I have tools that can pull the pulblic key from the tx and even convert it to an address and then to a keypair with no secret seed. but I fail to go any farther

11:41 <stellar-slack> <sacarlson> I would need to know what method of converting the tx into a string is required to do the SHA256 fucntion on

11:43 <stellar-slack> <dzham> https://github.com/stellar/js-stellar-base/blob/master/src/transaction.js#L56-L77

11:46 <stellar-slack> <sacarlson> wow that signatureBase() function is complicated wonder if that already exists in ruby-stellar-base?

11:47 <stellar-slack> <sacarlson> but that looks to be the missing part of the puzzle

11:50 <stellar-slack> <sacarlson> cool I think I found something in ruby-stellar-base it

11:50 <stellar-slack> <dzham> signaturebase just returns hash(network passphrase) + hash(txenv in xdr format)

11:51 <stellar-slack> <sacarlson> yes so this already does all that so now I should be able to make my function or at least try

12:34 <stellar-slack> <sacarlson> I got it

12:35 <stellar-slack> <sacarlson> thanks dzham you got me looking in the right direction

13:25 <stellar-slack> <dzham> @sacarlson: np!