Our COO recently posted a Medium Article where he analyses the latency and finality in different cryptocurrencies. You can read it here.

Hey guys, the final part of “Anatomy of a transaction” can be read here. You can check the entire series on our Medium page.

Hey guys, here’s the 3rd part of “Anatomy of a transaction”. Here we describe how a valid transaction is broadcasted and eventually accepted in the network, and how the double spends get rejected. You can read it here.

Our second article which describes the details of our protocol is out! You can read it here.

Blockchain was the first solution to the distributed ledger problem. It is old and reliable, but it definitely doesn't scale.

We started a series of Medium articles to better explain details of our protocol. You can read the first article here.

Our current implementation supports 20,000 transactions per second, with a confirmation time of 300-600 milliseconds. We do plan on making the code open source in the future.


Not sure what you mean, but we have accounts, similar to Ethereum.

Hey guys, we've tried to explain the fundamentals of the Distributed Ledger problem in our latest Medium article. Any feedback is welcomed .

Hey guys, check out this GIF showing a transaction in the Blink Wallet https://twitter.com/theblinknet/status/981900386108956672 .

It's amusing how you start by saying who are we (the people that built it) to decide on distribution, and then tell us how we should do distribution. 
We said a couple post ago we want to distribute the coin as wide as possible, we just haven't figured out how exactly, and want to focus on the tech right now.
We'll take as much input as possible before doing anything, so we'll think about what you said, even though you seemed unnecessarily aggressive.

Thanks!
Even if Bitcoin manages to get a lot more transaction per sec, with lower fees (pretty hard in itself), we still think our major advantage is in the latency to almost certainly confirm a message in under 1 sec.
Low confirmation times matter a lot more for microtransactions than for large cash transfers.

Since any transaction is never just accepted or rejected, but rather just increases in certainty with more information, the way we use lockers we think should be able to give high confirmation certainty in just 2 hops over the internet, which is in the order of hundreds of milliseconds.

Hey, I agree with you that there's no reason for most people to put money in a project just because of a whitepaper which very few people can actually go through. That's why we just want people to try to understand the algorithm and give us feedback now.

Most of the Bitcoin supply has already been distributed to less than 0.1% of the world's population, I don't think that's a very elegant delivery mechanism though. Neither would an ICO solve this issue, which is why we first want to get some seed investment from qualified investors (that's why we're not posting here to raise anything). In a competitive market, having the best tech is not enough to win, you still need Marketing and PR. Bitcoin is not that complicated to implement compared to our protocol, and came at a time when you didn't need marketing budgets to get adoption.

After that, we want to do a long-term coin distribution, where as many people have access to it, while allowing us to raise capital for development. Calling it an ICO is a bit of a stretch, but there's no great terminology since everyone seem to just try to raise as much money as possible quickly. Frankly, we don't know yet the details of this phase, but it's a separate problem from the consensus protocol, that we can provide details on later.

Agree that the paper is hard to read, and that's partially unavoidable due to the complexity of the algorithm, and how all the parts are actually needed to work together. What exactly would you say is babble?

We haven't seen anyone understand the way the system works in under a day (including any of us), and you started making comments about an hour after we posted, so pretty sure you just skimmed through the paper.
It's understandable that you may not have the time to do a rigorous analysis, we're just some guys asking for advice on a forum, but what's the point in asking for attack vectors of a thing you don't understand?

We've actually pointed you to page 31 in a previous post, where we explicitly state that a majority of the network needs to agree on the state within a certain number of rounds, or else it's considered void, penalizing nodes essentially. Can you say why this doesn't say that consensus will freeze in the worst case?

There are a lot of other bits of analysis we could have added to the paper, but it would have made it over 100 pages long, without anything essential to understanding the core, since we've seen these naturally clear-up for the people that understood the core protocol, realizing that those issues apply to blockchain-based consensus and not to our algorithm.

I know you may be used to people posting crap algorithm that are easily dismissed by showing their obvious holes, and it's understandable why you'd fire some automatic arguments, they're usually valid. Still, I hope you can see that's not the case with us and that we're working on different assumptions than blockchain consensus developers.

Nothing the lockers say finalizes the state. A locker signed transaction needs to be confirmed by a majority of nodes to be accepted.
Like previously stated, consensus is delayed until approved by the majority, even with the risk of voiding the round. The fact that you keep mentioning a fork means that you're not very clear on how the algorithm works. Did you understand this from the consensus section? It could be the paper is not clear on it, but please try reading it again.

Our intention is to have an ICO as quickly as possible, but first we need to raise seed capital and to build a team of great advisors/build a community around the project. We believe this project has top 10 potential, so we don't want to rush things.

In the case you presented, if 10/20 lockers appear offline and later they try to broadcast the transactions for which they were the assigned lockers, the other nodes would simply ignore those transactions. Honest nodes always ignore transactions that were signed more than 2 rounds in the past. But indeed, there could be a conflict if the lockers come back online in the middle of the following round.

After the transaction broadcasting phase follows the sync & commitment. During this second phase nodes solve any kind of inconsistencies, e.g. revert double spends. Only after syncing there is a commitment vote on the global state some X rounds in the past. Anything that happened during those last X rounds is still subject to change through the sync process. A fork can only happen if the network doesn't agree on the commitment state.

As for the propagation times, check out this screenshot from the paper you linked: . Our transactions currently have ~300 bytes, that's why the propagation times of Blockchain based protocols don't apply to us.

We're trying to prove in the paper that actually there's no such case where a fork happens involuntarily.
That's the purpose of the synchronization phase, to make sure that forks happen only when nodes explicitly want them to happen. Nodes will keep making round proposals until they're sure that they've got a consensus. If nodes can't agree within a certain number of rounds, it's actually in their interest just to void the round.
If you're aware of a specific case when an involuntary fork can happen, please let us know.

Do you have any reference for the 15s gossip time? All of our testing showed much lower numbers in the order of a few seconds at most, if all you needed to gossip what in the order of a few hundred bytes. Blocks are much larger though, and that's why I'd imagine a disparity could come from.

There's no way to create a fork on those transactions, since the majority of the network needs to receive them in the next round at most, to confirm them. Think of lockers as a pre-validation step, gatekeeper to the system if you will. Since those transactions were not confirmed by a majority of the network, that means that those transactions will never be accepted, and everyone the applied them will undo them.

Between the time a transaction is signed by a locker and confirmed by the network, it's essentially pending. We expect running a full node to be something that only servers with decent processing power and good internet should do, so delays are rare. The latency between almost any pair of servers with decent internet in the world is less than 300ms. Even if delays happen between some pairs of nodes, there would have to be a global internet problem in order for a majority of the network to have these issues.

In essence, we want to optimize the system as much as possible for the average case, while still being robust for any worse case.

Our entire algorithm is focused around the idea that independent transactions can be treated independently. So in that round all the other transactions will be accepted, except those that were performed on accounts which had unresponsive lockers.

The accounts need to wait for the next round, if the transactions are not signed by the lockers they are invalid and won't be accepted by the network.