<stellar-slack>
<eno> Do we have a SGD gateway in testnet?
<coinpip>
And it doesn't work. I getting error tecPATH_PARTIAL Path could not send full amount.
<coinpip>
Yes I have. This is gateway for SGD gDfapfG5hDHuYkbVpugtupkGYVTKXwd59r
<coinpip>
I sending from g4e5v2ERpKvdBZrchn6DrWUtvezkXsu5wo SGD to gJ3e65GzqERgeeS5oXsv8NGfdZWzm93ej6 MYR . This is marketmaker gfQPtvgmavftERtEgYgt4VcjGTtfMut9EM to make SGD to MYR transaction happen
<coinpip>
This gateway gsQuUKcxM68nEX9tKR71UH5hZXwrvT2mpS for MYR
<stellar-slack>
<eno> really cool
<stellar-slack>
<dzham> have you tried without source_currencies?
<stellar-slack>
<eno> Houston we have a problem
<coinpip>
Without source_currencies it doesn't show any path
<stellar-slack>
<dzham> I’m just using source_account, destination_account and destination_amount in my static_path_find
<stellar-slack>
<dzham> mkay
<coinpip>
This is result without source_currencies
<coinpip>
I just did it. And It doesn't show any paths at all
<stellar-slack>
<sunny-g> Quick question: what are the explicit purposes and functionality of the AUTH_REQUIRED_FLAG and AUTH_REVOCABLE_FLAGs? Or better yet, where is this info documented so I can find out myself (aside from the source code)?
pixelb has joined #stellar-dev
stellar-slack has quit [Remote host closed the connection]
de_henne has quit [Read error: Connection reset by peer]
de_henne has joined #stellar-dev
pixelbeat has joined #stellar-dev
pixelb has quit [Ping timeout: 255 seconds]
<stellar-slack>
<jed> ok testnet is rolling along again
<stellar-slack>
<jed> scott ^
<stellar-slack>
<scott> cool. thanks!
koolhead17 has quit [Remote host closed the connection]
skeuomorf has quit [Ping timeout: 246 seconds]
skeuomorf has joined #stellar-dev
edubai_ has quit [Quit: Connection closed for inactivity]
de_henne has quit [Ping timeout: 264 seconds]
skeuomorf has quit [Ping timeout: 264 seconds]
<stellar-slack>
<monsieurnicolas> @sunny-g : those are issuer flags. AUTH_REQUIRED_FLAG requires accounts to be authorized by the issuer to do any transaction for credits issued by the issuer; there is a corresponding flag "authorized" for each trust line. AUTH_REVOCABLE_FLAG gives the issuer the capability to set authorized to "false" (default is "sticky" behavior, ie an issuer cannot de-authorize accounts). I am adding those cla
<stellar-slack>
<sunny-g> @monsieurnicolas: I think I get it. If an Acct B does not set the AUTH_REQUIRED flag, then I can hold their credits as soon as I extended them a trust line correct?
<stellar-slack>
<monsieurnicolas> yes that's it (and this is the default too as flags are not set by default)
<stellar-slack>
<sunny-g> Thanks @monsieurnicolas! And the revocable flag lets an issuer freeze transfer or an issuers credits, but not deauthorize an account that may already be holding its credits?
<stellar-slack>
<sunny-g> And thank you for adding clarifications to the source, that'll be super helpful
<stellar-slack>
<monsieurnicolas> revocable means an issuer can freeze (as in de-authorize) a specific account - even if the account has credits
pixelbeat has quit [Ping timeout: 240 seconds]
jbenet has quit []
jbenet has joined #stellar-dev
de_henne has joined #stellar-dev
de_henne has quit [Remote host closed the connection]
de_henne has joined #stellar-dev
DomKM has quit [Quit: Connection closed for inactivity]
skeuomorf has joined #stellar-dev
nelisky has quit [Quit: nelisky]
koolhead17 has joined #stellar-dev
<stellar-slack>
<scott> @monsieurnicolas: what does the `price` column in the `offers` table map to?
<stellar-slack>
<monsieurnicolas> it's the actual ratio n/d - it's used to select the top offers (sort by price)
<stellar-slack>
<donovan> @monsieurnicolas: How will the offer placement order be maintained for offers with the same price? That is, do offers placed earlier get matched before later offers of the same place?
<stellar-slack>
<scott> thanks
<stellar-slack>
<monsieurnicolas> @donovan, yes sorted by price and then offerid. so older offers get hit first
<stellar-slack>
<monsieurnicolas> (offerID is a global counter)
<stellar-slack>
<donovan> @monsieurnicolas: great, was going to suggest adding offerid to make a composite index, but you’ll get that for free as it’s the primary key :simple_smile:
<stellar-slack>
<donovan> Also, no need for an atomic increment? It will be only ever be used in one thread?
<stellar-slack>
<monsieurnicolas> yeah core is basically single threaded
<stellar-slack>
<monsieurnicolas> yeah we could use it for other objects as we see it fit
<stellar-slack>
<monsieurnicolas> we have some threads but they are used to do background work (like merging buckets); and in the future they would be used to parallelize certain tasks that are CPU intensive for example (like if we want to verify a bunch of signatures, we can use worker threads and join in the main thread)
<stellar-slack>
<donovan> Yep, all sounds good. A single core is pretty fast these days with a loaded cache :simple_smile:
<stellar-slack>
Am I right in thinking that the idpool field will be serialised (non-portably?) into the data column her:
<stellar-slack>
<scott> Still need to add tests, but thought you should know
<stellar-slack>
<andrew> YES
<stellar-slack>
<andrew> :+1: scott's the man
<stellar-slack>
<scott> Couldn’t find an account on the testnet that had offers, but I assure you it works in at least some cases (goes to right tests now)