Quote from: americanpegasus on August 20, 2015, 05:35:28 PM

Quote from: Fuserleer on August 20, 2015, 05:11:53 PM

Indeed, from what information I been able to dig up, this claimed 100k tps was in a closed and controlled test environment, with a specifically constructed ledger, local LAN and almost certainly some very high powered hardware.

Kinda like when you buy a new car and the manufacturer states a 0-60 time of 6s, yet try as you might you cant get it below 7! That's because it was controlled, super grippy tyres on a super grippy test track, a drop of fuel in the tank, spare wheel out, seats out, starved driver that weighs only 6st

Whoever you are, you seem to be an expert in these matters. Aside from the stolen code, lying dev, and other FUD (well deserved) surrounding Vanillacoin, what is your opinion of their claimed zerotime protocol?

They say it let's you confirm transactions in less than a second and respend them as well. It also is supposedly very scalable.

I've heard it described as everything from hogwash to interesting. I'll be following you as we go forward; looking forward to what you have to release.

I cant comment on the matter of FUD, nor the accusations of lying etc....I'm far to busy to be concerned about those kinda things.

I can comment on what I have read in the paper, I haven't looked at any code, and I only briefly got into the paper, so take these following thoughts as you will.

It seems to me though, that ZT is susceptible to Sybil attacks, which can in turn lead to a DoS of the ZT feature for most of the network.

If there is a consensus conflict on the lock of a particular transaction, then the network goes into "defense" mode regarding that transaction and has to wait for a full confirmation before it can be spent. This is the right thing to do, and ensures that double spends are not possible (assuming the rest of the algorithms and code are correct).

However, it seems trivial to set up a number of nodes operating a Sybil attack that willingly cause conflicts on these locks, which means that a large portion (or even all) of transactions are forced to wait a confirmation, this of course makes ZT inoperable, and could be attacked endlessly.

As I said, I only briefly read the paper and didn't follow up on it in anyway, there could be things missing from that paper that could relieve these concerns, so take from my opinion what you will, and that it could be wrong due to lack of research on my part.

Quote from: americanpegasus on August 20, 2015, 06:12:19 PM

A long term project that is going to need a new name for launch, but I will look into it. I love scratch code that does new and innovative things and this sounds like genuine conversation, a refreshing change from the usual bitcointalk shilling.

Heh, the name might be a bit 'cute' but it does what it says on the tin, and Joe public love cute names Wink