Author

Topic: [ANN][ICO]CREDITS - New Blockchain for financial industry [HARDCAP REACHED!] - page 164. (Read 37749 times)

full member
Activity: 294
Merit: 100
Hello. Explain, please, for what purpose will every action be linked to the time mark, the number of the previous block, the user's login and the smart contract ID in the system?
member
Activity: 406
Merit: 31
Well, it’s a very large project. However, I suspect that due to the large number of transactions being processed, there may appear some duplicates, and some users will use them for their own benefit. If I were a developer, I would pay special attention to this point.
There’re great specialists in CREDITS team. That's why every detail gets a lot of attention, including the problem that you’ve described. I can assure you that no duplicates will arise, there’re no chances of fraud.
Really? Well, it's great, if it is so. Do you know how the service will struggle against duplicates?
In order to prevent duplication of the transaction in the same block with the same identifier, the system accepts an agreement that the only true and correct transaction is that which came first to the validator subsystem for processing. Since it is already recorded in the validator system that a transaction has already been made from the current account and there are no values left in the account to conduct the transaction, a consensus cannot be found.
I’d also like to say, that when the transaction is executed, information is received to the validator and confirmed, the information about the ledger status change is automatically distributed to all nodes from the trusted list, after which the ledger is synchronized. This also contributes to the fact that duplicate transactions can’t be executed in Credits anyway.
Considering what you said, it turns out, that the system will always need to maintain an up-to-date registry, I mean carry out synchronization after each transaction. Is it possible?

Yeah, it is possible! The system will use a separate port for synchronization in order to keep the registry synchronized. By the way, such a solution will increase the speed of processing of input information in the core of the validator due to the distribution of the load within the port.
full member
Activity: 336
Merit: 100
Well, it’s a very large project. However, I suspect that due to the large number of transactions being processed, there may appear some duplicates, and some users will use them for their own benefit. If I were a developer, I would pay special attention to this point.
There’re great specialists in CREDITS team. That's why every detail gets a lot of attention, including the problem that you’ve described. I can assure you that no duplicates will arise, there’re no chances of fraud.
Really? Well, it's great, if it is so. Do you know how the service will struggle against duplicates?
In order to prevent duplication of the transaction in the same block with the same identifier, the system accepts an agreement that the only true and correct transaction is that which came first to the validator subsystem for processing. Since it is already recorded in the validator system that a transaction has already been made from the current account and there are no values left in the account to conduct the transaction, a consensus cannot be found.
I’d also like to say, that when the transaction is executed, information is received to the validator and confirmed, the information about the ledger status change is automatically distributed to all nodes from the trusted list, after which the ledger is synchronized. This also contributes to the fact that duplicate transactions can’t be executed in Credits anyway.
Considering what you said, it turns out, that the system will always need to maintain an up-to-date registry, I mean carry out synchronization after each transaction. Is it possible?
member
Activity: 406
Merit: 31
Well, it’s a very large project. However, I suspect that due to the large number of transactions being processed, there may appear some duplicates, and some users will use them for their own benefit. If I were a developer, I would pay special attention to this point.
There’re great specialists in CREDITS team. That's why every detail gets a lot of attention, including the problem that you’ve described. I can assure you that no duplicates will arise, there’re no chances of fraud.
Really? Well, it's great, if it is so. Do you know how the service will struggle against duplicates?
In order to prevent duplication of the transaction in the same block with the same identifier, the system accepts an agreement that the only true and correct transaction is that which came first to the validator subsystem for processing. Since it is already recorded in the validator system that a transaction has already been made from the current account and there are no values left in the account to conduct the transaction, a consensus cannot be found.
I’d also like to say, that when the transaction is executed, information is received to the validator and confirmed, the information about the ledger status change is automatically distributed to all nodes from the trusted list, after which the ledger is synchronized. This also contributes to the fact that duplicate transactions can’t be executed in Credits anyway.
full member
Activity: 392
Merit: 100
Well, it’s a very large project. However, I suspect that due to the large number of transactions being processed, there may appear some duplicates, and some users will use them for their own benefit. If I were a developer, I would pay special attention to this point.
There’re great specialists in CREDITS team. That's why every detail gets a lot of attention, including the problem that you’ve described. I can assure you that no duplicates will arise, there’re no chances of fraud.
Really? Well, it's great, if it is so. Do you know how the service will struggle against duplicates?
In order to prevent duplication of the transaction in the same block with the same identifier, the system accepts an agreement that the only true and correct transaction is that which came first to the validator subsystem for processing. Since it is already recorded in the validator system that a transaction has already been made from the current account and there are no values left in the account to conduct the transaction, a consensus cannot be found.
member
Activity: 336
Merit: 10
Well, it’s a very large project. However, I suspect that due to the large number of transactions being processed, there may appear some duplicates, and some users will use them for their own benefit. If I were a developer, I would pay special attention to this point.
There’re great specialists in CREDITS team. That's why every detail gets a lot of attention, including the problem that you’ve described. I can assure you that no duplicates will arise, there’re no chances of fraud.
Really? Well, it's great, if it is so. Do you know how the service will struggle against duplicates?
full member
Activity: 392
Merit: 100
Well, it’s a very large project. However, I suspect that due to the large number of transactions being processed, there may appear some duplicates, and some users will use them for their own benefit. If I were a developer, I would pay special attention to this point.
There’re great specialists in CREDITS team. That's why every detail gets a lot of attention, including the problem that you’ve described. I can assure you that no duplicates will arise, there’re no chances of fraud.
member
Activity: 336
Merit: 10
Well, it’s a very large project. However, I suspect that due to the large number of transactions being processed, there may appear some duplicates, and some users will use them for their own benefit. If I were a developer, I would pay special attention to this point.
member
Activity: 574
Merit: 12
Good day everyone. Does anyone know the length of the secret key? Have you tested the security system for any hacking attacks? What is the result?
Such tests are plan to be after alpha release
member
Activity: 574
Merit: 12
Hello. I’m worried about a very important thing. How are you going to protect the information between validation knots from stealing?
CREDITS Platform places the network security at the forefront. We use the appropriate network operation scheme, experience and all the latest advances in the field of encryption.   
member
Activity: 574
Merit: 12
That’s an interesting project but I don’t think it is possible to make it work so fast  taking into account the amount of work. Probably in a couple of years when technology will get even more advanced it will be achievable. But still this project has some long-term potential. 
Alpha release will be already in 2018, but project has long term road map and there will be a lot of updates and improvements
member
Activity: 574
Merit: 12
Those who invested a large amount of money  are going to get  bigger bonuses?
Yes, you are right, look here: https://credits.com/en/home/ico
member
Activity: 574
Merit: 12
Good Day! New ICO round is coming in soon. So I wonder if there are any bonuses for investors?
current PRE-ICO Bonus
Pre-ICO - 30%
Additional bonus from the purchase amount:
Total 30%, including 0% - up to 50 Ether (35,000 USD)
Total 50%, including 20% - from 50 Ether (35,000 USD)
Total 55%, including 25% - from 100 Ether (70,000 USD)
Total 60%, including 30% - from 250 Ether (175,000 USD)
Total 65%, including 35% - from 500 Ether (350,000 USD)
Total 70%, including 40% - from 1,000 Ether (700,000 USD)
member
Activity: 103
Merit: 10
If you are using Diffie-Hellman algorithm you get the channel that you can listen in to. What is the downside of this for the users?  
member
Activity: 358
Merit: 10
I’ve found a part that says that RC4 algorithm is based on discrete logarithms difficulty. Does it mean that theoretically somebody can hack this algorithm if he figures out  all discrete logarithms?
member
Activity: 196
Merit: 10
I’ve read in project description that RC4 algorithm will work on secret key. Can you tell me please who is going to have access to this key?
member
Activity: 392
Merit: 10
Good day everyone. Does anyone know the length of the secret key? Have you tested the security system for any hacking attacks? What is the result?
full member
Activity: 168
Merit: 100
Hello. I’m worried about a very important thing. How are you going to protect the information between validation knots from stealing?
member
Activity: 294
Merit: 10
That’s an interesting project but I don’t think it is possible to make it work so fast  taking into account the amount of work. Probably in a couple of years when technology will get even more advanced it will be achievable. But still this project has some long-term potential. 
You’re right. CREDITS can’t work at the full speed right now. But the team doesnt want to wait for the future to come they are creating the future! They have developed this technology from the scratch and it will help the platform to work as fast as it is currently possible.
Well, that sounds promising)) What kind of technologies are they working on and have developed so far?

When it comes to the speed of the service the main thing is the list of transactions. Every record is made of hashcode block of transactions that is added to the list of candidates for the registry.
To me it looks like you are not going to use traditional Merkle tree. Is that right?
Yes, you’re right.  Merle tree system make the platform too slow. Our way is definitely faster by all means  in both general work and transactions. Plus it will make it hard to make any unlawful changes in the registry. More than that, in CREDITS nobody will be able to backdated those changes. 
member
Activity: 196
Merit: 10
That’s an interesting project but I don’t think it is possible to make it work so fast  taking into account the amount of work. Probably in a couple of years when technology will get even more advanced it will be achievable. But still this project has some long-term potential. 
You’re right. CREDITS can’t work at the full speed right now. But the team doesnt want to wait for the future to come they are creating the future! They have developed this technology from the scratch and it will help the platform to work as fast as it is currently possible.
Well, that sounds promising)) What kind of technologies are they working on and have developed so far?

When it comes to the speed of the service the main thing is the list of transactions. Every record is made of hashcode block of transactions that is added to the list of candidates for the registry.
To me it looks like you are not going to use traditional Merkle tree. Is that right?
Jump to: