Our supporter thinks that I should provide another round of DEX test without actual fund / money.
This to show what our DEX is capable of & the actual stability of it.
In the meanwhile, I could also find proper team for the future.
I can't release actual DEX without proper power to handle the possible issue.
If you all think this is the better solution for now, please thumbs up, else thumbs down
However, please rest assured that Infinex has been my focus in the past year. So, it has been and will always be a huge part of my life.
That being said, I would like to thank you for all your time, support, believe, and encouragement so far. Again, I am very sorry and very disappointed in myself for not being able to deliver the discussed InfiniDEX at this moment.
Infinex coin will continue to be exchanged – there will be no change on that part. The website, seed node, and channel will continue to run as per normal.
Lastly, do you mind if i ask you for a favour?
If you have anybody you know that can help me in developing a strong future Infinex, could you please take a bit of your time to send me his or her résumé and a brief introduction to email@example.com? Kindly note that I will try my best to reply but delays will most probably be inevitable.
It has been a great past journey for Team Infinex. Here’s hoping that it has been a great one for you, too.
Looking forward to the future Infinex.
Dear Infinex Supporters,
As you all know, the safety of your funds that you are planning to invest in the future InfiniDEX - the decentralized exchange powered by Infinex - is of my top priority.
With the recent hacking and regulatory issues, such as what has happened to Cryptopia, Maple Exchange, and EtherDelta, I have spent countless nights to think of what is best for InfiniDEX... My limited resources, lack of experience, and next to none background in this matter does not help.
It is with heavy heart that I truly realized own limitations in the last three crunch days.
As such, I have decided to postpone InfiniDEX indefinitely. This does not mean that InfiniDEX will cease to exist.
I have high hopes that in the future, I will be able to assemble a strong team that can help me build the secure InfiniDEX that everybody wants; the InfiniDEX which can comply even to the strictest government standard.
But until then, I need to apologize to all of you that my break in Infinex is imminent. This break can last for one year, two years, or even for a couple of years.
I would like to apologise for the late announcement but I need to postpone DEX Beta for 3 more days.
New date for DEX Beta: 07 March 2019 - 00:00 GMT.
Reason: minor complication, settling in progress.
Please give me 3 more days for it, many thanks in advance 🙏 🙏 🙏
Recently I'm adding the function of balance transfer between users, pair cross trade and escrow service (consider as new types of functions).
With the addition of function to DEX network, I would need to do a lot of ensuring of the message flow in correct way which is truly complicated.
Latest changes (which took a lot of my time to rethink, redraw & reinput):
Whenever DEX network data flow to MN, when that MN is not fully complete its sync yet, it would put that generic message (pre process) into 1 big box.
That single big box would contain all the data the MN receives before it fully sync.
So the moment the MN done it's sync, it just need to get the message from the single big box, process it into different categories as original & its done.
This truly make my life easier by 10x (huge reduce in complexity while maintaining that every message is well processed).
Recoding the above job took a lot of time due to I need to remove a lot of old functions in 30 classes and create a single generic class to contain it.
With that above, I would announce DEX Beta to start on 04 March 2019 - 00:00 GMT
Get back to work, truly a lot of stuff to focus in
Hi guys, it's been a tough 2 weeks as I found 1 design issue with DEX that I really need to change it to solve the complexity issue.
The issue is in the initial synchronisation part.
Its where when new MN being setup as node for DEX, when they need to synchronise partial data of the network (in the part that they in charge of).
Main design of DEX is that data would flow in the network non stop, iregardless whether the MN done its sync or not.
Previous design is something like every MN have a lot of boxes (containers) to contain data that they receive but haven't process yet due to sync underway.
The main issue in above is that for every new types or categories of task that I add to the network, I would need to add and take care of additional box (container), to make sure that they would process it once done sync.
This part cause a lot of complexity during programming as every time a message is received, I need to make sure the MN remember to process the different types of message in different containers after they done the sync.
Let me try to boost up the confidence slightly for everyone.
We took a very long time to develop InfiniDEX from scratch.
InfiniDEX could be the truly first Decentralised Exchange running over MN network, no single point of failure, breaking paradigm of existing mindset where MN are only nodes without much purpose, costing $ and only for people looking for high ROI.
With InfiniDEX, MN are given a purpose to serve, to process, to earn actual revenue.
Lastly I'm sorry for such a long wait, continuous delay and the recent fiasco of inconsistent block issue, miner dumping issue, marketing rebrand / refresh.
We would start to solve all those issue.
We hate delay, the same as everyone else, we are also frustrated, we are holding strong to continuous development for best of all of us
This would be the last announcement before the next DEX Beta test, I look at it next week (at the moment not looking to modify code further)
Weekly update for everyone.
We are doing slight changes to the core code, creating commonly used term as template and link it to certain number.
Simple term like:
"Withdraw successfully performed", link it to number 128.
So when client side received code 128, it would be interpreted as above with added formating.
The template could be added through live network as we run it.
Reasoning is to improve efficiency in network transfer, reduce network load & reduce memory usage in MN side.
Previously we are using standard text transfer but it's highly redundant.
The memory saved & network bandwidth saved is quite significant over the course of DEX.
Next thing we are changing in core code is in the implementation of bit flag enum.
It's the next upgrade from the first point, where multiple statuses (code 128, code 32, etc) are combined into single object.
It help save memory and the most important point in that it opens up the possibility to have more data available in single container.
Example of previous implementation:
UserWithdrawStatus - UserRequest
BalanceMNWithdrawStatus - ReleaseApprove
WalletMNWithdrawStatus - PendingConfirmation
After some wait, user didn't receive withdrawal, so it send a report, modifying first status into:
UserWithdrawStatus - WithdrawMissing
BalanceMNWithdrawStatus - Checking
and goes on
With above, original status would be gone & replace with new status.
WithdrawStatus - UserRequest | ReleaseApprove | PendingConfirmation | WithdrawMissing | Checking | etc
With latest implementation, we could know what flag have been set before (more data available), saving space by combining 3 objects into single object.
It's more hardcore, slightly more complicated but we believe its better for the long run.
Current implementation issue on above technique:
IMO, mining pool unable to support dynamic difficulty on every block, thus mining pool side code need to update (I'm busy with DEX thus don't think I can add the code for that).
Changing difficulty retargeting would be similar to consensus change, wallet update would be required in exchange (CB charge 0.5 BTC for consensus change wallet update).
Above is just my personal idea to contribute to PoW, hope this could help Crypto in whatever tiny little bit it is.
Average block time: 90 seconds
Desired minimum block time: 60 seconds
Variable decay time: 5 seconds
Block 1 time: 07:00:00, difficulty 100 (normal difficulty)
Difficulty for next block
Time: 07:00:01 (first second), difficulty 1000, extremely difficult to mine
Time: 07:00:06 (6 seconds pass), difficulty 950
Time: 07:00:11 (11 seconds pass), difficulty 900
Time: 07:01:00 (60 seconds pass, intended minimum time, lowering difficulty to medium level), difficulty 200
Time: 07:01:30 (90 seconds pass, intended block time, lowering difficulty to normal level), difficulty 100
If block found, repeat cycle as above (with different difficulty from average hourly block calculation)
If block not found yet, time: 07:02:00 (120 seconds pass, lowering difficulty to easy level), difficulty 30, easier to mine
With above logic, it would allowed for a more consistent block time (as mega miner won't be able to find 30 blocks in span of 1 minute and leave, as every next block difficulty would be extremely high before slowly decaying down).
Security should be stronger against previous design (even when one of the block is mined at lower difficulty) as nobody could mine consecutive blocks.
Initially I did thought above plan to prevent 51% attack. After some calculation here & there, 51% is still possible (although much difficult) as mega miner could still rewrite previous 40 blocks according to the timestamp with matching difficulty.
Next thing I would like to contribute some of my thought process in advancing PoW in the issue with mega miner mining low difficulty block & leave when the difficulty is high (selfish mining) causing inconsistent block time (which affected majority of low cap PoW coin), causing some block took hours to find (which is also bad).
A variable difficulty retargeting system on every single block as per last block time (decay difficulty).
The design philosophy is in:
Every single block difficulty is dynamic decay downward (meaning difficulty would adjust downward for every n seconds the block is not mined)
After a block is found, the next block, initial block difficulty would be very very high (with the intention to have at least how many x seconds before next block is mined)
Average blocks per hour calculation need to be maintained.
Another bad day for crypto exchange:
Cryptopia has been hacked.
There are no info how many types of coins have been hacked but according to Cryptopia, its "Significant Losses"
Creating a secured exchange is very hard, especially with centralised exchange where single point of failure would cause huge damage.
Our own custom design of IFX DEX, where every MN handling different task (also every MN handling different coin), in logical sense, hopefully be better 🙏
We are not using any source codes from the market for the DEX, 100% designed from scratch by IFX dev.
Hopefully with the uniqueness, we could achieve better security & safer exchange for@everyone.
Recently, 51% attack seems to be a norm as more specialised miner released into the market, easily purchasable hash from Nicehash, smaller miner giving up leaving only mega miner in operation.
With 51% attack, the main target & biggest loser would definitely be exchange.
Increasing block confirmation alone could reduce chance of 51% attack but as mega miner growing stronger, block confirmation need to set even higher which in the end would just cause user to feel frustrated due to long wait of deposit time and lesser attractiveness for user to use.
I'm trying to find a balance on the number of block confirmation together with additional code to detect irregular block discovery.
A lot of thought process are being planned to reduce chance of 51% attack.
I have a lot of plan in brain but it's hard to explain it out with plain word so I would just leave short info as above.
A minor announcement for@everyone, to keep everyone updated on what is going on & happy new year!
IFX dev team plan to roll out DEX Beta in 1 - 2 weeks timeline.
The Beta should be good for trading, deposit & withdrawal using new UI, not much stuff (news, info writeup, faq, etc) in it yet (we spent most of the time in core).
We would make the UI better & better as we develop (most important is first core code that need to be stable & correct)
Coin listing process has not been finalised yet, we are looking for high automation and decentralised way with proper security & ease of upgrade, to make IFX Dex truly unique & easy to maintain (a lot of thought process going on).
At the moment we are adding new node task, in charge of receiving issue reporting between nodes, this is to make dev team easier when we need to troubleshoot any failing part during DEX.
Any deposit & withdrawal issue, hopefully the automation feature inside the core code is working well (testing is definitely required, issue reporting would be routed to above node also)
We would release the date once we have the exact executable for people to download & run
Current time is 01/01/2019 - 00:00 GMT
So this should be universal time for me to wish
"Happy New Year 2019"
Wish Infinex be a great success starting from year 2019!
Wish everyone is happy & healthy all the time!
In regards to the activity daily in discord, yes, I did read up all the messages & get to understand everyone point of view.
It seems that PoS is getting more & more support day by day.
Miner mentality is different from years ago, they need to get $ to support their operation, so I can't blame them in whatever way they did, it just that IFX need to evolve as we move.
My main priority is getting DEX Beta out first.
Once it's proven running well, during entire network upgrade process (every MN to be updated), it could be the point where we switch from PoW to PoS.
1 step at a time and hopefully correct sequence.
Enjoy the holiday guys & stay with us for great things ahead!
As always, last word from me, I'm always around for IFX.
DEX Beta would release the moment I could achieve almost full automation, developing hard for it.
This may sounds awkward but I'm too passive recently causing panic, euphoria & huge price dump.
I hope that those with available fund could help maintain certain price & make everyone calm & happy.@everyone
I'm truly sorry but I always think good for IFX & everyone.
Currently we split the task to about 20+ types that every IFX MN would have different roles they in once we goes live to make sure everything would move well on its own gear.
Code base is huge & truly complicated, a lot of in depth planning & continuous revision being done.
Also we are trying to reduce the maintenance required to be done when hosting their own wallet by setting up a lot of code to provide automated support when there are issue with deposit & withdrawal
What is automated listing process:
Other coin dev preparing all the required stuff (code that we would prepare to be added into their source code), hosting of their wallet, intercommunication with IFX MN on his / her hosted IFX MN with their coin wallet.
Requirement for listing:
1 IFX MN.
Why we let the other coin dev host their own wallet:
We have been consistently thinking on the current issue with available exchanges. Some coin dev need to update their wallet. Requesting wallet update support is time consuming & costly for the other coin dev & it would be confusing for InfiniDEX team. Imagine when we grow huge & a lot of coin dev request for coin wallet update, we would need to verify the person contacting us is really the other coin dev, need to make sure update the correct node, etc.
By hosting their own wallet together with IFX MN, the IFX MN that they use would automatically be assigned & securely verified, no other people could change the content without having access to the node.
What about the security aspect when its the other party who is hosting the wallet:
When you invest in other coin, automatically you believe in the development of the other coin. It also eliminate the point where fingers pointing between exchange & other coin dev when issue arise.
By doing it this way, we could make sure all the update & proper maintenance being done by the other coin dev itself.
By using automated listing process, listing process could be faster, better, more secure (no scammer impersonating as IFX team).
IFX team would have more time in doing continuous development.
Short & precise info
Never lose hope, never lose faith, stay positive!