<stellar-slack>
<sacarlson> so what commit will we be running now on the testnet stellar-core?
pixelbeat has quit [Ping timeout: 260 seconds]
<stellar-slack>
<jed> I'm going to move testnet to master
<stellar-slack>
<jed> ok testnet should be back in action
<stellar-slack>
<sacarlson> from my view at this time that would make stellar-core on horizon running 28bcca5b669e17fe59f1fea9b596cd5ff399a4e6
<stellar-slack>
<dzham> @sacarlson: I’m doing contracts in that way right now. Not fully scripted, but more complicated than the “simple contracts” from @jed
<stellar-slack>
<dzham> What do you mean by “account timed lock”? There’s a time bound already on a transaction envelope, so you can define when it will be valid. (before and/or after a certain timestamp)
<stellar-slack>
<sacarlson> I think I figured out a way to lock an account without having to make any changes. locking an account would mean that the master user can't access his funds for some window of time
<stellar-slack>
<sacarlson> I had originaly planed to have the master user lock his own account with a time transaction that would unlock it but that can't work as the transaction will never be valid while the account is locked
<stellar-slack>
<dzham> If it’s non-XLM you can just freeze the funds, that way the only thing the user can do with the funds is send it back to the issuer
<stellar-slack>
<dzham> so a temporary freeze might work?
<stellar-slack>
<sacarlson> but by having the witness account also provide a signature to unlock the account would still work
<stellar-slack>
<sacarlson> you would just require both signatures the one from the witness account and the master sig to unlock it
<stellar-slack>
<sacarlson> this should lock all the account including xlm
<stellar-slack>
<dzham> Ah, ok.. fiddle with the medium threshold, maybe?
<stellar-slack>
<sacarlson> medium and high both set to 2
<stellar-slack>
<sacarlson> do transaction sequences have to run in order?
<stellar-slack>
<dzham> yes
<stellar-slack>
<dzham> but you can always use multi-sign to get around that, add a dummy account as a signer, and have the dummy account be the main source account of the tex envelope
<stellar-slack>
<sacarlson> oh ya but I thought I had to have to witness create the account as they are the one that add the offline trust
<stellar-slack>
<dzham> but in that case, the witnesses always create the transactions in order, right?
<stellar-slack>
<dzham> that’s what I do at least
<stellar-slack>
<sacarlson> I've never played with the time lock yet so I best play with it before I speak more about it
<stellar-slack>
<sacarlson> the witness may create transactions for several clients with different time lock windows that I assume the transaction can't be published until it's window time makes it valid?
<stellar-slack>
<sacarlson> or does the transaction just get published and sit not moving funds until the strike a valid time?
<stellar-slack>
<dzham> I think it just gets rejected
<stellar-slack>
<dzham> you’ll have to keep track of it yourself, when it’s okay to publish it
<stellar-slack>
<sacarlson> ya that's what I think it's just rejected
<stellar-slack>
<sacarlson> so you can still create other transactions on that account then that aren't rejected and still pass this transaction later?
<stellar-slack>
<sacarlson> if so then you don't have to run transactions in any order
<stellar-slack>
<sacarlson> as long as the sequence number is biger than the last and not used yet?
<stellar-slack>
<sacarlson> if not then all that is required to unvalidate any time locked transaction would be create a new transaction on that account
<stellar-slack>
<sacarlson> I think your above statement already fixes all this as you said just use the locked dummy accounts sequence number
<stellar-slack>
<dzham> I think the sequence numbers still have to be consecutive, like in the old version
<stellar-slack>
<sacarlson> ya me too
<stellar-slack>
<sacarlson> so lets play with time locked transactions today then. what is the format of the start and stop time? utc integer seconds from 19XX?
<stellar-slack>
<sacarlson> show me an example transaction in base64 that has a lock window that I can take apart to look at
<stellar-slack>
<dzham> unix timestamps if I’m not mistaken
<stellar-slack>
<sacarlson> ya I would think that would be what I would expect. but an example would be cool to see.
<stellar-slack>
<sacarlson> any examples available?
<stellar-slack>
<sacarlson> if not I'll trial and error some until it works and publish it here
<stellar-slack>
<dzham> I don’t remember seeing any examples
<stellar-slack>
<dzham> I just found it looking through the xdr
<stellar-slack>
<sacarlson> cool
<stellar-slack>
<sacarlson> link?
<stellar-slack>
<sacarlson> oh maybe you mean you found the format?
<stellar-slack>
<sacarlson> ya can't be that hard, I'll make one
<stellar-slack>
<dzham> oh, yeah, gotta be future proof… 64bit timestamps. what a good way to waste 32 bits
<stellar-slack>
<sacarlson> maybe so it can also be valid for time travelers. does it go negitive so we can time travel and see the dinosores?
<stellar-slack>
<sacarlson> U unsighed
<stellar-slack>
<sacarlson> darn
de_henne_ has joined #stellar-dev
de_henne has quit [Ping timeout: 264 seconds]
<stellar-slack>
<sacarlson> seems the new version of stellar-core will require a full reset as I now get this error at start
<stellar-slack>
<sacarlson> I'll try full reset to see if that fixes this
<stellar-slack>
<jed> yes if you wait till tomorrow you wont have to reset
<stellar-slack>
<sacarlson> too late already running reset now
TheSeven has quit [Disconnected by services]
[7] has joined #stellar-dev
bit2017 has quit [Ping timeout: 244 seconds]
<stellar-slack>
<sacarlson> I think I've created my first timebound transaction. not tested yet b64: AAAAAD1O39Zz2qUNUKLDH6BnGEEFOs8+CC/aVz5CUmCj3euQAAAAZAAACtMAAAABAAAAAAAAAAAAAAABAAAAAAAAAAUAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAADnRlc3QudGltZWJvbmRzAAAAAAAAAAAAAAAAAAGj3euQAAAAQIwETnShthewLe/pZFrSYpC0tw1bc5Kf5T2d2OrFUxBDJhz+WeBKpfaym6r2pp8DZTE9jUf2Q174355ArMnWvAg=
<stellar-slack>
<sacarlson> it expires in 10,000 seconds
<stellar-slack>
<sacarlson> I'll let it expire and see if it errors out
<stellar-slack>
<sacarlson> opps 2.7 hours that too long to wait ha ha
<stellar-slack>
<sacarlson> that last attempt at timebound was wrong I now have a new method that I think should work
<stellar-slack>
<sacarlson> to add a timebound to any tx I created this:
<stellar-slack>
<sacarlson> I've also added to my view_envelope(b64) the ability to look inside the envelope and see what the timebounds are set to
<stellar-slack>
<sacarlson> it works! Stellar::TransactionResultCode.tx_too_late(-3) result send_tx Stellar::TransactionResultCode.tx_too_late(-3)
<stellar-slack>
<sacarlson> not sure about the too early yet as it's not tested
<stellar-slack>
<dzham> I’m not sure if you need both min_time and max_time
<stellar-slack>
<sacarlson> well I wanted a way to set both, what should they default to nil?
<stellar-slack>
<sacarlson> and if default I would assume no max would be forever and no min would be the same as Time.now.to_i
<stellar-slack>
<dzham> oh, never mind. it’s both or none
<stellar-slack>
<sacarlson> no I think you could set max = nil and it will be forever I'll try it
<stellar-slack>
<sacarlson> there now we have forever
nivah has joined #stellar-dev
<stellar-slack>
<sacarlson> I guess that forever idea didn't work /home/sacarlson/.bundle/gems/xdr-0.1.0/lib/xdr/unsigned_hyper.rb:6:in `write': val is not Integer (XDR::WriteError)
<stellar-slack>
<sacarlson> so I guess forever will just be 100 years or Time.now.to_i + 3.154e+9
de_henne_ has quit [Remote host closed the connection]
de_henne has joined #stellar-dev
de_henne has quit [Read error: Connection reset by peer]
de_henne has joined #stellar-dev
<stellar-slack>
<sacarlson> to early also works result send_tx Stellar::TransactionResultCode.tx_too_early(-2)
<stellar-slack>
<buhrmi> did somebody change something
<stellar-slack>
<sacarlson> they are running a new stellar-core today
<stellar-slack>
<sacarlson> on testnet
<stellar-slack>
<buhrmi> a new new stellar core?
<stellar-slack>
<sacarlson> a new version update
dne has joined #stellar-dev
jbenet has quit [Ping timeout: 246 seconds]
olinkl has quit [Read error: Connection reset by peer]
``rawr has quit [Ping timeout: 246 seconds]
DomKM has quit [Ping timeout: 268 seconds]
olinkl has joined #stellar-dev
jbenet has joined #stellar-dev
jbenet has quit [Remote host closed the connection]
olinkl has quit [Remote host closed the connection]
jbenet has joined #stellar-dev
``rawr has joined #stellar-dev
DomKM has joined #stellar-dev
<stellar-slack>
<sacarlson> I now have the make_witness_hash(witness_keypair,account,asset="",issuer="") function tested and working. I'm now working on the check_witness_hash(witness_account,hash). when both are working they will be added to the multi-sign-server to make it a automated witness
<stellar-slack>
<sacarlson> with this and the timebounds function I think we might be able to make a offline transaction posible
olinkl has joined #stellar-dev
pixelbeat has joined #stellar-dev
<stellar-slack>
<dzham> depends on what you mean by offline transactions, you could also simply use multi-sig dummy accounts like mentioned earlier
<stellar-slack>
<sacarlson> can't I spend a dummy account if it's not locked?
<stellar-slack>
<dzham> the dummy account doesn’t have any funds, but sure, I get your point
<stellar-slack>
<sacarlson> this allow you to prove to someone that has no internet that there is funds in a locked account
<stellar-slack>
<sacarlson> that's what offline means
<stellar-slack>
<dzham> I’ll have to check in with what you’re doing later, still finishing up things of my own. plus it’s Friday evening -> time with the family
<stellar-slack>
<sacarlson> wow friday already
<stellar-slack>
<sacarlson> looks like the server is working this is the output of action = "make_witness"
``rawr has quit [Quit: Connection closed for inactivity]
DomKM has quit [Quit: Connection closed for inactivity]
nivah has quit [Ping timeout: 246 seconds]
pixelbeat has quit [Ping timeout: 250 seconds]
pixelbeat has joined #stellar-dev
stellar-slack has quit [Remote host closed the connection]
stellar-slack has joined #stellar-dev
pixelbeat has quit [Ping timeout: 265 seconds]
pixelbeat has joined #stellar-dev
<stellar-slack>
<jed> stress test of testnet is in effect right now. lmk if you see issues
<stellar-slack>
<scott> something is busted in horizon-importer… shutting it down on testnet while I investigate
<stellar-slack>
<scott> :facepalm: I know the cause… it’ll be fixed in about 15 minutes
pixelbeat has quit [Quit: Leaving]
pixelbeat has joined #stellar-dev
pixelbeat has quit [Ping timeout: 240 seconds]
<stellar-slack>
<mason> Thanks scott. Hey guys! Working on my super simple stellar wallet. Will there be usernames on the new network?
<stellar-slack>
<scott> @mason: The federation system (which is what gave people names) is a separate system from the actual network (which only deals with addresses). In that sense, yes, the new network will still have usernames
<stellar-slack>
<scott> We’ve improved things in the new network a bit by adding a “home domain” attribute that an account holder can set. This home domain would be the federation server to query for username information for a given account.
<stellar-slack>
<scott> in other words, the “home domain” helps for the scenario we call “Reverse federation”, mapping from address to username
<stellar-slack>
<mason> Will "forward federation(?)" work? ie masonforest -> my_stellar_address. Also feel free to point me to docs on this or I'm happy to write some :)
<stellar-slack>
<scott> but, yes, forward federation still exists and is exactly the same
<stellar-slack>
<scott> it’s worth noting… The stellar client at http://launch.stellar.org|launch.stellar.org uses a trick for federation. A name like “scott” is actually expanded to “mailto:scott@stellar.org|scott@stellar.org” for the purposes of federation.
<stellar-slack>
<scott> sorry, “scott*http://stellar.org|stellar.org”, not mailto:scott@stellar.org|scott@stellar.org… I forgot we made that change
<stellar-slack>
<irisli> hey @scott. is there a way to know how many operations a user has (that have affected them)?
<stellar-slack>
<scott> what do you mean by “affected them”?
<stellar-slack>
<irisli> "affected them"like the results in the "operations-for-account" endpoint. But the bigger question i would like to ask is if there is a way to do pagination for results
<stellar-slack>
<scott> yes, of course
<stellar-slack>
<irisli> and knowing how many pages there are
<stellar-slack>
<scott> paging in horizon isn’t really organized into pages
<stellar-slack>
<irisli> the operations was just an example of the question about paging
<stellar-slack>
<irisli> hm, so then is there a easy way to say "i just want transactions for the month of March"?
<stellar-slack>
<scott> no
<stellar-slack>
<scott> the way to do that would be to find the first ledger of the month, the last ledger of the month, and record their `paging_token` attributes… then start paging through the transactions collection using the first ledgers paging token as the initial cursor, and quitting when you see a transaction whose paging_token is greater than that of the last ledger in the month
<stellar-slack>
<scott> The other route: run a local horizon instance and query it’s history db directly. Much more fexibility
<stellar-slack>
<mason> sorry was grabbing coffee :walking: . Back now. Thanks for the info on federation! Is the plan to eventually add the federation stuff into horizon or will it be a seprate service?
<stellar-slack>
<scott> It’s possible… I could see building a “federation proxy” into horizon that handles the process of looking up a domain’s stellar.txt and making a federation call on behalf of the client. While I imagine that will be low priority for us at http://Stellar.org|Stellar.org, I’d be happy to discuss a design and accept a PR with it.
<stellar-slack>
<scott> At the very least, we will be building federation capabilities into our client libraries
<stellar-slack>
<mason> cool cool
<stellar-slack>
<mason> yeah, I think as soon as "regular people" see a bitcoin address they get scared away. This is a neat solution to that
nivah has joined #stellar-dev
<stellar-slack>
<scott> yeah, I agree. hiding the addresses makes for a nicer user experience. Although you then have to contend with the federation server lying to you… for example, if someone compromises the federation server, they could respond with a address controlled by the hacker.
<stellar-slack>
<scott> I imagine that clients should build some sort of system that minimizes this risk, either with some sort of memory or perhaps a visual representation of a user’s address to highlight if it changes
<stellar-slack>
<scott> For example, our client tells you the address after we look it up
nivah has quit [Ping timeout: 250 seconds]
<stellar-slack>
<mason> yeah, could you use SCP for registering names? Kinda like how onename uses a blockchain to prove names haven't changed?
<stellar-slack>
<scott> Certainly it’s possible, but it was a conscious decision to exclude it. The smaller the protocol, the easier to implement, and we feel that federation is best left outside (with the exception of the home domain attribute that makes reverse federation feasible)
<stellar-slack>
<scott> I think there would be many unintended side effects to include some notion of usernames in the core protocol. For example, now people would be creating accounts just to squat on usernames.
<stellar-slack>
<mason> Gotchya. Yeah that makes sense