Logged Conversation (all times UTC)
[03:43] <stellar-slack> i missunderstood it. I thought it was all keys in account used instead of all sigs in envelope.
[03:44] <stellar-slack> current multi key design is really brilliant
[04:00] <coinpip> Guys can u help me to understand why my payment transaction doesn't work.
[04:01] <coinpip> I use testnet
[04:01] <coinpip> This is what I do:
[04:01] <coinpip> curl -X POST https://test.stellar.org:9002 -d '
[04:01] <coinpip> {
[04:01] <coinpip> "method": "static_path_find",
[04:01] <coinpip> "params": [
[04:01] <coinpip> {
[04:01] <coinpip> "source_account": "g4e5v2ERpKvdBZrchn6DrWUtvezkXsu5wo",
[04:01] <coinpip> "destination_account": "gJ3e65GzqERgeeS5oXsv8NGfdZWzm93ej6",
[04:01] <coinpip> "source_currencies" : [ { "currency" : "SGD", "issuer" : "gDfapfG5hDHuYkbVpugtupkGYVTKXwd59r"} ],
[04:01] <coinpip> "destination_amount": {
[04:01] <coinpip> "currency": "MYR",
[04:01] <coinpip> "value": "1",
[04:01] <coinpip> "issuer": "gsQuUKcxM68nEX9tKR71UH5hZXwrvT2mpS"
[04:01] <coinpip> }
[04:01] <coinpip> }
[04:02] <coinpip> And paths is found
[04:02] <coinpip> Then I try to make payment transaction:
[04:02] <coinpip> curl -X POST https://test.stellar.org:9002 -d '
[04:02] <coinpip> {
[04:02] <coinpip> "method": "submit",
[04:02] <coinpip> "params": [
[04:02] <coinpip> {
[04:04] <stellar-slack> Do we have a SGD gateway in testnet?
[04:05] <coinpip> And it doesn't work. I getting error tecPATH_PARTIAL Path could not send full amount.
[04:05] <coinpip> Yes I have. This is gateway for SGD gDfapfG5hDHuYkbVpugtupkGYVTKXwd59r
[04:07] <coinpip> I sending from g4e5v2ERpKvdBZrchn6DrWUtvezkXsu5wo SGD to gJ3e65GzqERgeeS5oXsv8NGfdZWzm93ej6 MYR . This is marketmaker gfQPtvgmavftERtEgYgt4VcjGTtfMut9EM to make SGD to MYR transaction happen
[04:08] <coinpip> This gateway gsQuUKcxM68nEX9tKR71UH5hZXwrvT2mpS for MYR
[04:10] <stellar-slack> really cool
[04:13] <stellar-slack> have you tried without source_currencies?
[04:13] <stellar-slack> Houston we have a problem
[04:13] <coinpip> Without source_currencies it doesn't show any path
[04:13] <stellar-slack> I’m just using source_account, destination_account and destination_amount in my static_path_find
[04:14] <stellar-slack> mkay
[04:16] <coinpip> This is result without source_currencies
[04:16] <coinpip> {
[04:16] <coinpip> "result": {
[04:16] <coinpip> "alternatives": [],
[04:16] <coinpip> "destination_account": "gJ3e65GzqERgeeS5oXsv8NGfdZWzm93ej6",
[04:16] <coinpip> "destination_currencies": [
[04:16] <coinpip> "MYR",
[04:16] <coinpip> "STR"
[04:16] <coinpip> ],
[04:16] <coinpip> "status": "success"
[04:16] <coinpip> }
[04:16] <coinpip> }
[05:24] <coinpip> Any suggestion how to solve this issue?
[06:13] <stellar-slack> turn off no rippling
[06:14] <stellar-slack> on your accounts
[06:49] <coinpip> I just did it. And It doesn't show any paths at all
[06:56] <stellar-slack> 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)?
[15:58] <stellar-slack> ok testnet is rolling along again
[15:59] <stellar-slack> scott ^
[15:59] <stellar-slack> cool. thanks!
[17:57] <stellar-slack> @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
[18:02] <stellar-slack> @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?
[18:06] <stellar-slack> yes that's it (and this is the default too as flags are not set by default)
[18:42] <stellar-slack> 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?
[18:43] <stellar-slack> And thank you for adding clarifications to the source, that'll be super helpful
[18:57] <stellar-slack> revocable means an issuer can freeze (as in de-authorize) a specific account - even if the account has credits
[20:47] <stellar-slack> @monsieurnicolas: what does the `price` column in the `offers` table map to?
[20:48] <stellar-slack> it's the actual ratio n/d - it's used to select the top offers (sort by price)
[20:51] <stellar-slack> @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?
[20:53] <stellar-slack> thanks
[20:55] <stellar-slack> @donovan, yes sorted by price and then offerid. so older offers get hit first
[20:56] <stellar-slack> (offerID is a global counter)
[20:56] <stellar-slack> @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:
[20:56] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/ledger/OfferFrame.cpp#L41
[21:07] <stellar-slack> @monsieurnicolas: Where’s the logic for where the offerid gets assigned the global counter when 0 as per:
[21:07] <stellar-slack> https://github.com/stellar/stellar-core/blob/0553effc694f82d3e4403b70c5f53d1b4584e17d/src/xdr/Stellar-transaction.x#L98
[21:07] <stellar-slack> Sorry, couldn’t find it :simple_smile:
[21:10] <stellar-slack> Ahh, found it:
[21:10] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/transactions/CreateOfferOpFrame.cpp#L289-L290
[21:10] <stellar-slack> here https://github.com/stellar/stellar-core/blob/master/src/transactions/CreateOfferOpFrame.cpp#L289-L290
[21:10] <stellar-slack> :simple_smile:
[21:10] <stellar-slack> Lol, sorry :simple_smile:
[21:10] <stellar-slack> np
[21:12] <stellar-slack> So this id is general and can be used for any required id in other transaction types?
[21:12] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/ledger/LedgerHeaderFrame.cpp#L62-L66
[21:13] <stellar-slack> Also, no need for an atomic increment? It will be only ever be used in one thread?
[21:14] <stellar-slack> yeah core is basically single threaded
[21:14] <stellar-slack> yeah we could use it for other objects as we see it fit
[21:16] <stellar-slack> 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)
[21:18] <stellar-slack> Yep, all sounds good. A single core is pretty fast these days with a loaded cache :simple_smile:
[21:18] <stellar-slack> Am I right in thinking that the idpool field will be serialised (non-portably?) into the data column her:
[21:18] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/ledger/LedgerHeaderFrame.cpp#L79-L81
[21:20] <stellar-slack> Looks like it is:
[21:20] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/xdr/Stellar-ledger.x#L28
[21:20] <stellar-slack> Sorry, answering my own questions :simple_smile:
[21:22] <stellar-slack> :simple_smile:
[23:03] <stellar-slack> @andrew: Initial offer support is out on the testnet: http://horizon-testnet.stellar.org/accounts/gsgevbsE3bPvJe15E8drUnwiEGb7xDzCHfKnwe8USxVbpBVzMG8/offers
[23:03] <stellar-slack> Still need to add tests, but thought you should know
[23:03] <stellar-slack> YES
[23:04] <stellar-slack> :+1: scott's the man
[23:04] <stellar-slack> 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)
[23:05] <stellar-slack> An example offer:
About StellarVerse IRC Logger
StellarValue IRC Logger
is part of