<stellar-slack>
<lab> monsieurnicolas: i have a question, how to get current threshholds setting of an account?
<stellar-slack>
<monsieurnicolas> you just need to load the AccountEntry for that account
<stellar-slack>
<lab> i mean outside stellar-core
<stellar-slack>
<monsieurnicolas> Horizon has an API for that
<stellar-slack>
<monsieurnicolas> it's just pulling straight off the accounts table
<stellar-slack>
<lab> got it. thanks for help.
de_henne_ has joined #stellar-dev
de_henne has quit [Ping timeout: 264 seconds]
pixelbeat has joined #stellar-dev
sv-logger has quit [Remote host closed the connection]
sv-logger has joined #stellar-dev
TheSeven has quit [Disconnected by services]
[7] has joined #stellar-dev
pixelbeat has quit [Ping timeout: 240 seconds]
de_henne_ has quit [Remote host closed the connection]
de_henne has joined #stellar-dev
pixelbeat has joined #stellar-dev
<stellar-slack>
<sacarlson> ok I have my multi-sign API server now almost done. I'm just short one last function
<stellar-slack>
<sacarlson> to convert a base64 envelope back into binary format
<stellar-slack>
<sacarlson> I have the function to convert binary envelope in b64 but not back again
<stellar-slack>
<sacarlson> without it I'm stuck again
<stellar-slack>
<sacarlson> seems I need more than just convert base64 as I thought I found it
<stellar-slack>
<sacarlson> reverse of this b64 = envelope.to_xdr(:base64) ; so need the reverse of to_xdr also
<stellar-slack>
<dzham> var buffer = new Buffer(req.body.txenv, 'base64'); var envelope = stellar.xdr.TransactionEnvelope.fromXDR(buffer); var tx = new stellar.Transaction(envelope);
<stellar-slack>
<dzham> In javascript
<stellar-slack>
<sacarlson> cool with that I might be able to do a search to find it's match in ruby
<stellar-slack>
<sacarlson> might have found it tr = Stellar::TransactionResult.from_xdr bytes
dobson has quit [Ping timeout: 240 seconds]
dobson has joined #stellar-dev
<stellar-slack>
<dzham> Is that for receiving an envelope to sign, or for collecting signed envelopes?
<stellar-slack>
<dzham> (for collecting signed envelopes all you need is the signatures. you can add them manually to the envelope before submitting the envelope to the network)
<stellar-slack>
<sacarlson> it recieves and collects mutli-sign accounts and transactions, the transactions are available for others to pickup and sign. with the server detects it has enuf sigs for the transaction it submits it
<stellar-slack>
<dzham> How complicated was that? I haven’t done that yet. You check the source accounts in the envelope, check the signers+weights for those addresses, check which sigs you have, and if you fulfill the signature requirements?
<stellar-slack>
<sacarlson> the transactions are ided with a tx_code that is a 10 letter hash of the master tx so that users know what tx they are looking for and want to sign
<stellar-slack>
<dzham> Oh, I’m just thinking about how to know when it’s all signed
<stellar-slack>
<sacarlson> yes but presently I don't look inside the tx, I have the user send me the specs to the server at this time
<stellar-slack>
<dzham> ok, ok
<stellar-slack>
<buhrmi> why do you test locally if it has enough signatures? you could just submit it to the network to check....
<stellar-slack>
<buhrmi> if it goes through -> good, if it gets error -> not good
<stellar-slack>
<dzham> It would be cool to have in the ui.. 5/7 signatures collected. Two more needed. Or a progress bar
<stellar-slack>
<buhrmi> wow what kind of transaction are we talking here
<stellar-slack>
<buhrmi> must be super important :)
<stellar-slack>
<sacarlson> I'm not sure that's just how I did it. the user had to have the info to setup the account so this way the account can be created and processed on the server side with nothing but curl transactions needed on the user side
<stellar-slack>
<dzham> @buhrmi: Haha, just thinking ahead :)
<stellar-slack>
<buhrmi> the holy transaction! everybody sign!
<stellar-slack>
<buhrmi> hehe
<stellar-slack>
<sacarlson> it checks it like this:
<stellar-slack>
<sacarlson> it's all done with json transactions
<stellar-slack>
<sacarlson> the only key needed to sign is the master but he can be set to have no weight so it has no security problems even with unencrypted curl transactions
<stellar-slack>
<dzham> @burhmi: seven sigs might have been a bit extreme, but I don’t think six would be that exeggerated
<stellar-slack>
<sacarlson> I made a function to setup a basic account: setup_multi_sig_acc_hash(master_pair,*signers)
<stellar-slack>
<sacarlson> my game runs with 10 players
<stellar-slack>
<dzham> There you go!
<stellar-slack>
<sacarlson> I'm not sure what the limits would be of how many signers
<stellar-slack>
<dzham> 20 sign per transaction envelope is the maximum, I think?
<stellar-slack>
<sacarlson> it auto calculates basic weights so all have to sign by default but you can tweek the hash to whatever you want
<stellar-slack>
<buhrmi> let's make a multi sig acc with 7 billion signers, and a network with only one transaction submitted by this account.
<stellar-slack>
<buhrmi> the one transaction
<stellar-slack>
<buhrmi> wonder what's inside
<stellar-slack>
<sacarlson> I should be able to publish the mostly completed test version by tomaro or the next
<stellar-slack>
<dzham> OK, yeah. 20 is the max. Per account, and per tx envelope
<stellar-slack>
<buhrmi> sounds arbitrary
<stellar-slack>
<sacarlson> cool 10's all I need so I'm set
<stellar-slack>
<sacarlson> you could I guess just chain many accounts so you could have more signers
<stellar-slack>
<dzham> you could maybe chain transactions together.. make a nice little tree
<stellar-slack>
<sacarlson> but at this point it still centralized but the protocol I guess could be used for p2p at some point
<stellar-slack>
<sacarlson> I presently just setup a listening port on 9494 that listens for json commands
dobson has quit [Ping timeout: 240 seconds]
dobson has joined #stellar-dev
pixelbeat has quit [Ping timeout: 264 seconds]
pixelbeat has joined #stellar-dev
<stellar-slack>
<monsieurnicolas> re: limit on the number of signatures per transaction. Yeah completely arbitrary. It's easier to raise the limit in the future than to lower it when we see how people abuse the system. I tend to think that people are always super creative when it comes to breaking systems :)
<stellar-slack>
<buhrmi> as backoffice-tooling developer as my day job... i can confirm
<stellar-slack>
<buhrmi> "I just broke the systen".. "what did you do?" ... "I just gave it totally unrealistic amounts of artificial load to see if it can handle it" .. "...."
<stellar-slack>
<buhrmi> WELL DONT DO THAT
pixelbeat has quit [Ping timeout: 244 seconds]
DomKM has joined #stellar-dev
pixelbeat has joined #stellar-dev
stellar-slack has quit [Remote host closed the connection]
<stellar-slack>
<scott> The various libraries (except go-stellar-base), horizon and horizon importer have had their master branches updated to reflect this change (which should land on stellar-core master soon)
<stellar-slack>
<scott> We’ve also pushed ruby-stellar-base 0.4.0 to rubygems to reflect this change, and js-stellar-base 0.4.0 will be landing shortly
<stellar-slack>
<dzham> :(
<stellar-slack>
<dzham> Wouldn’t replay attacks already be prevented by sequence numbers?
<stellar-slack>
<dzham> So you’d have to have the same address + the same sequence number on both networks for it to work?
<stellar-slack>
<monsieurnicolas> yes, you'd just have to wait for the account to be "ripe" for the exploit by watching its sequence number against a database of signed tx for that account.
<stellar-slack>
<dzham> OK, OK, now I’ve read the changes… So you’re basically just changing the signature hash to what it was like in stellard. I just assumed that was the way it was already..
<stellar-slack>
<monsieurnicolas> when it comes to attacks, you normally want to have a completely asymmetric complexity between what a good guy does vs what an attacker needs to do
<stellar-slack>
<monsieurnicolas> I don't think there is such a concept in stellard - the assumption is that people will pick different secrets for different networks
<stellar-slack>
<monsieurnicolas> (or at least it was not configured if it existed)
<stellar-slack>
<dzham> The signature hash is prefixed base on the network.. .STX/0 (live) or stx/0 (test)
<stellar-slack>
<dzham> So this is just a generalization