Logged Conversation (all times UTC)
[00:00] <stellar-slack> I've no idea how Google have implemented it under the hood, but is a nice design.
[00:01] <stellar-slack> jed: I think it might just be an overzealous assert left over as an artifact of when Slot::processEnvelope was a bit more synchronous. it's being called from an async callback queued in processEnvelope, at Slot.cpp:117
[00:02] <stellar-slack> jed: tbh I don't really know this part of the Slot code very well...
[00:02] <stellar-slack> yeah I'll look
[00:02] <stellar-slack> I thought it was in the catchup code
[00:03] <stellar-slack> it is probably related to what I was changing to get SCP unstuck
[00:03] <stellar-slack> I think it's probably just receiving a straggler envelope and tripping a too-strong assert
[00:03] <stellar-slack> yeah
[00:03] <stellar-slack> donovan: perhaps, my concern is more to do with the queue mechanism than the query
[00:03] <stellar-slack> donovan: running queries against sql (or read-replicas thereof) should hold us for quite a while
[00:04] <stellar-slack> though I guess we don't want to wake up everyone. so yeah, some kind of filtering of the wakeups. I dunno. it's not an interface in the system I've given much thought to.
[00:04] <stellar-slack> as often, you're a few steps ahead of me :simple_smile:
[00:05] <stellar-slack> Re: Trustlines
[00:05] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/ledger/TrustFrame.cpp#L24
[00:05] <stellar-slack> Has the concept of "rippling"/transitive exchange been removed?
[00:05] <stellar-slack> @graydon: I guess, it's just the ability to filter the feed and get updates to a subset of state without polling.
[00:05] <stellar-slack> also I suspect that's scott's area of expertise more than mine. I keep learning new magic features of sql semantics every week :simple_smile:
[00:05] <stellar-slack> donovan: yeah you can do the same thing with offers
[00:05] <stellar-slack> ok guys I have to take a break.
[00:08] <stellar-slack> night
[00:10] <stellar-slack> @scott: You mentioned that you might release those go-xdr library patches. I'd be happy to have a play around if you're ready to open them up :simple_smile:
[00:15] <stellar-slack> (we might be a little slow on the reply for the next couple days since everyone is completely exhausted..)
[00:17] <stellar-slack> No probs, thanks for releasing it all so quickly and being so open about the process. Much appreciated! Have a rest :simple_smile:
[00:31] <stellar-slack> @donovan: I will probably open up the "go-stellar-base" library this weekend or early next week. It is an analog to https://github.com/stellar/js-stellar-base and https://github.com/stellar/ruby-stellar-base, i.e. "It consists of classes to read, write, hash, and sign the xdr structures that are used in stellar-core".
[00:31] <stellar-slack> As far as the patches to go-xdr, things ended up not working out that way... Instead I generate code with https://github.com/stellar/xdrgen/tree/master/lib/xdrgen that relies upon the existing go-xdr library without need for patches
[00:32] <stellar-slack> The actual code generation of the go xdr code is here: https://github.com/stellar/xdrgen/blob/master/lib/xdrgen/generators/go.rb, but I must warn you... it's _very ugly_, probably some of the worst I've written in recent memory. I hope to refactor and improve it this weekend
[00:41] <stellar-slack> Cool, thanks for pointing me in the right direction. I'll have a look over the weekend as well :simple_smile:
[01:03] <stellar-slack> in https://github.com/stellar/stellar-core/blob/master/src/transactions/readme.md#validity-of-a-transaction, surely the line about maxFee should be the other way around?
[01:06] <stellar-slack> lol, yeah. that does seem backwards
[01:47] <stellar-slack> let's call those practice runs for PRs - I'm sure there are as horrific typos in the actual code :simple_smile:
[08:24] <stellar-slack> is the unit changed in Hayashi?
[08:25] <stellar-slack> 3. View your account using the Horizon API. It should contain 1,000 lumens.
[08:25] <stellar-slack> "balance": 100000000
[08:25] <stellar-slack> 1 lumens = 1e5 stroop?
[08:26] <stellar-slack> it was 1e6 stroop 1 STR
[08:27] <stellar-slack> yeah, my understanding is 1e6 stroops to the lumen - scott would probably know offhand. Or we can go code diving :simple_smile:
[08:28] <stellar-slack> @lab: btw, I checked what metrics I do have on testnet1 & 2, no cpu or networks spikes to speak of) disk activity just tailed off at about 4/9 7:30am UTC
[08:30] <stellar-slack> @lab: looks like 100 lumens is what friendbot is set to give out https://github.com/stellar/horizon/blob/c04a703ee1fe75e572cc73b9fd45f5fbf7781bf2/app/models/friendbot.rb#L42
[08:30] <stellar-slack> so my guess is the 1,000 lumens is a documentation mistake
[08:31] <stellar-slack> :thumbsup:
[08:32] <stellar-slack> why so we "lumens"?
[08:33] <stellar-slack> @lab: I filed a ticket in our content repo I suspect it'll get picked up after everyone sleeps off their release grog
[08:33] <stellar-slack> thanks again!
[08:34] <stellar-slack> you are welcome :grinning:
[08:35] <stellar-slack> @epsilon: I believe it stemmed from confusion around everything being called "stellar" (the foundation, the daemon, the currency)
[08:36] <stellar-slack> could be more to it though. probably good to ask in #general to get the full story
[08:36] <stellar-slack> it seems lumens creates more detail
[08:39] <stellar-slack> There's a story? Will it be a cool one? *winkyface*
[08:39] <stellar-slack> I'm sure nowhere near as cool as the graphic novel
[08:39] <stellar-slack> :wink:
[08:42] <stellar-slack> lumens.. ffs
[10:34] <stellar-slack> Have to say I've been reading through all the code, and it is one of the best-commented and tested C++ codebases I've seen in a while. I love how the Application class is such a lightweight object that can be spun up in any test:
[10:34] <stellar-slack> https://github.com/stellar/stellar-core/blob/dc8a9adb494b0584fda9500fb1a465d175efdfd4/src/bucket/BucketTests.cpp#L337
[10:34] <stellar-slack> And for anyone with an interest in the internals of managing huge amounts of data, the honest discussion of tradeoffs here is required reading:
[10:34] <stellar-slack> https://github.com/stellar/stellar-core/blob/dc8a9adb494b0584fda9500fb1a465d175efdfd4/src/bucket/BucketList.h#L13
[10:34] <stellar-slack> Kudos :simple_smile:
[14:16] <stellar-slack> Here's a question:
[14:16] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/ledger/TrustFrame.cpp#L24-L25
[14:16] <stellar-slack> Why not `BIGINT UNSIGNED NOT NULL` and uint64 here:
[14:16] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/xdr/Stellar-ledger-entries.x#L40
[14:16] <stellar-slack> XDR seems to support 'unsigned hyper'
[14:16] <stellar-slack> http://en.wikipedia.org/wiki/External_Data_Representation#XDR_data_types
[14:44] <stellar-slack> :heart: :heart: Donovan: Have to say I've been reading through all the code, and it is one of the best-commented and tested C++ codebases I've seen in a while. I love how the Application class is such a lightweight object that can be spun up in any test:"
[14:45] <stellar-slack> the dev team worked really hard on making it usable
[14:45] <stellar-slack> I'm sure they will appreciate that comment!
[15:02] <stellar-slack> donovan: we wanted underflows to be less catastrophic. if unsigned and you underflow you end up with some really huge number and it is harder to detect than just ending up with w negative number
[15:03] <stellar-slack> @jed Makes sense :simple_smile:
[15:04] <stellar-slack> Another question... How is variable precision between different currencies going to be handled?
[15:05] <stellar-slack> at the client level. the IOUs will be issued in BTC or mBTC for example
[15:06] <stellar-slack> So all presentation of currencies is just handled in the client with hard-coded precisions for each currency?
[15:10] <stellar-slack> @donovan: Another note, none of the sql engines we target really handle uint64 very well. The few places we use them we're comfortable representing them as int64's because we're hopeful that by the time we need that highest bit we'll be running on sql engines that do.
[15:11] <stellar-slack> donovan: yeah that is the way people use currency really.
[15:13] <stellar-slack> @scott: Yep, Go 's database/sql isn't too fond of a high bit being set in a uint64 either :simple_smile:
[15:13] <stellar-slack> @jed: It's mostly a question of how a client would know what the precisions are without having to consult each issuer's website to find out.
[15:20] <stellar-slack> well they need to do that to even know what currency it is
[15:20] <stellar-slack> And it is probably going to be conveyed in the currency symbol
[15:21] <stellar-slack> BTC and mBTC wont have the same symbol
[15:23] <stellar-slack> Oh, just noticed 4 characters for the currency code:
[15:23] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/ledger/TrustFrame.cpp#L23
[15:23] <stellar-slack> Guess that makes it easier to apply some logical rules with the extra character :simple_smile:
[15:43] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/xdr/Stellar-types.x#L30-L34
[15:43] <stellar-slack> In my opinion, adding an extra uint8 to the struct which indicates the number of digits to the right of the decimal point would be a useful aid to most clients and would allow different issuers to perhaps have currencies with the same symbol but different degrees of precision. If you think about it you couldn't assume that a BTC symobol has a precision of 1, because you couldn't do partial BTC trades then, but that i
[15:43] <stellar-slack> precision of a 1000.
[15:44] <stellar-slack> donovan: we fiddled a lot with different possible approaches to currency representation
[15:45] <stellar-slack> at one end of the simplicity spectrum there's fixed-point fixed-interpretation, which is what we settled on
[15:45] <stellar-slack> on the other end there's something like real IEEE754R decimal floating point (note: decimal floating point, not binary) which is still a sufficiently new standard that we couldn't commit to it in good conscience, not enough places support it.
[15:46] <stellar-slack> (also 'floating point' terrifies programmers when thinking of money, they seem often to forget that integer divides round also)
[15:46] <stellar-slack> we didn't really want to build our own floating point system, that way seems like the worst of both worlds
[15:47] <stellar-slack> adding an "extra u8 to indicate number of digits" is essentially that
[15:48] <stellar-slack> at least if it's automatically integrated into arithmetic
[15:48] <stellar-slack> the weakest form of FP is a kind of manual mode wherein people can trade in microdollars or millidollars as completely independent units and in order to convert from one to another, you have to put in an order / execute a transaction. this might be adequate for the few boundary cases we expect to actually emerge.
[15:49] <stellar-slack> @graydon: Thanks for the answer! I'm more than happy with integral arithemtic, extended to uint128 for division. The extra precision value isn't intended to alter the arithmetic, just to provide a guide to clients on how to present currency values and compare offers on multiple books, without having to maintain a manual list of precisions for them to do their own calculations.
[15:50] <stellar-slack> (in that case, if that becomes a real concern, there _is_ actually 1 byte extra room in currency code due to all fields having to be multiples-of-4 bytes; we thought this was too cutesy to commit to for real but we might wind up going there if we have to, that is, permitting people to write 'mUSD' or 'uUSD' as currency codes. but we honestly don't expect people to need outside-u64-with-7-digits-after-decima
[15:51] <stellar-slack> (I actually was the side arguing for IEEE754R, but I lost after enough investigation on how few databases and PLs currently have full first-class support)
[15:56] <stellar-slack> I suppose ultimately it comes down to how successful a system is whether it needs to represent a number bigger than:
[15:56] <stellar-slack> 9,223,372,036,854.775807 (Assuming int64 and 6 digits to the right of the decimal place). In many ways it would be great if all currencies stuck to exactly the same precision :simple_smile:
[15:58] <stellar-slack> yeah. also what to _do_ in that case.
[15:59] <stellar-slack> like should you throw away the trailing '807' digits? that's what DFP will do. I think it's maybe ok to do so. I'm sure somewhere there's someone who thinks that's an abomination.
[15:59] <stellar-slack> or rather, that's what DFP will do in some modes. I actually implemented it in a way that traps all overflow, underflow and precision-loss events as errors and refuses to process them.
[16:00] <stellar-slack> but that results in other things you might _want_ being considered errors. so it's tricky.
[16:00] <stellar-slack> anyway we avoided DFP as I said. integer-wise we're going to treat overflow as an error the network rejects.
[16:02] <stellar-slack> Simple is good. I guess the real challenge is just educating all the first set of gateways to be very clear on what precision they are issuing their currencies and to make that information readily available. The network itself as a repository of that information is attractive to me, but I can understand why there is a resistance to add more than the basic information to any of the core entities.
[16:04] <stellar-slack> clients should assume everything is 1e6 by default
[16:08] <stellar-slack> Sounds like the first rule of Stellar Club :simple_smile:
[16:10] <stellar-slack> the first rule of stellar club is to blame the virtual clock for everything
[16:10] <stellar-slack> the second rule is to be careful capturing pointers in lambdas
[16:11] <stellar-slack> (the second-and-a-half rule is to run asan)
[16:12] <stellar-slack> the third rule is to add more metrics
[16:12] <stellar-slack> :simple_smile:
[16:12] <stellar-slack> it's a super boring club
[16:13] <stellar-slack> Sounds like a well-measured club to me :simple_smile:
[16:17] <stellar-slack> Here's another question (I've got plenty!):
[16:17] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/herder/HerderImpl.cpp#L258-L326
[16:17] <stellar-slack> This reads like a mini leadership election (a little like Raft in some ways). What is the role of a King/Monarch, and how does that relate to the whole set of peers, given that any peer might not know of all other peers?
[16:26] <stellar-slack> "king/monarch" is a misnomer; it's a sort-order chosen for the set of ballots in a round so that two peers pick values proposed by the same originating peer, but the peer they pick the proposal-of rotates randomly per-round.
[16:27] <stellar-slack> it just speeds up convergence on a candidate value, it's not intrinsic to the ratifying cycle's correctness (as far as I know)
[16:27] <stellar-slack> jed, dm or others might wish to elaborate further
[16:28] <stellar-slack> (this area of the code isn't stuff I'm especially familiar with)
[16:29] <stellar-slack> https://stellar-public.slack.com/archives/dev/p1428593095000246
[16:29] <stellar-slack> Early days aside, V-man, considerable input from your good self would be appreciated.
[16:34] <stellar-slack> @vinniefalco: Also, Dave #1
[16:35] <stellar-slack> @graydon: Thanks, would be good to hear a bit more about it from others. I guess it's possibly one of the most crucial bits and just want to understand it :simple_smile:
[16:38] <stellar-slack> I thought it might be also, but from the conversations I had about it, I now believe it's actually a bit of an ignorable detail, it just gives preference to one node's proposal (unpredictably) each round, so the others are likely to pick the same thing when faced with a choice of multiple acceptable options, rather than have to negotiate back and forth on which txs are "in" or "out" of the round, merge opti
[16:40] <stellar-slack> like you'll notice it's not a term that exists in the SCP protocol at all, or in scp/*
[16:41] <stellar-slack> it's just part of the process herder uses to select values to drive into SCP a its own proposals, based on the ballots it's heard so far
[16:42] <stellar-slack> (I mean, "ignorable" in the sense of evaluating SCP's correctness; I think it's important to know it exists for debugging and optimizing the herder's behavior)
[16:42] <stellar-slack> Is it quite likely or unlikely that multiple peers with the same quorum slices will pick the same king?
[16:43] <stellar-slack> I believe "likely", but just for the one round.
[16:44] <stellar-slack> I guess, the follow on question for that is what if the king is "befouled"?
[16:45] <stellar-slack> I believe it depends on whether the proposal differs from your own beliefs. I mean, a bad actor can still propose an acceptable-to-you value.
[16:45] <stellar-slack> ^That's not an answer
[16:46] <stellar-slack> but again, I'm really not expert in this part of the code
[16:46] <stellar-slack> epsilon: what part of the answer would you like me to change?
[16:46] <stellar-slack> I have been pretty up front about not knowing this part of the code so far. I'm not trying to mislead you.
[16:46] <stellar-slack> graydon: all the parts that donlt answer the question
[16:47] <stellar-slack> epsilon: I am not interested in a discussion with this tone.
[16:48] <stellar-slack> It's a tricky question, not sure anyone is being guarded with their answers. In fact this is one of the most open discussions I've ever been involved with :simple_smile:
[16:48] <stellar-slack> graydon: I appreciate your answers 100x than Slack allows me to indicate :simple_smile:
[16:48] <stellar-slack> ok. so .. what can I say that'll be helpful in understanding it?
[16:49] <stellar-slack> let's look through the code?
[16:49] <stellar-slack> graydon: you will only get "but I want" in social channels :stuck_out_tongue:
[16:50] <stellar-slack> heh
[16:50] <stellar-slack> I guess this is the core protocol. Peers want to agree on these values and identify themselves accordingly:
[16:50] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/xdr/Stellar-overlay.x#L10-L22
[16:51] <stellar-slack> A selected King's hash is compared to the peer's own. If they agree, great. If not re-reroll the dice?
[16:55] <stellar-slack> Also fascinated by the fact that the txset hash is agreed on and not the outcome of the transactions as well (in the Ripple Style). It would be fantastic to have safe knowledge that the outcomes are wholly deterministic!
[16:56] <stellar-slack> I think I'm out of my depth in understanding how this codepath interacts with consensus
[16:56] <stellar-slack> donovan: the effect of the txs is hashed in the ledger header after the ledger closes, and is thus the basis for the _next_ round
[16:57] <stellar-slack> donovan: we don't want to "pre-run" txs while we're still trying to agree on them.
[16:57] <stellar-slack> donovan: if there's any difference in their effect, though, it'll block the immediate-next round
[16:58] <stellar-slack> (I would also very much like to go get breakfast; back soon?)
[16:59] <stellar-slack> Cool, thanks for all the answers! Sorry, keep leaving Slack and reading code :simple_smile:
[17:02] <stellar-slack> the monarch stuff is what we are working on now. It will likely change so don't want to go into too much detail right now. But like graydon said it doesn't actually impact things right now that much it is just a way to narrow the possible ballot values nodes are considering. SCP would work without it
[17:04] <stellar-slack> jed: his concern was whether, in a degenerate case with a bunch of quorum members all having same qsets and all thereby picking the same monarch-for-a-round, whether that choice could effectively amplify the damage a misbehaving node could do should it get chosen as that round's monarch. as near as I can tell.
[17:04] <stellar-slack> it could only delay txs for a ledgerclose
[17:06] <stellar-slack> For all peers who have selected that king, or the whole network? What's the timeout in either of those situations?
[17:07] <stellar-slack> jed: can it convince you to accept a txset you otherwise wouldn't have?
[17:08] <stellar-slack> (I mean, in the sense that you propose it and your friends propose it too since they all picked same monarch)
[17:08] <stellar-slack> I think that's the concern
[17:10] <stellar-slack> @graydon: summarises my questions better than I ever could :simple_smile:
[17:12] <stellar-slack> sure but that isn't really that bad. all it can do is delay txs for a ledger till there is a new monarch
[17:13] <stellar-slack> mm, true: it can't reorder them within a round, and it can't initiate new ones on behalf of other keys, and it will lose its role in the next round..
[17:14] <stellar-slack> so it could delay a tx of its choosing for 1 ledger in that case.
[17:15] <stellar-slack> perhaps worrying but also likely something you could accomplish by other means. I'd hesitate to say we're immune from that sort of thing in general.
[17:38] <stellar-slack> restarting the horizon testnet, just a heads up
[17:56] <stellar-slack> Just want to attempt to summarise my understanding:
[17:56] <stellar-slack> Stellar-core uses a single slot in SCP to reach a consensus on the set of transactions to be used in the current ledger.
[17:56] <stellar-slack> If a node A has a Quorum Slice of B,C,D,E,F and node C is "befouled" it will be selected as a king/monarch once every 5 ledgers (on average) and will not provide a transaction set hash that the node A can agree on. This ledger will not be updated until a transaction set hash is selected from a different node for a subsequent ledger. This failure mode continues until node C is removed from the Quorum Slice. All node
[17:56] <stellar-slack> Quorum Slice carry on as normal.
[18:05] <stellar-slack> The befouled node C can attempt to attack in different ways:
[18:05] <stellar-slack> * by omitting transactions: in this case the pending transaction are still buffered and will be processed in the next ledger.
[18:05] <stellar-slack> * by attempting to manufacture transactions: the other node will check signatures and reject the set.
[18:05] <stellar-slack> * by giving A, B and D,E,F different sets: so long as they enjoy quorum intersection, agreement will fail and a new ballot round will start with a different monarch.
[18:05] <stellar-slack> I think it's more that C provides a txset that can, at worst, omit 1 or more txs from the set A would otherwise have chosen, but that opportunity will vanish in ledger N+1 and the omitted tx will enter the next txset.
[18:07] <stellar-slack> yeah, gmarceau's point here is that the only attack this opens up is omitting a tx, but since you only get the opportunity periodically the tx will just get picked up by the next round. it's similar to the kinds of attacks you can do at the edge of the network by delaying or reordering txs your clients submitted, if you're a misbehaved gateway.
[18:07] <stellar-slack> (or if you're the conecting node between two sides of quorum, delaying txs in flight)
[18:08] <stellar-slack> So there will be multiple rounds of king selection per ledger, and the nodes which selected the befouled node C will just keep spinning until they find another node than C?
[18:08] <stellar-slack> it is not an attack on consensus as such; consensus proceeds. it _is_ an attack on the values-agreed-on, but neither a big nor unique sort of attack.
[18:09] <stellar-slack> suppose C wants to omit tx T from the txset {T,U,V}. it gets selected as king for round N, proposed {U,V}, that gets accepted and consensus proceeds. problem is, C is not king in round N+1 and the other nodes propose T for N+1
[18:09] <stellar-slack> It's not so much the attack nature that concerns me, just what happens to the nodes with C in their quorum slice and what happens to nodes without C in their quorum slice.
[18:09] <stellar-slack> so T was delayed 1 ledger
[18:11] <stellar-slack> for nodes without C in their quorum slice, it depends how they're connected to C and what their sense of consensus is. consensus isn't a network-wide thing, it's a quorum-wide thing, which has to do with the transitive closure of a set of slices.
[18:12] <stellar-slack> but the worst that can happen (if I understand correctly, here I'm really just parroting what jed explained above) is that C manages to get a proposal for a smaller-than-otherwise txset into its quorum's consensus for a single round each time it comes up as king.
[18:12] <stellar-slack> and the txs that it omits spill into the next round
[18:13] <stellar-slack> Can we define round as opposed to ledger?
[18:16] <stellar-slack> round is in the vocabulary of scp, since in theory the algorithm doesn't know or care what the value its agreeing on represents.
[18:17] <stellar-slack> oh, sorry. I was using the two interchangeably.
[18:17] <stellar-slack> Can there me more than one round in deciding the current ledger?
[18:17] <stellar-slack> do distinguish rounds with ballots: the network will make multiple attempts at agreement if necessary. each attempt is called a ballot, where we decide whether value `v` will go in slot `i`.
[18:18] <stellar-slack> Is just one slot used in Stellar-core's application of SCP?
[18:21] <stellar-slack> we decide one slot at a time, for "the current ledger", but "slot number" (SCP terminology) and "ledger number" (stellar terminology) are often used interchangeably.
[18:22] <stellar-slack> and in the implementation there is only one instance of `Slot`. Its `i` is mutated to `i+i` after we externalize, but conceptually, there is one slot for ledger.
[18:24] <stellar-slack> I hate to re-quote previous words:
[18:24] <stellar-slack> ```Stellar-core uses a single slot in SCP to reach a consensus on the set of transactions to be used in the current ledger.
[18:24] <stellar-slack> If a node A has a Quorum Slice of B,C,D,E,F and node C is "befouled" it will be selected as a king/monarch once every 5 ledgers (on average) and will not provide a transaction set hash that the node A can agree on. This ledger will not be updated until a transaction set hash is selected from a different node for a subsequent ledger. This failure mode continues until node C is removed from the Quorum Slice. All node
[18:24] <stellar-slack> Quorum Slice carry on as normal.```
[18:24] <stellar-slack> but, is there anything incorrect in this summary?
[18:27] <stellar-slack> yeah, "will not provide a transaction set hash that the node A can agree on" is, I think, incorrect
[18:27] <stellar-slack> I think C provides a txset that A happily agrees on (as A views C as king-for-a-round)
[18:28] <stellar-slack> it just can't be _too badly damaged_ by this, because all C can do is make up bogus txs (rejected) or omit legitimate ones (delayed)
[18:31] <stellar-slack> So if C agrees on A's tx set which has omitted a single transaction that could have gone in ledger `n`, C moves on to ledger `n+1`, selects a new king which provides a tx set with a different hash which has one less transaction in it, what happens then?
[18:32] <stellar-slack> (edit) sorry A=C
[18:32] <stellar-slack> the omitted tx gets introduced into n+1's txset
[18:33] <stellar-slack> So different nodes can have ledgers with different sets of transactions in them?
[18:36] <stellar-slack> no. somehow we're talking past each other, sorry :disappointed:
[18:37] <stellar-slack> consensus includes a txset hash. "the quorum reached consensus" means they agreed on a specific set of txs
[18:37] <stellar-slack> there might be other txs floating around the system, queued, pending resubmission, buffered, etc.
[18:37] <stellar-slack> not part of consensus
[18:37] <stellar-slack> if a tx is omitted from a round of consensus
[18:38] <stellar-slack> it can (hopefully will!) show up in the next round
[18:38] <stellar-slack> off hand I don't know where an omitted tx is buffered, I'll ask if you want to see that data flow
[18:41] <stellar-slack> Sorry if I'm sounding braindead :simple_smile: So there are multiple rounds of consensus to reach agreement on the tx set for a single ledger. A single befouled node C cannot cause A,B,D,E or F to agree on its omitted transaction. King is respun and agreement is found.
[18:42] <stellar-slack> What I don't see is the message that indicates that this process has finished for a ledger:
[18:42] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/xdr/Stellar-overlay.x
[18:46] <stellar-slack> I think what's probably needed is a "SCP as applied to Stellar-core" summary. I'm probably just not doing the correct mental application myself :simple_smile:
[18:49] <stellar-slack> A node emits `COMMITTED` https://github.com/stellar/stellar-core/blob/master/src/scp/SCPXDR.x#L24
[18:50] <stellar-slack> Ah ha! Thank you :simple_smile:
[18:50] <stellar-slack> and here https://github.com/stellar/stellar-core/blob/master/src/scp/Slot.cpp#L196
[18:51] <stellar-slack> you're welcome :simple_smile:
[19:09] <stellar-slack> Would be great to see these tests or a version of them parameterised with variable numbers of members and thresholds in multiple sets with differing degrees of intersection (and perhaps with misbehaving nodes):
[19:09] <stellar-slack> https://github.com/stellar/stellar-core/blob/master/src/scp/SCPTests.cpp#L140-L150
[19:09] <stellar-slack> A lot of the fears over correctness of consensus algorithms seems to stem from simulations not being very real world like. Would like to say that I very much respect the decision to abstract the consensus algorithm outside of its application and to see the basis of some very thorough testing. It all comes across as very transparent and is great!
[19:20] <stellar-slack> yes, we have much testing ahead of us.
[19:45] <stellar-slack> What I would like to see in terms of testing is an implementation in a model checker like TLA+ - if some people are interested I'd love to help
[19:49] <stellar-slack> I have been poking around with this in maude lately but I have ... not exactly buckets of time
[19:49] <stellar-slack> It's a great idea and interesting to see what others have done:
[19:49] <stellar-slack> https://github.com/efficient/epaxos/blob/master/tla%2B/EgalitarianPaxos.tla
[19:49] <stellar-slack> and very little training with it
[19:57] <stellar-slack> For reference:
[19:57] <stellar-slack> http://research.microsoft.com/en-us/um/people/lamport/tla/c-manual.pdf
[19:57] <stellar-slack> Kind of tempted :simple_smile:
[20:01] <stellar-slack> welcome @lewis
[20:01] <stellar-slack> hey @scott
[20:25] <stellar-slack> fyi core devs, this now the second time I've seen this behavior: https://github.com/stellar/stellar-core/issues/429
[20:26] <stellar-slack> I didn't realize it was a crash the first time, and I don't have logs around it, unfortunately
[20:33] <stellar-slack> @jed did you mean to add the `txfee` when doing a texttx command? https://github.com/stellar/stellar-core/commit/3d1e5a3e588a47872aaaca4b7ef1c696e3937350#diff-5b6efc13ccf0b9d4a919225b9df1cf6bR117
[20:46] <stellar-slack> it's not needed: the fee is already set by the createPaymentTx function
[20:47] <stellar-slack> (test helper function)
[20:50] <stellar-slack> @donovan, you should download the toolkit - it's java/eclipse. What put me off was the amount of specification to write for a protocol like paxos for example (it's in the sample directory). The good thing about it though, is that it forces to think about the various "modules" that need to be model checked so that the internal state machine doesn't blow up.
[20:52] <stellar-slack> @monsieurnicolas: I am genuinely interested in exploring it. I'll have a play around over the weekend and see if I can get a start worth sharing :simple_smile:
[20:54] <stellar-slack> like one module could be dedicated to the herder king aka pre consensus phase.
[20:55] <stellar-slack> yeah, there is probably a bunch of grunt work just to get the basic stuff setup without even passing messages around
[20:55] <stellar-slack> maybe some can be stolen from other existing models
[20:56] <stellar-slack> @monsieurnicolas: P.S. don't want to appear like a linkedin browser type, but back in a former life I was a big user of Painter :simple_smile: Worked on this ad in Spain: https://vimeo.com/63820956
[20:56] <stellar-slack> All painted in Painter :simple_smile:
[20:56] <stellar-slack> Back to TLA, I'll have a hack around with the examples :simple_smile:
[20:56] <stellar-slack> ah the Painter days :simple_smile: That was an interesting bunch of people
[20:57] <stellar-slack> Cool software, the brushes were just so much better than Photoshop's
[20:57] <stellar-slack> The animation stepper was a bit of a nightmare, but it did work, sort of :simple_smile:
[20:58] <stellar-slack> the version we never shipped was light years of everything else. but oh well
[20:58] <stellar-slack> Bryce as well, that was a lot of fun!
[20:58] <stellar-slack> memory dots
[20:59] <stellar-slack> anyways, I am going to get an updated PR for the changes in Herder
[20:59] <stellar-slack> I got David to commit the XDR changes I needed
[21:00] <stellar-slack> (so it unblocks the queue)
[21:09] <stellar-slack> r+ anybody on this? https://github.com/stellar/stellar-core/pull/420
[21:15] <stellar-slack> i'll trade you: https://github.com/stellar/stellar-core/pull/430
[21:16] <stellar-slack> heh
[21:19] <stellar-slack> gmarceau: broadly speaking, how was it quadratic?
[21:19] <stellar-slack> (sorry!)
[21:21] <stellar-slack> The timer queue would accumulate a O(n) pending timers, one for each node in the quorum slice I suppose, then cancel them all one at a time.
[21:23] <stellar-slack> thus O(n) traversals of a O(n) data structure
[21:23] <stellar-slack> The `mFlushedIgnored` counter is the what's breaking the quadratic in the new code https://github.com/gmarceau/stellar-core/commit/1c7449dc887177bafdf6b9ba1d2e8accd86aa869#diff-64a1174a8c85061d0e7afd0261feccc2R158
[21:25] <stellar-slack> combined with the `VirtualTimer` keeping track of their VirtualClockEvent`s to preserve to eager-trigger semantic of cancels
[21:25] <stellar-slack> https://github.com/gmarceau/stellar-core/commit/1c7449dc887177bafdf6b9ba1d2e8accd86aa869#diff-5288190c639e04decbed7d3677d5eafdR170
[21:26] <stellar-slack> I'm worried it's permitting mutation of the queue during dispatch
[21:26] <stellar-slack> but I can't quite tell
[21:26] <stellar-slack> (the new code)
[21:26] <stellar-slack> this is relatively important not-to-permit
[21:26] <stellar-slack> the pending number of events in the queue never got huge, couple hundreds, a thousand at the top. but it's getting hammered the core scp loop.
[21:26] <stellar-slack> like if you trigger an event and it enqueues a new event on dispatch, it can invalidate pointers and/or loop while dispatching
[21:27] <stellar-slack> but .. fingers crossed! :simple_smile:
[21:28] <stellar-slack> cool, now I know what that `toDispatch` var is for https://github.com/gmarceau/stellar-core/commit/1c7449dc887177bafdf6b9ba1d2e8accd86aa869#diff-64a1174a8c85061d0e7afd0261feccc2L267
[21:31] <stellar-slack> or if an event cancel a timer and the flushing runs, it'll break, good point
[21:36] <stellar-slack> yeah. it seemed a bit silly how I was doing it but there's a lot of feedback-prevention required to keep it from blowing itself up
[21:37] <stellar-slack> does `toDispatch` really need to be a priority queue? it seems vector's ordering can be trusted, and the events come out of mEvents sorted.
[21:38] <stellar-slack> doesn't need to be a pqueue
[21:38] <stellar-slack> that was just my being lazy I think
[21:38] <stellar-slack> I mean, like mentally lazy. probably tired.
[21:42] <stellar-slack> pushed -f
[22:00] <stellar-slack> gmarceau: you missed one more feedback thing, in cancelAllEvents
[22:00] <stellar-slack> gmarceau: r+ otherwise, looks good. much nicer.
[22:00] <stellar-slack> saw that, thanks.
[22:01] <stellar-slack> thank you! I felt dirty with the compare-to-timer-pointer thing every time I read it. I should never have committed that, it was wrong wrong wrong.
[22:03] <stellar-slack> eh, you're forgiven :simple_smile:
[22:03] <stellar-slack> though the mFlushesIgnored thing comparing against the event-list size is ... sufficiently counterintuitive, or at least nonobvious, that it might be worth a comment explaining why it's happening
[22:04] <stellar-slack> ("// we're buffering cancelled-event flushes here to avoid traversing the event queue too often; easy to go quadratic when cancelling a lot of timers.") or such
[22:33] <stellar-slack> added a note
[22:34] <stellar-slack> the travis web interface can't see the repo anymore, complains "The repository at stellar/stellar-core was not found."
[22:34] <stellar-slack> do you get that too?
[22:42] <stellar-slack> Looks like maybe you guys are moving stellar-core from our private travis to the public infrastructure?
[22:47] <stellar-slack> hopefully someone we know
[22:48] <stellar-slack> lol. I just see that their is a buildless stellar-core in the public travis infrastructure: https://travis-ci.org/stellar/stellar-core/branches
[22:59] <stellar-slack> graydon you know what is up with travis?
[22:59] <stellar-slack> no
[22:59] <stellar-slack> shall I check?
[23:00] <stellar-slack> please
[23:01] <stellar-slack> I think possibly it didn't handle the switch to public
[23:01] <stellar-slack> I'll re-enable
[23:01] <stellar-slack> @monsieurnicolas: your PR needs a rebase now
[23:02] <stellar-slack> and can I get r+ https://github.com/stellar/stellar-core/pull/423
[23:02] <stellar-slack> switched on
[23:02] <stellar-slack> it seems like http://travis-ci.org|travis-ci.org is now doing it
[23:02] <stellar-slack> not http://travis-ci.com|travis-ci.com
[23:02] <stellar-slack> because it's public
[23:03] <stellar-slack> I sure hope they didn't punt us to worse machines!
[23:03] <stellar-slack> graydon: note that I had to manually delete the travis webhook in the github settings. then toggle the switch on https://travis-ci.org/profile/stellar to get things working
[23:03] <stellar-slack> (for the other repos, that is)
[23:04] <stellar-slack> oh please not worse machines. the 45 min cycle to get a PR in is killing me
[23:06] <stellar-slack> I want to say that my builds are running faster on the public infrastructure, but I wasn't smart enough to record the private run times
[23:07] <stellar-slack> I think the test suite on ruby-stellar-base was taking ~15 minutes for jruby on private, it's ~10 now on public
[23:08] <stellar-slack> @scott: maybe http://docs.travis-ci.com/user/caching/ will be helpful to speed it up
[23:09] <stellar-slack> @jed: r+'ed your PR
[23:10] <stellar-slack> checking out. g'night.
[23:37] <stellar-slack> bartek: we do quite a bit of caching! ccache even
[23:38] <stellar-slack> jed: we're down to 25min last I checked
[23:44] <stellar-slack> @graydon: is there a simple way to check if the various invocations of VirtualClock are done from the main thread? It looks like the code is not thread safe, as in: creating/cancelling timers will mess with "mEvents" which is not thread safe
[23:44] <stellar-slack> can put an assertion in that we're on the main thread, sure.
[23:45] <stellar-slack> capture main thread id on startup, compare on any call?
[23:47] <stellar-slack> yeah I guess this works
About StellarVerse IRC Logger
StellarValue IRC Logger
is part of