00:07 <stellar-slack> <monsieurnicolas> I started to write down what I am thinking of doing for making upgrades smooth over time, any comments welcome : https://github.com/stellar/stellar-core/issues/499

00:13 <stellar-slack> <donovan> I think supporting ranges of protocols leads to a lot of complexity. A possible simplification is to reduce any instance to only support a current protocol and the next protocol, possibly indicated by a hash of the xdr definitions in source code form. An instance advertises these two supported protocols in its hello message. I guess the ultimate goal is to ensure that a majority of instances can migrate from

00:13 <stellar-slack> to a new ledger.

00:33 <stellar-slack> <donovan> Historical replay-ability is a very important feature of the Stellar design, in my view. A transaction executed in ledger 32569 (!) needs to be able to be executable by an instance years later, which may have a completely different code path for that transaction type and have multiple bugfixes applied. In an ideal world every transaction processing change would be archived in the code itself. One possible ide

00:33 <stellar-slack> (16-bit?) for each message type. An Offer might be 0001 and a AccountCreate might be 0002, and so on, in the first release. Any code change requires an increment for the affected message type and both the new and the old are both supported for replay but only the latest is accepted for new ledgers. Clients would have to have a way to get the latest accepted message type versions from the server. This continues for ever

00:33 <stellar-slack> time. Hopefully you don’t end up applying so many fixes that 65536 message types are exhausted :simple_smile:

00:44 <stellar-slack> <scott> I’m concerned about the implications of "Supported implementations lifetime considerations” section. IMO `stellar-core` itself needs to be able to replay history forevermore.

00:51 <stellar-slack> <scott> This problem of replayability was one of the reasons I mentioned event sourcing (http://martinfowler.com/eaaDev/EventSourcing.html) in the past.

02:57 <stellar-slack> <lab> stellar-core is processing consensus online. history is irrelavant.

03:00 <stellar-slack> <lab> the whole lifetime supporting is only needed by history processing, eg, ledger explorer/analyzer

03:02 <stellar-slack> <lab> donovan: +1 we need compact and pragmatic protocol.

03:05 <stellar-slack> <lab> event versioning is the heel of event sourcing.

15:01 <stellar-slack> <scott> event versioning really isn’t that tough provided you’re disciplined. A good test suite helps to keep you that way.

15:22 <stellar-slack> <monsieurnicolas> @donovan: the protocolVersion acts as a global version number for everything (so it's the generalized version of the 16 bit counter). Operations may change, but there are other things in the runtime that are not representable in the xdr file, the way we merge buckets for example. You can imagine protocolVersion being a rough approximation of the build number in a single implementation world, things

15:22 <stellar-slack> several implementations that move at different pace.

15:22 <stellar-slack> The reason for a range is that it's actually the same code than for dealing with previous/next: the rollout of versions still requires humans to make a decision.

15:22 <stellar-slack> As far as capability to replay history: I think we'll try to keep the stellar implementation compatible with the entire history for as long as we can. I don't think that it's a practical thing to do over the course of several years as the only way to guarantee support for older transactions is to actually replay everything from genesis - no other test suite can really give better guarantees as the implementation and

15:22 <stellar-slack> subtle way (like there was a compiler bug that triggered one behavior over another).

16:50 <bittrex-richie> is anyone having problems with the sfd servers?

17:00 <stellar-slack> <jed> bittrex what is going wrong?

17:52 <bittrex-richie> its not connecting properly

17:52 <bittrex-richie> been ahving intermittent connection issues for almost 12 hours

17:53 <bittrex-richie> using steller-rest and it says websocket connected.. but when i query it, getting an error back

18:00 <stellar-slack> <jed> bittrex. hmm yeah looks like they are still having issues. really can't wait to be on the new network

18:01 <stellar-slack> <richiela> hmm did you fix something?

18:01 <stellar-slack> <richiela> just came back alive

18:01 <stellar-slack> <eva> it's intermittent, so it may be on and off for you

18:02 <stellar-slack> <richiela> oh :disappointed:

20:57 <stellar-slack> <richiela> and its dead again meh

22:23 <stellar-slack> <jed> thanks richiela. I had to restart some of the public nodes. It should be back in action shortly

23:25 <stellar-slack> <richiela> still toast.. or it died again.. no sure which

23:25 <stellar-slack> <richiela> it says the socket is connected

23:25 <stellar-slack> <richiela> but it never gets the subscribe message

23:28 <stellar-slack> <jed> yeah still looking into it *sigh*

23:40 <stellar-slack> <richiela> coolio

23:40 <stellar-slack> <richiela> someoen should host two servers for redundancy :wink:

23:41 <stellar-slack> <andrew> we do host multiple servers its just that stellard is a big pile of you know what which is why we're moving to the new network as fast as possible.

23:42 <stellar-slack> <andrew> in other news, I've added a cool new feature to the client demo https://jsfiddle.net/stellardev/rxsd1fd0/

23:42 <stellar-slack> <andrew> its called "acccount management" and it allows a user of the demo to generate new accounts in a more seamless way, and then store them locally so they can refer back to them to set up scenarios. it also provides actions on each of the stored accounts to prefill in the various actions with the accounts address and secret.

23:44 <stellar-slack> <richiela> very cool

23:44 <stellar-slack> <richiela> going to make all of us write new code though aren't ya? :simple_smile:

23:48 <stellar-slack> <andrew> yeah but you'll love it

23:49 <stellar-slack> <andrew> the new API scott's cookin' up is a dream to code to

23:59 <stellar-slack> <richiela> grin.. they all say that.. but no one every thinks about us poor exchanges heh