rjones (Mon, 11 Mar 2019 19:50:45 GMT):
nage

rjones (Mon, 11 Mar 2019 19:52:21 GMT):
Has left the channel.

nage (Mon, 11 Mar 2019 21:33:25 GMT):
User User_1 added by nage.

nage (Mon, 11 Mar 2019 21:33:40 GMT):
User User_2 added by nage.

nage (Mon, 11 Mar 2019 21:35:01 GMT):
Place to discuss the next major revision of Indy Ledger architecture (see #indy-node for the current stable release)

nage (Mon, 11 Mar 2019 21:35:19 GMT):
User User_3 added by nage.

nage (Mon, 11 Mar 2019 21:35:28 GMT):
User User_4 added by nage.

nage (Mon, 11 Mar 2019 21:35:40 GMT):
User User_5 added by nage.

nage (Mon, 11 Mar 2019 21:35:59 GMT):
User User_6 added by nage.

nage (Mon, 11 Mar 2019 21:36:15 GMT):
User User_7 added by nage.

nage (Mon, 11 Mar 2019 21:36:54 GMT):
Please invite others who were on the call today but haven't made their way to the channel.

nage (Mon, 11 Mar 2019 21:38:13 GMT):
User User_8 added by nage.

mwherman2000 (Tue, 12 Mar 2019 01:39:45 GMT):
Has joined the channel.

ashcherbakov (Tue, 12 Mar 2019 06:26:09 GMT):
User User_9 added by ashcherbakov.

ashcherbakov (Tue, 12 Mar 2019 06:26:10 GMT):
User User_10 added by ashcherbakov.

ashcherbakov (Tue, 12 Mar 2019 06:26:10 GMT):
User User_11 added by ashcherbakov.

ashcherbakov (Tue, 12 Mar 2019 06:26:51 GMT):
User User_12 added by ashcherbakov.

ashcherbakov (Tue, 12 Mar 2019 07:09:05 GMT):
User User_13 added by ashcherbakov.

ashcherbakov (Tue, 12 Mar 2019 07:11:31 GMT):
Ledger 2.0 kick-off slides: https://docs.google.com/presentation/d/1vs_wWhSCRlEMA9RdS4bGUn8XIcsHUKK8t7Nw2qf6w8A/edit#slide=id.g45e53a55e3_0_0

ashcherbakov (Tue, 12 Mar 2019 07:11:56 GMT):
A Spreadsheet to track current options for Protocols and Platforms: https://docs.google.com/spreadsheets/d/1-GuJuew1oUvnlzU7gBPZkF5Ongu92voojPHAPc-pUu8/edit#gid=0

ashcherbakov (Tue, 12 Mar 2019 07:12:13 GMT):
Epic in Jira: https://jira.hyperledger.org/browse/INDY-1691

ashcherbakov (Tue, 12 Mar 2019 07:12:36 GMT):
The current Plenum's consensus protocol sequence diagram: https://github.com/hyperledger/indy-plenum/blob/master/docs/source/diagrams/consensus-protocol.png

mwherman2000 (Tue, 12 Mar 2019 13:52:26 GMT):
Hi, I've looked through the slides and wanted to confirm the scope for Ledger 2.0, using https://github.com/mwherman2000/indy-arm/blob/master/README.md#8-ledger-viewpoint- as a reference, is the intended scope limited to the the Ledger Nodes and the Ledger (Verifiable Data Registry) ..i.e. elements (35) and (37) in the Ledger Viewpoint? ...or for example, are the actual Indy Transaction types, their representation and storage, etc. potentially in-scope i.e. element (17)?

mwherman2000 (Tue, 12 Mar 2019 13:52:26 GMT):
Hi, I've looked through the slides and wanted to confirm the scope for Ledger 2.0, using https://github.com/mwherman2000/indy-arm/blob/master/README.md#8-ledger-viewpoint- as a reference, is the intended scope limited to the the Ledger Nodes and the Ledger (Verifiable Data Registry) ..i.e. elements (35) and (37) in the Ledger Viewpoint? ...the Node to Node communications protocol i.e. element (39)? ...also,, are the actual Indy Transaction types, their representation and storage, etc. potentially in-scope i.e. element (17)?

mwherman2000 (Tue, 12 Mar 2019 13:52:26 GMT):
Hi, I've looked through the slides and wanted to confirm the scope for Ledger 2.0, using https://github.com/mwherman2000/indy-arm/blob/master/README.md#8-ledger-viewpoint- as a reference, is the intended scope limited to the the Ledger Nodes and the Ledger (Verifiable Data Registry) ..i.e. elements (35) and (37) in the Ledger Viewpoint? ...the Node to Node communications protocol i.e. element (39)? ...also, are the actual Indy Transaction types, their representation and storage, etc. potentially in-scope i.e. element (17)?

mwherman2000 (Tue, 12 Mar 2019 13:52:26 GMT):
Hi, I've looked through the slides and wanted to confirm the scope for Ledger 2.0, using https://github.com/mwherman2000/indy-arm/blob/master/README.md#8-ledger-viewpoint- as a reference, is the intended scope limited to the the Ledger Nodes and the Ledger (Verifiable Data Registry) ..i.e. elements (35), (36). and (37) in the Ledger Viewpoint? ...the Node to Node communications protocol i.e. element (39)? ...also, are the actual Indy Transaction types, their representation and storage, etc. potentially in-scope i.e. element (17)?

mwherman2000 (Tue, 12 Mar 2019 13:53:02 GMT):

Clipboard - March 12, 2019 6:52 AM

alkopnin (Tue, 12 Mar 2019 23:34:13 GMT):
User User_14 added by alkopnin.

amundson (Wed, 13 Mar 2019 00:29:24 GMT):
FWIW, Sawtooth's PBFT implementation is complete now - it's in pre-1.0 testing/review.

amundson (Wed, 13 Mar 2019 00:36:42 GMT):
the current URL is - https://github.com/hyperledger/sawtooth-pbft/ (the slides have the much older bitwiseio repo)

reithmayer (Wed, 13 Mar 2019 07:47:43 GMT):
Has joined the channel.

esplinr (Fri, 15 Mar 2019 23:28:57 GMT):
User User_15 added by esplinr.

esplinr (Fri, 15 Mar 2019 23:32:00 GMT):
Today I sent out a calendar invitation for a checkpoint coordination call on October 28 (October 29 in New Zealand). On Monday's call, we set a goal for Based on our call on Monday, Evernym, Luxoft, and Spark are likely to have

esplinr (Fri, 15 Mar 2019 23:32:00 GMT):
Today I sent out a calendar invitation for a checkpoint coordination call on October 28 (October 29 in New Zealand). On Monday's call we agreed to try and have a team assembled by October (Q4). Evernym, Spark, and Luxoft think it is likely they will have one engineer available. We need to recruit a few more participants to really make progress.

esplinr (Fri, 15 Mar 2019 23:32:00 GMT):
Today I sent out a calendar invitation for a checkpoint coordination call on October 28 (October 29 in New Zealand). On Monday's call we agreed to try and have a team assembled by October (Q4). Evernym, Spark, and Luxoft think it is likely they each will have one engineer available. We need to recruit a few more participants to really make progress.

esplinr (Fri, 15 Mar 2019 23:34:26 GMT):
If I missed anyone in my invitation for October 28/29, let me know. I also submitted the event to the Hyperledger Community Calendar.

esplinr (Fri, 15 Mar 2019 23:36:56 GMT):
Also, I found this article to be interesting: https://medium.com/interstellar/understanding-the-stellar-consensus-protocol-423409aad32e

esplinr (Fri, 15 Mar 2019 23:45:20 GMT):
Oh, and of course the Sovrin Foundation also said they intend to have an engineer available in Q4.

pieterp (Sat, 16 Mar 2019 04:55:03 GMT):
Has joined the channel.

ashcherbakov (Mon, 18 Mar 2019 07:23:02 GMT):
@mwherman2000 You are correct that this affects only the Ledger (Node) part, that is elemements (35) and (37). As for other items, it depends on the option we choose for Ledger 2.0. It may affect Ledger storage level (36) if we choose a different platform for Ledger 2.0, but will not affect it if we keep existing Plenum code. The same for node-to-node communication (39). I think we will need to keep txn format (17) not changed regardless of the chosen option. But we will be answer for sure after we choose the option for implementation.

xnopre (Mon, 18 Mar 2019 09:26:34 GMT):
Has joined the channel.

aronvanammers (Mon, 18 Mar 2019 14:14:34 GMT):
Has joined the channel.

ashcherbakov (Mon, 18 Mar 2019 14:29:35 GMT):
More docs about write and read requests workflow, that has State Proofs and BLS multi-sigs descriptions: - https://github.com/hyperledger/indy-plenum/blob/master/docs/source/diagrams/read-requests.png - https://github.com/hyperledger/indy-plenum/blob/master/docs/source/diagrams/write-requests.png - https://github.com/hyperledger/indy-plenum/blob/master/docs/source/diagrams/consensus-protocol.png - https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md#reply-structure-for-read-requests

AlexanderVtyurin (Mon, 18 Mar 2019 16:44:26 GMT):
Has joined the channel.

mwherman2000 (Mon, 18 Mar 2019 19:43:07 GMT):
FYI: The INDY ARM Interactive Explorer is available as of right now: https://github.com/mwherman2000/indy-arm/blob/master/README.md#indy-arm-interactive-explorer

alkopnin (Mon, 18 Mar 2019 20:10:45 GMT):
Hey guys, Did you assess Avalanche algorithm? - https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV

BernardLin (Fri, 22 Mar 2019 14:29:48 GMT):
Has joined the channel.

Gruszka (Fri, 22 Mar 2019 21:44:19 GMT):
Has joined the channel.

NutecDev (Mon, 25 Mar 2019 10:05:31 GMT):
Has joined the channel.

Ryan2 (Tue, 26 Mar 2019 04:48:17 GMT):
Has joined the channel.

esplinr (Thu, 28 Mar 2019 22:04:55 GMT):
@Sergey.Kupryushin: any thoughts on the Avalanch algorithm?

esplinr (Thu, 28 Mar 2019 22:04:55 GMT):
@Sergey.Kupryushin: any thoughts on the Avalanche algorithm?

Sergey.Kupryushin (Thu, 28 Mar 2019 22:04:55 GMT):
Has joined the channel.

wangdong (Sat, 30 Mar 2019 07:05:42 GMT):
Has joined the channel.

mwherman2000 (Sat, 30 Mar 2019 19:17:04 GMT):
`did-uri-spec`: I've been working on a `did-uri-spec` specification for a generic/baseline DID URI grammar... *Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) * Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md …which emphasizes the different application areas or domains that use DIDs and how they can be supported with the did-url-spec grammar. An interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline did-url-spec grammar to support Domain-specific DID Grammars (DSDGs). Here’s a short webcast (16 minutes) that describes this capability: *Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3* Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src Also. here's 20-minute talk on the Domain-specific #DID Grammar (DSDG) for DID Document Collections ... ... checkout video #3 in the #Hyperonomy playlist: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv This webcast also describes how the $supportedCapabilities DID Method transformer option will (most likely) work.

mwherman2000 (Sat, 30 Mar 2019 19:17:04 GMT):
`did-uri-spec`: I've been working on a `did-uri-spec` specification for a generic/baseline DID URI grammar... *Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) * Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md …which emphasizes the different application areas or domains that use DIDs and how they can be supported with the did-url-spec grammar. An interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline did-url-spec grammar to support Domain-specific DID Grammars (DSDGs). Here’s a short webcast (16 minutes) that describes this capability: *Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3* Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src Also. here's 20-minute talk on the **Domain-specific #DID Grammar (DSDG) for DID Document Collections** ... ... checkout video #3 in the #Hyperonomy playlist: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv This webcast also describes how the $supportedCapabilities DID Method transformer option will (most likely) work.

mwherman2000 (Sat, 30 Mar 2019 19:17:04 GMT):
`did-uri-spec`: I've been working on a `did-uri-spec` specification for a generic/baseline DID URI grammar... *Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) * Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md …which emphasizes the different application areas or domains that use DIDs and how they can be supported with the did-url-spec grammar. An interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline did-url-spec grammar to support Domain-specific DID Grammars (DSDGs). Here’s a short webcast (16 minutes) that describes this capability: *Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3* Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src Also. here's 20-minute talk on the **Domain-specific #DID Grammar (DSDG) for DID Document Collections** ... ... checkout video #3 in the #Hyperonomy playlist: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv This webcast also describes how the `$supportedCapabilities` DID Method transformer option will (most likely) work.

mwherman2000 (Sat, 30 Mar 2019 19:17:04 GMT):
`did-uri-spec`: I've been working on a `did-uri-spec` specification for a generic/baseline DID URI grammar... *Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) * Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md …which emphasizes the different application areas or domains that use DIDs and how they can be supported with the `did-url-spec` grammar. An interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline `did-url-spec` grammar to support Domain-specific DID Grammars (DSDGs). Here’s a short webcast (16 minutes) that describes this capability: *Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3* Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src Also. here's 20-minute talk on the **Domain-specific #DID Grammar (DSDG) for DID Document Collections** ... ... checkout video #3 in the #Hyperonomy playlist: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv This webcast also describes how the `$supportedCapabilities` DID Method transformer option will (most likely) work.

mwherman2000 (Sat, 30 Mar 2019 19:20:06 GMT):
How is this relevant for the Ledger 2.0 project? It might be considered on the "edge" of what's in-scope but I'm interested in contributing: 1. `did-url` parser 2. `did-uri` AST semantic analyser 3. `did-uri` AST execution optimizer ...specifically for Ledger 2.0. Here's picture from the first webcast listed above...

mwherman2000 (Sat, 30 Mar 2019 19:21:23 GMT):

Clipboard - March 30, 2019 1:21 PM

mwherman2000 (Sat, 30 Mar 2019 19:22:38 GMT):

Clipboard - March 30, 2019 1:22 PM

mwherman2000 (Sat, 30 Mar 2019 19:30:12 GMT):
HINT: In YouTube, you can click on the gear settings icon, and then select 1.5x or even 2.0x to play the video in a shorter amount of time. It works well because I deliberately talk slowly.

lukasA (Mon, 01 Apr 2019 12:26:12 GMT):
Has joined the channel.

AlexanderVtyurin (Tue, 02 Apr 2019 13:07:42 GMT):
Hello everyone. According to docs `indy-plenum` has extendable architecture - you can define your own plugins to customize the DLT behavior. `indy-node` is such kind of a plugin for `indy-plenum` that provides logic related to schemas, credential definitions, etc. But there is no any requirement for `ledger-next` to have multiple ledgers or to be compatible with `indy-plenum` plugin architecture. Why?

cam-parra (Tue, 02 Apr 2019 13:41:28 GMT):
AlexanderVtyurin No decisions have been made about the kind of consensus algorithm we will use in ledger-next. But @ashcherbakov or Sergey K can explain more

AlexanderVtyurin (Tue, 02 Apr 2019 13:43:06 GMT):
@cam-parra Yes, I know. I'm asking about requirements for `ledger-next' DLT. You can find these requirements in kick-off slides.

AlexanderVtyurin (Tue, 02 Apr 2019 13:43:06 GMT):
@cam-parra Yes, I know. I'm asking about requirements for `ledger-next` DLT. You can find these requirements in kick-off slides.

mwherman2000 (Tue, 02 Apr 2019 14:42:48 GMT):
A number of people have been asking me for clarification wrt the differences between the following 2 DID grammar specification efforts: • Hyperonomy Universal Decentralized Identifier URI specification (did-uri-spec) • W3C Decentralized Identifiers specification (did-spec) The webcast below (the 4th in the series and the last - at least for the next few weeks) provides a detailed comparison & relative positioning of these two efforts and how they work great together: Decentralized Identifier URI Specification (did-uri-spec): “DID ABNF” Comparison & Coexistence v0.22 https://www.youtube.com/watch?v=h_TOZ7YvYXg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3

mwherman2000 (Tue, 02 Apr 2019 14:43:35 GMT):

Clipboard - April 2, 2019 8:43 AM

VS09 1 (Wed, 03 Apr 2019 06:35:53 GMT):
Has joined the channel.

esplinr (Wed, 03 Apr 2019 17:29:38 GMT):
Everyone: It's time for an April update on progress toward staffing a formal project. Evernym plans to work on PBFT view change over Q3. Once that is completed, we will be in a good place for supporting ledger adoption for some time to come. However, we would like to start working on a future ledger in Q4 2019. I have incorporated that into my budget planning, and it looks to be workable for us. Who thinks they can be ready to start before October? That will drive our conversation around requirements gathering and research tasks. We also want to assist those who are planning to contribute in learning about the current ledger implementation so that we can make informed decisions together.

mwherman2000 (Fri, 05 Apr 2019 16:08:15 GMT):
Me

mwherman2000 (Fri, 05 Apr 2019 16:08:15 GMT):
Me ...and I would value the ledger training

esplinr (Fri, 05 Apr 2019 21:25:38 GMT):
@mwherman2000 That's great! I'll reach out to you next week to discuss how best to proceed.

silviu (Sat, 06 Apr 2019 19:13:42 GMT):
Has joined the channel.

mwherman2000 (Tue, 09 Apr 2019 16:25:04 GMT):
Latest webcast ...this one drilling down on Domain Specific DID Grammars ...click the settings gear in YouTube and run it at 1.5-2.0x speed: Universal Decentralized Identifier URI Specification: DSDG Matrix and $supportedCapabilities (15 minutes at 2.0x) https://www.youtube.com/watch?v=LgbznYPnJvY&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=4

mwherman2000 (Tue, 09 Apr 2019 16:25:20 GMT):

HBB-did-uri-spec-supportedCapabilities v0.24-matrix.png

pmaruindy (Wed, 10 Apr 2019 02:46:46 GMT):
Has joined the channel.

amundson (Thu, 11 Apr 2019 14:23:31 GMT):
@esplinr which PBFT implementation is that in reference to?

esplinr (Thu, 11 Apr 2019 15:55:28 GMT):
@amundson Our current plan is to implement PBFT view change from scratch in our current RBFT implementation in Indy Plenum.

mwherman2000 (Fri, 12 Apr 2019 18:00:02 GMT):
What do you think? I'm interesting in exploring a port Indy to the Stratis Platform, a general-purpose, smart-contract based blockchain written in C#/.NET Core (node wire-level protocol compatible with BITCOIN CORE). The Stratis team are the maintainers of the official (.NET CORE version of BITCOIN CORE (NBITCOIN). https://stratisplatform.com/

mwherman2000 (Fri, 12 Apr 2019 18:00:02 GMT):
What do you think? I'm interesting in exploring a port of Indy to the Stratis Platform, a general-purpose, smart-contract based blockchain written in C#/.NET Core (node wire-level protocol compatible with BITCOIN CORE). The Stratis team are the maintainers of the official (.NET CORE version of BITCOIN CORE (NBITCOIN). https://stratisplatform.com/

mwherman2000 (Fri, 12 Apr 2019 18:00:02 GMT):
What do you think? I'm interesting in exploring a port of Indy to the Stratis Platform, a general-purpose, smart-contract based blockchain written in C#/.NET Core (node wire-level protocol compatible with BITCOIN CORE). The Stratis team are the maintainers of the official .NET CORE version of BITCOIN CORE (NBITCOIN). https://stratisplatform.com/

mwherman2000 (Fri, 12 Apr 2019 18:01:55 GMT):
More generally, I think there are a variety of ways to use Blockchain #DumbData to store DID and other Indy documents on a blockchain: *Blockchain #DumbData: Best way to safely store secure, immutable, auditable, historized, permanent data on a blockchain* https://medium.com/@mwherman2000/best-way-to-store-secure-immutable-auditable-historized-permanent-data-stored-on-the-69a874ee17cd

mwherman2000 (Sat, 13 Apr 2019 14:59:22 GMT):
A bit off topic but does anyone have a schema definition for a DID Document? ...that is, a meta description/definition outlining the overall structure of a DID Document, the mandatory elements, provisions for optional elements, ...that sort of thing. Effectively, the spec text for a DID Document from the DID Spec (https://w3c-ccg.github.io/did-spec/#did-documents) expressed in some sort of schema definition language (e.g. JSON schema?)

nage (Wed, 17 Apr 2019 20:42:29 GMT):
@ashcherbakov this seems like it might be an analogous building block for state proofs on sawtooth https://github.com/hyperledger/sawtooth-rfcs/blob/master/text/0030-pbft-consensus-seal.md

Dan (Wed, 17 Apr 2019 20:53:14 GMT):
Has joined the channel.

Dan (Wed, 17 Apr 2019 21:33:50 GMT):
Yes, I was catching up a bit late on that one and you'll see where I was trying to nudge it towards BLS sigs. I would be very interesting in drawing that closer to state proofs. When some of us had spoken in the past we identified useful overlap in sawtooth and plenum. One of the few gaps was RBFT or a similar PBFT communication that could be used to build the aggregate signatures. Now that Sawtooth has PBFT it seems like this gap is very addressable.

esplinr (Wed, 17 Apr 2019 22:30:05 GMT):
Interesting. Thank you for sharing!

lijamie (Wed, 17 Apr 2019 22:35:44 GMT):
Has joined the channel.

rangak (Thu, 18 Apr 2019 23:11:11 GMT):
Has joined the channel.

mwherman2000 (Mon, 22 Apr 2019 23:00:10 GMT):
@esplinr @nage For Ledger 2.0, aside from the higher level discussions of Consensus Algorithm X, Consensus Algorithm Y, Consensus Algorithm Z, ... and PoABC is not as good as PoXYZ, etc. etc., has anyone created a lower level list of metrics/constraints? ...for example, ideal maximum block confirmation times? ...end-to-end transactions processing times (e.g. measured from signing and submission until the transaction is confirmed back to a block ina local Ledger Node's local replica)? ...other important metrics? ...characteristics?

mwherman2000 (Mon, 22 Apr 2019 23:00:10 GMT):
@esplinr @nage For Ledger 2.0, aside from the higher level discussions of Consensus Algorithm X, Consensus Algorithm Y, Consensus Algorithm Z, ... and PoABC is not as good as PoXYZ, etc. etc., has anyone created a lower level list of metrics/constraints? ...for example, ideal maximum block confirmation times? ...end-to-end transactions processing times (e.g. measured from signing and submission until the transaction is *finalized* confirmed back to a block in a local Ledger Node's local replica)? ...other important base-level metrics? ...characteristics?

mwherman2000 (Mon, 22 Apr 2019 23:00:10 GMT):
@esplinr @nage For Ledger 2.0, aside from the higher level discussions of Consensus Algorithm X, Consensus Algorithm Y, Consensus Algorithm Z, ... and PoABC is not as good as PoXYZ, etc. etc., has anyone created a lower level list of metrics/constraints? ...for example, ideal maximum block confirmation times? ...end-to-end transactions processing times (e.g. measured from signing and submission until the transaction is *finalized* and confirmed back to a block in a local Ledger Node's local replica)? ...other important base-level metrics? ...characteristics?

nage (Tue, 23 Apr 2019 03:26:07 GMT):
Beyond the metrics we have been using for token testing, not really

nage (Tue, 23 Apr 2019 03:26:59 GMT):
the best possible comparisons are usually done to the Visa and Mastercard networks. You can also make comparisons to the throughput of the DNS system, but they are "sunny day", "wish for the best" types of comparisons, not practical requirements

nage (Tue, 23 Apr 2019 03:28:11 GMT):
My experience it pays to focus on safety and finality first and then go after speed from there. You need confidence no one can take over or front run identifiers first, then speed comes after.

mwherman2000 (Tue, 23 Apr 2019 12:46:16 GMT):
I understand what finality is @nage but how are you referring to it in your comment above? ...please elaborate.

nage (Tue, 23 Apr 2019 15:04:52 GMT):
it is important to know the exact state of revocation at every point of time into the past, so ambiguity on forks causes problems knowing whether a credential a specific point in time constitutes data permissioning at that point in time (or not)

esplinr (Tue, 23 Apr 2019 15:48:51 GMT):
So far, our requirements are very general: * scale to at least a billion users, * responses must be fast and reliable in order to win the confidence of emergency first-responders, * transaction costs need to be accessible to the world's poorest populations, * privacy should be built-in I need help translating those business requirements into useful technical requirements.

Raja_Sabarish (Wed, 24 Apr 2019 08:42:26 GMT):
Has joined the channel.

mwherman2000 (Wed, 24 Apr 2019 22:18:40 GMT):
I've sent an email to the Stratis CTO and smart contract lead to get their feedback.

mwherman2000 (Wed, 24 Apr 2019 22:18:40 GMT):
I've sent an email to the Stratis Platform CTO and smart contract lead to solicit their feedback.

fimbault (Thu, 02 May 2019 09:42:00 GMT):
Has joined the channel.

wombletron (Thu, 02 May 2019 20:24:06 GMT):
Has joined the channel.

fimbault (Fri, 03 May 2019 08:32:53 GMT):
An analysis of stellar : https://sites.google.com/view/stellar-analysis

fimbault (Fri, 03 May 2019 12:13:26 GMT):
Regarding your previous questions on avalanche, to complete your spreadsheet : avalanche is leaderless, with formal proofs, weakly synchronous, low complexity to implement, major implementations are perlin.net and avalabs (currently only a demo : https://avalabs.org/snow-bft-demo). Avalabs plans to complement it with PoS to avoid Sybil attacks.

fimbault (Fri, 03 May 2019 12:13:26 GMT):
Regarding your previous questions on avalanche, to complete your spreadsheet : avalanche is leaderless, with formal proofs, weakly synchronous, low complexity to implement, planned for a significant throughput and degrades gracefully. Major implementations are perlin.net and avalabs (currently only a demo : https://avalabs.org/snow-bft-demo). Avalabs plans to complement it with PoS to avoid Sybil attacks. They also put forward the governance mecanisms that the protocol allows.

fimbault (Fri, 03 May 2019 12:16:21 GMT):
Some criticisms / reviews :

fimbault (Fri, 03 May 2019 12:16:22 GMT):
https://groups.io/g/corda-dev/message/53

fimbault (Fri, 03 May 2019 12:16:36 GMT):
https://nearprotocol.com/papers/NEAR_Protocol_Position_Paper.pdf Snowball / Avalanche [11] is a fair probabilistic consensus algorithm based on participants building a DAG of transactions. When conflicting transactions are observed, each node queries a sample of other participants to decide on which transaction to choose. This method is not applicable when transactions execute arbitrary Turing-complete program, as there is no clear definition for conflicting transactions. While the paper provides certain proofs for a synchronous setting, it is unclear if Avalanche still maintains its guarantees in an asynchronous setting. Also, Avalanche leaves no trace of the process of achieving the consensus, making it hard to identify malicious nodes.

fimbault (Fri, 03 May 2019 12:37:39 GMT):
And here is a graphical representation of self proclaimed TPS (to take with caution)

fimbault (Fri, 03 May 2019 12:37:43 GMT):

Clipboard - May 3, 2019 2:37 PM

fimbault (Fri, 03 May 2019 12:40:31 GMT):
(source : https://medium.com/nervosnetwork/forget-about-the-tps-competition-df40a45fdad8)

mwherman2000 (Sun, 05 May 2019 09:32:59 GMT):
TPS can be misleading. I like to see end-to-end average and worst case transaction times ...that is, from the moment of signing and submission off a Tx until the moment the Tx is finalized and can be read back from the local replica of the ledger. In this context, the TPS is a reflection of how many of these tasks are running in parallel (average per second). High TPS with an end-to-end Tx time of 45 seconds isn't that useful (as an example).

fimbault (Tue, 14 May 2019 08:07:23 GMT):
yes indeed (see the title of the blogpost, "forget about TPS competition")

fimbault (Thu, 16 May 2019 06:46:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-ledger-next?msg=xB5bstY96ywCm7aBw)
Clipboard - May 16, 2019 8:45 AM

ilya1w (Wed, 22 May 2019 03:53:05 GMT):
Has joined the channel.

DougKing (Tue, 04 Jun 2019 14:21:53 GMT):
Has joined the channel.

esplinr (Tue, 11 Jun 2019 23:50:24 GMT):
@fimbault I forgot to thank you for the information. It is very useful. We appreciate your collaboration in this research.

esplinr (Wed, 19 Jun 2019 15:02:58 GMT):
Has anyone looked at LibraBFT to see what we can learn for Ledger 2.0?

sergey.khoroshavin (Wed, 19 Jun 2019 15:44:45 GMT):
@esplinr Thanks for mentioning this protocol, after quick search I found related papers and it seems like LibraBFT (https://developers.libra.org/docs/assets/papers/libra-consensus-state-machine-replication-in-the-libra-blockchain.pdf) is an enchancement of HotStuff (https://arxiv.org/pdf/1803.05069.pdf), which in turn is an enchancement of plain old PBFT. I didn't dig deeply into papers, on the surface proposed improvements don't look revolutionary, however they are very sensible and can bring quite a lot of performance improvements (at least for happy path) over plain PBFT

esplinr (Wed, 19 Jun 2019 15:45:45 GMT):
Thanks for looking Sergey. Credit for the idea goes to @aronvanammers

sergey.khoroshavin (Wed, 19 Jun 2019 15:47:07 GMT):
As a side rant - moving from RBFT to PBFT (with some enhancements from Aardvark) can also can give quite an improvement in both performance and scalability and can be done quite cheaply once view change is really stable

sergey.khoroshavin (Wed, 19 Jun 2019 15:47:07 GMT):
As a side rant - moving from RBFT to PBFT (with some enhancements from Aardvark) can also give quite an improvement in both performance and scalability and can be done quite cheaply once view change is really stable

esplinr (Thu, 20 Jun 2019 16:06:03 GMT):
I hadn't noticed that Libra is also implemented in Rust.

esplinr (Thu, 20 Jun 2019 16:06:03 GMT):
I just noticed that Libra is also implemented in Rust.

esplinr (Thu, 20 Jun 2019 16:06:22 GMT):
There is a lot of synergy between Libra and what we are thinking about for indy-ledger-next.

MarcoPasotti (Wed, 26 Jun 2019 16:30:17 GMT):
Has joined the channel.

ravip (Thu, 18 Jul 2019 17:53:53 GMT):
Has joined the channel.

ravip (Thu, 18 Jul 2019 17:53:54 GMT):
Hello everyone, how do I clear the log file that is generated at http://localhost:9000/ledger/domain? It seems to have reached the max file size limit and any new transactions that are created on the ledger are not visible. Note: I am following the tutorial that is in the Education github repository.

lucasmori (Tue, 23 Jul 2019 12:22:19 GMT):
Has joined the channel.

lucasmori (Tue, 23 Jul 2019 12:22:19 GMT):
Hi everyone, i have a problem, i'm trying to use Pool.CreatePoolLedgerConfigAsync. It only accept string values, and i have the genesis_txn add in a variable string and it has array in that json

lucasmori (Tue, 23 Jul 2019 12:24:32 GMT):

That's the error message

ShashankKulkarni (Wed, 28 Aug 2019 12:40:12 GMT):
Has joined the channel.

ShashankKulkarni (Wed, 28 Aug 2019 12:40:12 GMT):
shrinivas

esplinr (Sat, 31 Aug 2019 05:41:47 GMT):
Questions like this should be asked on #indy

jadhavajay (Thu, 19 Sep 2019 18:46:38 GMT):
Has joined the channel.

amundson (Thu, 26 Sep 2019 17:16:37 GMT):
Has left the channel.

Abhishekkishor (Mon, 30 Sep 2019 03:46:51 GMT):
Has joined the channel.

ajayjadhav (Fri, 18 Oct 2019 13:36:31 GMT):
Has joined the channel.

esplinr (Fri, 25 Oct 2019 00:28:43 GMT):
Wow, 6 months went by fast! It's time when we can have another coordination conversation to discuss budgets for work on the Indy ledger. We have a call scheduled: October 28 at 11H US Pacific / 19H Central European Time / 19H Moscow Standard Time / 7H October 29 in New Zealand. https://zoom.us/j/715671233

esplinr (Fri, 25 Oct 2019 00:30:12 GMT):
We want to discuss the progress we have made in simplifying view change, and the work we want to do to simplify consensus. We want to identify collaborators who can work with us, and see how you want to contribute.

sergey.khoroshavin (Fri, 25 Oct 2019 08:14:06 GMT):
@esplinr actually according to calender it is 21H Moscow Standard Time, not 19H

esplinr (Sun, 27 Oct 2019 04:34:59 GMT):
Oh yes, thanks for the correction Sergey. I was thinking 9PM / 21H even though I typed it wrong.

esplinr (Mon, 28 Oct 2019 18:01:16 GMT):
We are getting started with the Indy Contributors call: https://zoom.us/j/715671233

esplinr (Wed, 30 Oct 2019 19:57:33 GMT):
In Monday's Indy Contributors call, we had a discussion about our concerns for the future of Indy based on the small number of contributors to Plenum. As a result, we have a proposal to the TSC as part of our quarterly report (due today): let's spin Plenum out as its own first-class Hyperledger project. You can read the rationale here: https://wiki.hyperledger.org/display/HYP/2019+Q4+Hyperledger+Indy

Yano (Thu, 31 Oct 2019 17:27:56 GMT):
Has joined the channel.

donqui (Fri, 01 Nov 2019 10:26:03 GMT):
Has joined the channel.

esplinr (Fri, 01 Nov 2019 20:33:27 GMT):
Update: we released Indy Node today with the improved View Change algorithm. There are still some bugs to sort out, but it's already an improvement over the previous release.

esplinr (Fri, 01 Nov 2019 20:34:43 GMT):
As we've analyzed the reported bugs, we see another clear cluster related to the RBFT Replicas. See https://jira.hyperledger.org/browse/INDY-2251

esplinr (Fri, 01 Nov 2019 20:35:16 GMT):
We currently favor taking a simpler approach, and moving from RBFT to Aardvark: https://jira.hyperledger.org/browse/INDY-2250

esplinr (Fri, 01 Nov 2019 20:35:50 GMT):
If anyone has any feedback on that plan, please reach out. We'll be able to discuss it in the next Indy Contributors call, or here.

esplinr (Fri, 01 Nov 2019 20:35:50 GMT):
If anyone has any feedback on that plan, please reach out. We can discuss it in this chart, or during the Indy Contributors call on Monday.

esplinr (Sun, 03 Nov 2019 04:19:55 GMT):
More details are in this presentation: https://docs.google.com/presentation/d/12zsP6jQgBCnq9XnBiMIsPFRihnh3ZcEk814jbjy7SLM/edit#slide=id.p

VipinB (Mon, 04 Nov 2019 15:35:26 GMT):
Has joined the channel.

VipinB (Mon, 04 Nov 2019 15:35:27 GMT):
I had asked about the possibility of using LibraBFT on the TSC call (actually I had mentioned HotStuff). Open source implementations in Rust are available. I have not done a thorough analysis, especially scaling in the wild. But it seems to have excellent scaling properties as well as some dedicated maintainers (notwithstanding the problems with Libra as a whole)

VipinB (Mon, 04 Nov 2019 15:37:07 GMT):
The most important properties seem to be a leader election combined with faster consensus for large replica networks.

VipinB (Mon, 04 Nov 2019 18:39:14 GMT):
Combined with an asynch/hybrid - consensus and leader election

esplinr (Mon, 04 Nov 2019 19:31:04 GMT):
Thanks for the thoughts @VipinB . I am very interested in Libra HotStuff. It does seem like a good fit for our goals. It didn't exist when we last evaluated other ledgers, so we should look at it in more detail.

cam-parra (Mon, 04 Nov 2019 19:57:07 GMT):
We have connections with the Libra folk. I won't be able to meet with them till next year but for now I may be able to ask if I can get in contact with their team.

esplinr (Mon, 04 Nov 2019 20:17:49 GMT):
That would be great. Their analysis of the technical challenges and best solutions is very similar to ours. If we started today (instead of two years ago), we'd probably take the same approaches.

vardan10 (Tue, 05 Nov 2019 09:26:16 GMT):
Has joined the channel.

vardan10 (Tue, 05 Nov 2019 09:26:18 GMT):
As per proof-of-non-revocation (https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation#presenting-proof-of-non-revocation): The prover can calculate an updated witness u by finding the product of all of the non-revoked entries in the tails file and excluding its own entry. The Prover also knows its own factor, b, because it was given its entry's index in the tails file, and can calculate u*b = e, where e is the accumulator. The prover then uses zero knowledge proof to prove to the issuer that he knows u and b using product proofs. Now let’s say the prover has 2 credential definitions, one which is revoked and one which is not. My question is what stops the prover to use u and b from the credential definition that was not revoked while sharing a credential definition that was revoked. Example: Let’s say a prover has a driving license and a university degree from a same issuer. Then the issuer revokes the driving license but not the university degree. In this case while sharing driving license with the verifier the prover also shares u and b values of university degree and not driving license (since driving licence was revoked).

sergey.khoroshavin (Tue, 05 Nov 2019 10:04:15 GMT):
@esplinr I've analyzed a bit both HotStuff and LibraBFT papers in the past - they look like a generalization and improvement over PBFT and Tenderment. If using LibraBFT codebase is not a political issue then it might make sense to spend some more time on evaluating their implementation.

esplinr (Tue, 05 Nov 2019 14:55:48 GMT):
I created INDY-2279 to help us remember to evaluate it in more detail.

eduelias (Tue, 12 Nov 2019 16:00:17 GMT):
Has joined the channel.

esplinr (Tue, 26 Nov 2019 00:23:03 GMT):
@swcurran pointed out to me today that Hyperledger Besu has two implementations of BFT. Has anyone looked at them yet?

swcurran (Tue, 26 Nov 2019 00:23:03 GMT):
Has joined the channel.

esplinr (Tue, 26 Nov 2019 00:23:07 GMT):
https://besu.hyperledger.org/en/stable/Concepts/Consensus-Protocols/Comparing-PoA/

esplinr (Tue, 26 Nov 2019 00:23:38 GMT):
Anyone familiar with Clique and IBFT (Istanbul BFT)?

sergey.khoroshavin (Tue, 26 Nov 2019 07:56:42 GMT):
@esplinr some time ago I went through IBFT papers. So, yes - in some extent I'm familiar with it.

ashcherbakov (Tue, 26 Nov 2019 10:05:32 GMT):
BTW there is another implementation of IBFT in a quite popular Quorum framework from JPMporgan: https://github.com/jpmorganchase/quorum (3.5 K stars)

ashcherbakov (Tue, 26 Nov 2019 10:05:51 GMT):
Here is an interesting paper comparing Quorum and Besu (since thet look pretty similar): https://www.coindesk.com/hyperledger-challenges-jpmorgans-quorum-for-enterprise-ethereum-crown

ashcherbakov (Tue, 26 Nov 2019 10:08:46 GMT):
An interesting quote: > Quorum has 20 engineers who engage and support developers on Slack, Github and through global meetups, the source added. > By comparison, Pegasys, the engineering team linked to Consensys which built Besu, has some 71 staffers, of which about 40 engineers are working on the core Besu client and enterprise features. In addition, there’s the support that comes with Hyperledger involving numerous channels to promote projects, meetups in every major city, and an annual global forum (next to be held in Phoenix in March) where Besu is expected to play a starring role.

sergey.khoroshavin (Tue, 26 Nov 2019 10:27:29 GMT):
@esplinr IBFT (https://github.com/ethereum/EIPs/issues/650) is largely based on PBFT, with some ideas borrowed from Tendermint (which is also based on PBFT). Funny thing - author of Tendermint actively participated in that thread. As far as I remember IBFT had issues with both safety and liveness, however I couldn't find links to relatively old papers proving that (but there are mentions in aforementioned issue). On the other hand, there are some very recent (august-september 2019) papers proving problems of original IBFT (https://arxiv.org/pdf/1901.07160.pdf) and proposing IBFT 2.0 (https://arxiv.org/pdf/1909.10194.pdf), claiming that they solved problems of original protocol.

sergey.khoroshavin (Tue, 26 Nov 2019 10:27:29 GMT):
@esplinr IBFT (https://github.com/ethereum/EIPs/issues/650) is largely based on PBFT, with some ideas borrowed from Tendermint (which is also based on PBFT). Funny thing - author of Tendermint ( ebuchman) actively participated in that thread. As far as I remember IBFT had issues with both safety and liveness, however I couldn't find links to relatively old papers proving that (but there are mentions in aforementioned issue). On the other hand, there are some very recent (august-september 2019) papers proving problems of original IBFT (https://arxiv.org/pdf/1901.07160.pdf) and proposing IBFT 2.0 (https://arxiv.org/pdf/1909.10194.pdf), claiming that they solved problems of original protocol.

sergey.khoroshavin (Tue, 26 Nov 2019 11:25:15 GMT):
Btw, it looks like authors of IBFT 2.0 papers are Pegasys employees. And Pegasys is a (start-up) company behind Hyperledger Besu

ashcherbakov (Tue, 26 Nov 2019 13:25:48 GMT):
And Pegasys is part of ConsenSys

esplinr (Tue, 26 Nov 2019 14:40:38 GMT):
Interesting. Thank you.

SigmaS 1 (Fri, 29 Nov 2019 14:19:07 GMT):
Has joined the channel.

esplinr (Thu, 12 Dec 2019 21:13:48 GMT):
User User_16 added by esplinr.

esplinr (Thu, 12 Dec 2019 21:14:19 GMT):
@avestaa has been researching various ledgers for one of his projects. I think everyone here would really benefit from comparing notes with him.

esplinr (Thu, 12 Dec 2019 21:17:38 GMT):
@avestaa You will find a lot of useful discussion in the history of this channel.

esplinr (Thu, 12 Dec 2019 21:17:38 GMT):
@avestaa You will find a lot of useful discussion in the history of this channel. It's a low volume channel, with a decent signal-to-noise ratio.

harrywright (Wed, 18 Dec 2019 17:43:18 GMT):
Has joined the channel.

esplinr (Mon, 06 Jan 2020 20:41:33 GMT):
I came across this paper on Twitter that discusses how the BFT trade-offs can be different in a "weakly byzantine environment". https://www.sikoba.com/docs/SKOR_AK_One_Step_Consensus.pdf

sergey.khoroshavin (Wed, 08 Jan 2020 09:24:51 GMT):
Thanks, this looks interesting

amarts (Mon, 13 Jan 2020 06:45:08 GMT):
Has joined the channel.

EdEykholt (Mon, 20 Jan 2020 03:29:44 GMT):
Has joined the channel.

domwoe (Sat, 25 Jan 2020 18:33:53 GMT):
Has joined the channel.

lauravuo (Wed, 29 Jan 2020 17:38:00 GMT):
Has joined the channel.

lauravuo-techlab (Thu, 30 Jan 2020 06:42:36 GMT):
Has joined the channel.

lauravuo (Thu, 30 Jan 2020 06:49:35 GMT):
Has left the channel.

NikhilPrakash (Wed, 12 Feb 2020 00:45:14 GMT):
Has joined the channel.

nacerix (Sun, 23 Feb 2020 14:39:36 GMT):
Has joined the channel.

esplinr (Thu, 05 Mar 2020 23:11:04 GMT):
Heard at the Global Forum: IBM is donating a new consensus engine to Fabric. It is true BFT and scales to 100+ nodes with high performance. It started as a hobby project by a team member. https://github.com/IBM/mirbft Paper: https://arxiv.org/abs/1906.05552 @sergey.khoroshavin

sergey.khoroshavin (Fri, 06 Mar 2020 11:10:43 GMT):
Thanks, @esplinr . I spent half an hour studying their paper and I think that this work could be a gamechanger unless authors missed something. This work builds on a well-known PBFT protocol, and manages to add "every node is a leader" property a bit like HoneybadgerBFT, but without adding requirement of threshold crypto (which is good) or removing weak synchrony assumtion (which is sad, but not catastrophic). Btw, name of one of authors (Marko Vukolic) looked familiar to me, and a quick check revealed that he was often co-authoring with Christian Cachin, who in turn is one of developers of SINTRA, which is a precursor to HoneybadgerBFT. Also Marko co-authored with Aublin (author of RBFT which we use in Indy Plenum) in their work "Next 700 BFT protocols". It doesn't look like "another hobby project" at all )

sergey.khoroshavin (Fri, 06 Mar 2020 11:10:43 GMT):
Thanks, @esplinr . I spent half an hour studying their paper and I think that this work could be a gamechanger unless authors missed something. This work builds on a well-known PBFT protocol, and manages to add "every node is a leader" property a bit like HoneybadgerBFT, but without adding requirement of threshold crypto (which is good) or removing weak synchrony assumption (which is sad, but not catastrophic). Btw, name of one of authors (Marko Vukolic) looked familiar to me, and a quick check revealed that he was often co-authoring with Christian Cachin, who in turn is one of developers of SINTRA, which is a precursor to HoneybadgerBFT. Also Marko co-authored with Aublin (author of RBFT which we use in Indy Plenum) in their work "Next 700 BFT protocols". It doesn't look like "another hobby project" at all )

sergey.khoroshavin (Fri, 06 Mar 2020 11:10:43 GMT):
Thanks, @esplinr . I spent half an hour studying their paper and I think that this work could be a gamechanger unless authors missed something. This work builds on a well-known PBFT protocol, and manages to add "every node is a leader" property a bit like HoneybadgerBFT, but without adding requirement of threshold crypto (which is good) or removing weak synchrony assumption (which is expected). Btw, name of one of authors (Marko Vukolic) looked familiar to me, and a quick check revealed that he was often co-authoring with Christian Cachin, who in turn is one of developers of SINTRA, which is a precursor to HoneybadgerBFT. Also Marko co-authored with Aublin (author of RBFT which we use in Indy Plenum) in their work "Next 700 BFT protocols". It doesn't look like "another hobby project" at all )

esplinr (Tue, 17 Mar 2020 18:45:36 GMT):
This is the most useful overview of BFT that I have read: https://www.usenix.org/system/files/login-logout_1305_mickens.pdf

esplinr (Tue, 17 Mar 2020 18:46:22 GMT):
(For those not familiar with James Mickens, he is usually at least half joking.)

echo.harker (Tue, 17 Mar 2020 19:01:30 GMT):
Has joined the channel.

kumar89 (Wed, 25 Mar 2020 17:27:27 GMT):
Has joined the channel.

mohammadhossein73 (Sun, 29 Mar 2020 05:49:13 GMT):
Has joined the channel.

daveek (Fri, 10 Apr 2020 21:04:50 GMT):
Has joined the channel.

rickkce (Fri, 10 Apr 2020 21:17:47 GMT):
Has joined the channel.

rickkce (Fri, 10 Apr 2020 21:17:49 GMT):
Hello guys, I'm currently applying for a German scholarship which is similar to google summer of code. This program is supporting me for three months and in exchange, I can contribute to an open-source project. I'm looking for a topic I can work on and a mentor who supports me when I reach a dead-end and gives me helpful tips to integrate into the main project. I was recommended to check this channel because I am interested in blockchain implementation and I think I can make a valuable contribution to ledger-next since I have previous experience with other Blockchains like Cosmos that is working also with Tendermint. I checked already the "Ledger 2.0 Kick-off" doc. Is there anyone that can support me and would be interested to create a work plan which I can use to apply for the Scholarship? The program starts in July, however, the deadline for the workplan is in a couple days. I thank you in advance for your help.

ultimo2020 (Tue, 14 Apr 2020 20:40:23 GMT):
Has joined the channel.

Hanu7743 (Tue, 21 Apr 2020 15:02:06 GMT):
Has joined the channel.

esplinr (Thu, 30 Apr 2020 03:03:28 GMT):
@rickkce I apologize for not responding sooner. I've been heads-down with a client project.

esplinr (Thu, 30 Apr 2020 03:03:54 GMT):
Did you put a plan together for your project?

HichamTAHIRI (Sun, 14 Jun 2020 15:54:54 GMT):
Has joined the channel.

Diiaablo95 (Wed, 17 Jun 2020 09:48:54 GMT):
Has joined the channel.

esplinr (Fri, 31 Jul 2020 15:43:00 GMT):
From @nage > Evernym is interested in collaborating, but I don't know who else would participate. I've been encouraging people interested in this topic to join #indy-ledger-next .

esplinr (Fri, 31 Jul 2020 15:44:23 GMT):
From @nage It looks like Libra core has added an observer node-like tier and as a result has a state proof equivalent worth experimenting with.

esplinr (Fri, 31 Jul 2020 15:44:46 GMT):
@sergey.khoroshavin : It looks interesting.

esplinr (Fri, 31 Jul 2020 15:45:14 GMT):
It would be cool to collaborate with others to explore the potential of libra-core as an indy equivallent.

nage (Fri, 31 Jul 2020 15:46:06 GMT):
We would still need to port over an indy layer to move smart contracts, but the regulation push with libra has brought them much closer to what we have in Indy

esplinr (Fri, 31 Jul 2020 15:46:32 GMT):
Very interesting.

GianlucaPinto (Thu, 24 Sep 2020 13:41:47 GMT):
Has joined the channel.

GianlucaPinto (Thu, 24 Sep 2020 13:41:48 GMT):
hi all, how can i do for get the timestamp of a credentials ? thanks

esplinr (Fri, 25 Sep 2020 13:30:24 GMT):
Best to ask in #indy-sdk

kei32bit (Fri, 13 Nov 2020 01:13:51 GMT):
Has joined the channel.

ArturPhilipp (Thu, 10 Dec 2020 12:16:09 GMT):
Has joined the channel.

rjones (Sat, 12 Feb 2022 22:00:04 GMT):
Has joined the channel.

rjones (Sat, 12 Feb 2022 22:00:05 GMT):
[Please move to Discord](https://discord.com/channels/905194001349627914/905205711850594336)

rjones (Sat, 12 Feb 2022 22:00:05 GMT):
[Please get an account on the Hyperledger discord](https://discord.gg), then [join Indy](https://discord.com/channels/905194001349627914/905205711850594336)

rjones (Sun, 13 Feb 2022 01:34:54 GMT):
Has left the channel.

rjones (Wed, 23 Mar 2022 17:25:42 GMT):