Quote from: jl777 on March 25, 2015, 03:59:51 PM

I have started to divulge some details about my crypto777 library in slack, Azeh used to cross post slack here. I am too busy coding to have much time to do anything else (literally), so I count on the community to keep up to date.

James

We recently got slackline linked back up so I'll be able to post slack logs again.

Been a bit busy lately as well, but I'll resume regular Slack Log updates every 2-3 days.

Quote from: whetherman on March 25, 2015, 04:10:00 PM

jl777 [2:34 PM]
cross posted:

jl777 [2:36 PM]
InstantDEX GUI is almost ready for beta, I got virtual orderbooks working (and it is being displayed) for any assetA/assetB (or assetB/assetA if you like it that way)
today I will debug the automatic trade clearing of such dual orderbook entries
each one will have the magic API sequence needed to do the trade and I expect over time I will keep adding more and more methods for trade completing

jl777 [1:48 PM]
crypto777 library is my new sourcebase that I started writing a couple weeks ago, I am combining ideas from TF, new tech from CfB, and just doing what makes sense to me. turns out I am doing things that are similar to previously described http://ftp://intranet.dei.polimi.it/users/Carlo.Piccardi/VarieCda/ArticoliStudenti/i15.pdf, https://www.cs.unm.edu/~saia/papers/RandomBeacon.pdf and others, but it is a method that I will use to solve network security, quantum computer attacks and pangea realtime betting. It is currently able to do pretty fast blocktimes on my 128 thread localhost network, but I still need to add command processing so it can add new nodes, catch up if it falls behind, etc. The consensus mechanism is totally abstracted out from the block contents, so a plugin can be created for any new tx type.

I believe I improved on BCnext TF, at least I have a method to practically do thousands of tx per block, with a very fast blocktime, but this is still "theoretical" I havent coded it yet, but it is "only" a distributed network application level complexity once the decentralized consensus is taken care of. The big problem is what to do with all that data! this I dont have a solution for yet, but I do have ideas and once the older projects go into maintenance mode, I will have time to experiment

mr_e [2:10 PM]
Is this using btcd or is it a completely separate "coin"?

jl777 [2:36 PM]
the crypto777 "coin" (I think I will name it CLOCK as the blocks come out like clockwork) is a framework to add a decentralized consensus onto anything, eg. pangea chips, but I am also investigating BTCD sidechains as it makes no sense to release yet another coin when you can enhance an existing one. CLOCK supports the concept of a ledger, which is simply a balance tied to an account and there are transactions that modify the ledger. I use 48 byte signature and 32 bytes for simple tx, but all the tx handling I would prefer to be totally abstracted away from CLOCK itself.

I have worked hard to make the code as simple and easy to understand as possible. With the line count being so low, it becomes feasible to get a full code review for any and all flaws. The temptation to contaminate the consensus mechanism with blockdata is quite high though... But if I can totally abstract out the blockdata semantics, then it will be a framework for any sort of data consensus, in realtime, that a subset of nodes can maintain. So a node would subscribe to a tx stream type X, Y and Z and only have to deal with them and if a tx type B is having a problem, it would just mess up ledger B, while all the other ledgers just keep on going. So like a blockchain OS, you can run multiple "processes" but just one consensus chain. My breakthrough idea is to overlap the time variable consensus generation with the actual blockchain data, since the consensus is only about which nodes are to become generators (no tx data at all), there is little room for disagreement, forks, etc. and this chain builds very fast. <2 seconds in my localhost test network of 128 threads. I have a logN network topology, so add 6 hops at worst case 500 milliseconds each hop still gets us to 5 second blocktimes for the consensus chain.

now we have a consensus chain growing once per 5 seconds and that means the data chains can be any time above this and it will be like a CLOCK

Since the codebase is so small and I fully understand it, I can start to solve the more difficult issues, like a backed and pegged fiat crypto, realtime ledger consensus, hmm actually I think those are the only two unsolved things left

so combined with the other improvements, BTCD is quite a sleeper now

btcddev [2:44 PM]
:smile:

Thx for that Whetherman!