[XCR] Crypti | Dapps | Sidechains | Dapp Store | OPEN SOURCE | 100% own code | DPoS

[immeraba]

Lite Wallets will be able to run Dapps, but not process them.

What is the difference?

We will reveal more information in the coming weeks.

Interesting I'll wait for more info.
I really like where Crypti is going. This is one of the few projects I believe in.

[1715183879]

1715183879

[1715183879]

1715183879

[1715183879]

1715183879

[Passion_ltc]

Lite Wallets will be able to run Dapps, but not process them.

What is the difference?

We will reveal more information in the coming weeks.

Interesting I'll wait for more info.
I really like where Crypti is going. This is one of the few projects I believe in.

Thank you. For all believers, spread the word!

[50cent_rapper]

1) MacOS is unix.
2) standby delegates can store CBC-s.
3) Lite wallet is best for windows users. Professional servers are always running under linux/unix - best for 101 delegates.

Keep the good work!

[MalReynolds]

Server problems - wait a second, I'm trying something...

[Mandy1749]

hello guys..
 

need your votes for my new delegate "China" now.
please .....
my server is online now.....just waiting to join the 101 club.

[Mandy1749]

it's Thursday now
it's update time.
what is the news?

[Passion_ltc]

it's Thursday now
it's update time.
what is the news?

The report is done. It will be reviewed by some of our guys and I will publish it in a few hours.

[Bigcabrito]

Second, I totally agree about the vulnerability of Crypti in its current form to DDoS attacks.  As I have discussed before, one solution is to split Top Delegate communications with Lite clients and their communications with each other onto separate IP addresses.  Top Delegates should have their own darknet where only they know the IP addresses being used for communications to new forge new blocks.

I have my concerns with this. If only 101 delegates have control over the network, it will be very simple to launch a coordinated attack on these. Are there any ways to handle this?

[MalReynolds]

Second, I totally agree about the vulnerability of Crypti in its current form to DDoS attacks.  As I have discussed before, one solution is to split Top Delegate communications with Lite clients and their communications with each other onto separate IP addresses.  Top Delegates should have their own darknet where only they know the IP addresses being used for communications among themselves to forge new blocks.

I have my concerns with this. If only 101 delegates have control over the network, it will be very simple to launch a coordinated attack on these. Are there any ways to handle this?

Top Delegates should have their own darknet where only they know the IP addresses being used for communications among themselves to forge new blocks.

The capability to do this is one of the advantages we got when we spun off Crypti Lite.  

[Litoshi]

Second, I totally agree about the vulnerability of Crypti in its current form to DDoS attacks.  As I have discussed before, one solution is to split Top Delegate communications with Lite clients and their communications with each other onto separate IP addresses.  Top Delegates should have their own darknet where only they know the IP addresses being used for communications to new forge new blocks.

I have my concerns with this. If only 101 delegates have control over the network, it will be very simple to launch a coordinated attack on these. Are there any ways to handle this?

Right now you would have to DDOS all 101 delegates at the same time.  Failure of any delegate to forge a block, passes the block to the next delegate in line.  If 10 delegates were unable to forge, those 10 blocks would have been forged by 10 other delegates.  This 10 delegates would have forged 2 blocks for that cycle.   That would only marginally delay the current 6-10 confirms needed for a transaction to be confirmed.  

Since 10 blocks were missed, then passed on to other delegates, that cycle would lengthen by 100 seconds for the 101 blocks.  Cycle completions are used to check the block chain for forks, add/delete delegates to active/standby mode; and divide the transaction fees earned during that cycle, if any.  

In the future versions, it has been discussed that we will be dropping delegates from the 101 club after X number of failed forges, for the next X cycles.  

[Passion_ltc]

An Introduction to our Multi Signature Implementation


Hello readers,

We are back with another Crypti issue on Thursday, and today we will cover the upcoming multi signature functionality in Crypti v0.3.1. We will explain how it works and how it will look like.

A multi signature account with a 2nd passphrase, will make your Crypti account as secure as a Swiss bank. There are few cryptocurrencies with multi signature support, and soon Crypti will join their proud ranks with an innovative twist. This is very important for exchanges, as they can offer a nearly 100% security.


Continue on our blog

[Passion_ltc]

On the 2nd April we changed to phpBB as our forum software. With this we started using a very nice and Crypti-like theme for the forum. I hope you liked it so far.

A few minutes ago I updated the theme at some aspects. It should now follow the material design guidelines a bit more. As you probably know we went with the material design at our Crypti client, and using it as our corporate identity from now on.


I hope you like it!


Check it out at: http://forum.crypti.me

[GreXX]

Starik, if someone were to run a full node on windows and try to become a delegate, it would be pointless. As soon as they became a delegate and were active and started missing blocks, they would just get voted out. So what is the point of supporting full nodes for windows? Full nodes aren't meant to be run by the average user. The Lite Wallet can interface with the delegates for anyone on a Windows box, but no one running an application, PoS, or otherwise would be running windows anyways.

Your argument is irrelevant because i never suggested to make a delegate on Windows.
Correct me if i am wrong.
Lite wallet does not check blockchain or blocks or transactions and does not propagate them through network. It only connects to delegate nodes.
While full wallet does. (as on the most other cryptocurrencies)
If this is true and the network became only 101 delegates then this is very bad because it could be stopped by simple ddos attack.

BTW, will lite wallet run DAPPs?

For reference, if you think a simple DDoS attack can take down the network, I will pay you a bounty to prove it right now.

[GreXX]

Second, I totally agree about the vulnerability of Crypti in its current form to DDoS attacks.  As I have discussed before, one solution is to split Top Delegate communications with Lite clients and their communications with each other onto separate IP addresses.  Top Delegates should have their own darknet where only they know the IP addresses being used for communications to new forge new blocks.

Mal, I actually addressed this in some of the proposals I had for our 2.0 network when we started looking into re-working it. The problem with setting up tunnels between the delegates is that it then becomes much more difficult to hot swap in standby delegates when an active delegate gets dropped. Bot impossible mind you, just more difficult. That being said, to DDoS effectively 101 cloud servers with proper DDoS protection through cloudflare or otherwise, would be almost impossible. That's not to say all delegates will have proper security and right now I imagine many have rudimentary measures. Even then, I challenge anyone to try it and show us how vulnerable we are in the current state. I will offer some form of bounty (and i'm sure others would chip in) to anyone who can take down the network and prove they did it, or find a vulnerability.

[dzarmush]

How do I check if I forge any blocks at the moment? My LA Vultr node started working worse and worse, so I deleted it and deployed the one in NY/NJ location instead of it, but as I see my uptime is keeping falling. Forging is enabled.

UPD: I checked my delegate through the web wallet, it showed that I wasn't forging. Will try to restart the server.

UPD2: It worked, my delegate is back online.

[patmast3r]

With Windows, it is not a good idea to use the full node.  Use the Crypti Lite wallet instead.

There is an issue with the time sync within Windows that causes forks and the inability to sync the block chain.  In future releases, Boris is not going to release Windows versions of the full wallet because of this issue.  Windows versions will be Lite wallets only.  Full wallets will be Linux based.

You can try deleting the blockchain.db file and restarting the node.  This usually works.

What kind of issue is that ? Like what does it cause ?

With a 10 minute block time, or even a one minute per block time, the time on your windows computer can be off a few seconds from the official NIST time and still forge or sync.  But with the XCR 10 second block times, a difference of a few seconds in the time on your windows machine and the network time, as synced with NIST, has caused failures to forge blocks and forking of the block chain for that machine.  

It is a problem with Windows, not with Crypti.  

I'm guessing because the network is rejecting blocks that are outside of a certain time threshold (like too far in the future or past) ?

If a block sent to a Windows machine, or any delegate, is not returned in sufficient time, the block is sent to the next delegate in line to forge. The only affect on the network is a 10 second or so lengthening of the present 101 block cycle.  The delegate that forged that block too late is now on a possible fork.  At the end of the 101 block cycle, the network self corrects all delegates that may have forked, as well as updating the votes cast during that cycle, and moving delegates in or out of the standby mode to the 101 club.


If the delegate that missed forging in time is on a fork, and it is 80 blocks down, it can take awhile to resync.  Meanwhile, forging of blocks continues on the network as that delegate attempts to catch up.  Now, what if that delegate is sent another block to forge before completing the block chain sync?  Further forking?  I dont know for sure, but it is not helping to secure the network.

I see.
It's not really a huge issue as most delegates would prob have run on linux machines anyway but you could take a look at the NEM whitepaper when it comes out. The NEM devs have implemented their own timesync protocoll which results in nodes not being more than 1-2 seconds away from each other (I'm told it's usually within ms but 1-2 s are not unthinkable).

[Litoshi]

How do I check if I forge any blocks at the moment? My LA Vultr node started working worse and worse, so I deleted it and deployed the one in NY/NJ location instead of it, but as I see my uptime is keeping falling. Forging is enabled.

UPD: I checked my delegate through the web wallet, it showed that I wasn't forging. Will try to restart the server.

UPD2: It worked, my delegate is back online.

you can watch the Delegate monitor here and see when your Delegte is forging. 

http://cryptichain.me/delegateMonitor

[Litoshi]

With Windows, it is not a good idea to use the full node.  Use the Crypti Lite wallet instead.

There is an issue with the time sync within Windows that causes forks and the inability to sync the block chain.  In future releases, Boris is not going to release Windows versions of the full wallet because of this issue.  Windows versions will be Lite wallets only.  Full wallets will be Linux based.

You can try deleting the blockchain.db file and restarting the node.  This usually works.

What kind of issue is that ? Like what does it cause ?

With a 10 minute block time, or even a one minute per block time, the time on your windows computer can be off a few seconds from the official NIST time and still forge or sync.  But with the XCR 10 second block times, a difference of a few seconds in the time on your windows machine and the network time, as synced with NIST, has caused failures to forge blocks and forking of the block chain for that machine.  

It is a problem with Windows, not with Crypti.  

I'm guessing because the network is rejecting blocks that are outside of a certain time threshold (like too far in the future or past) ?

If a block sent to a Windows machine, or any delegate, is not returned in sufficient time, the block is sent to the next delegate in line to forge. The only affect on the network is a 10 second or so lengthening of the present 101 block cycle.  The delegate that forged that block too late is now on a possible fork.  At the end of the 101 block cycle, the network self corrects all delegates that may have forked, as well as updating the votes cast during that cycle, and moving delegates in or out of the standby mode to the 101 club.


If the delegate that missed forging in time is on a fork, and it is 80 blocks down, it can take awhile to resync.  Meanwhile, forging of blocks continues on the network as that delegate attempts to catch up.  Now, what if that delegate is sent another block to forge before completing the block chain sync?  Further forking?  I dont know for sure, but it is not helping to secure the network.

I see.
It's not really a huge issue as most delegates would prob have run on linux machines anyway but you could take a look at the NEM whitepaper when it comes out. The NEM devs have implemented their own timesync protocoll which results in nodes not being more than 1-2 seconds away from each other (I'm told it's usually within ms but 1-2 s are not unthinkable).

Stas did a little testing two days ago with a Windows wallet.  He reset the clock on the computer, and found that if the Windows time is off by 2 seconds, a transaction sent from that machine, would not be accepted by the network. 

[dzarmush]

How do I check if I forge any blocks at the moment? My LA Vultr node started working worse and worse, so I deleted it and deployed the one in NY/NJ location instead of it, but as I see my uptime is keeping falling. Forging is enabled.

UPD: I checked my delegate through the web wallet, it showed that I wasn't forging. Will try to restart the server.

UPD2: It worked, my delegate is back online.

you can watch the Delegate monitor here and see when your Delegte is forging. 

http://cryptichain.me/delegateMonitor

I know Delegate Monitor, but I don't see where I can check whether I'm forging or not.

[Passion_ltc]

With Windows, it is not a good idea to use the full node.  Use the Crypti Lite wallet instead.

There is an issue with the time sync within Windows that causes forks and the inability to sync the block chain.  In future releases, Boris is not going to release Windows versions of the full wallet because of this issue.  Windows versions will be Lite wallets only.  Full wallets will be Linux based.

You can try deleting the blockchain.db file and restarting the node.  This usually works.

What kind of issue is that ? Like what does it cause ?

With a 10 minute block time, or even a one minute per block time, the time on your windows computer can be off a few seconds from the official NIST time and still forge or sync.  But with the XCR 10 second block times, a difference of a few seconds in the time on your windows machine and the network time, as synced with NIST, has caused failures to forge blocks and forking of the block chain for that machine. 

It is a problem with Windows, not with Crypti. 

I'm guessing because the network is rejecting blocks that are outside of a certain time threshold (like too far in the future or past) ?

If a block sent to a Windows machine, or any delegate, is not returned in sufficient time, the block is sent to the next delegate in line to forge. The only affect on the network is a 10 second or so lengthening of the present 101 block cycle.  The delegate that forged that block too late is now on a possible fork.  At the end of the 101 block cycle, the network self corrects all delegates that may have forked, as well as updating the votes cast during that cycle, and moving delegates in or out of the standby mode to the 101 club.


If the delegate that missed forging in time is on a fork, and it is 80 blocks down, it can take awhile to resync.  Meanwhile, forging of blocks continues on the network as that delegate attempts to catch up.  Now, what if that delegate is sent another block to forge before completing the block chain sync?  Further forking?  I dont know for sure, but it is not helping to secure the network.

I see.
It's not really a huge issue as most delegates would prob have run on linux machines anyway but you could take a look at the NEM whitepaper when it comes out. The NEM devs have implemented their own timesync protocoll which results in nodes not being more than 1-2 seconds away from each other (I'm told it's usually within ms but 1-2 s are not unthinkable).

We check every new whitepaper which appears. Thanks for the hint.