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

[GreXX]

So glad I ignored that guy and don't have to read his comments anymore...

[1714659404]

1714659404

[1714659404]

1714659404

[1714659404]

1714659404

[1714659404]

1714659404

[1714659404]

1714659404

[1714659404]

1714659404

[Wulfcastle]

@Devs

The block explorer : http://live.crypti.me/ is down. Also previously it was impossible to view the Top Accounts, as the page never loaded (it was stuck in a loading stage). Could you guys open-source the code for the block explorer on GitHub, so that we can run block-explorers on our own servers. The current one (http://live.crypti.me/) isn't that reliable at all to be honest.

[Vagnavs]

A heads up to you guys trying to game the system by running multiple nodes on the same IP.  It doesnt work.

I am talking to you:
104.131.159.247
104.131.24.219
104.131.25.48
106.187.42.214
109.73.224.63
109.73.224.74
109.73.224.76

some of you guys are running 20 nodes per IP#

The nodes have to be on unique IP #s, othewise they are treated as one node.

how the fuck do see peopels ip ROFLMAO

and post them here dumbfucker  

nice safe 0.5 xcr txids HAHAHAHA not 1 cheap fucks

Forum 8 views  

Seriously.. Don't you have something better to do?

[GreXX]

@Devs

The block explorer : http://live.crypti.me/ is down. Also previously it was impossible to view the Top Accounts, as the page never loaded (it was stuck in a loading stage). Could you guys open-source the code for the block explorer on GitHub, so that we can run block-explorers on our own servers. The current one (http://live.crypti.me/) isn't that reliable at all to be honest.

I will talk to the team and see what we can do.

[Litoshi]

Looking for some help. Trying to load Local Crypti Node Windows. Cannot load Blockchain passed 58777.

Sometimes it just takes a long time to load, especially if you have only 3GB RAM, or you are doing other things o the  computer


Are you on a PC?  If so, check your RAM available.  Best to use Resource Monitor.  There should be 3 listings for node.exe in the memory section.  One will e over 400K, likely 800K to 1 GB.  If you only have 2 node.exe showing in the memory section, then reboot the computer, not just the node, the computer.  Start the node before any other programs.

I run the node on a 3GB laptop that does nothing else.  When I tru it on my 4GB laptop, that I use for work, it will crash the node eventually when the RAM runs out.

Hope this helps

I had to reboot my computer and the node because we are doing some abuse investigation on the node.  Anyway, it took 2.5 hrs for my node on Win 7 to sync the blockchain and get to the log in screen.  SO, just be patient, it WILL eventually load.

Did you notice earlier today, when we started the forging reward program; that there were many 0 value blocks followed by double pay and even triple pay blocks?  That is due to a flood of nodes that are basically DDOSing the system.

We seem to be having a lot of nodes from the same IPs.  There are like 1000 nodes on the network, but only about 60-80 unique IP#s.

Our best guess it that ASIC/GPU farms are using their CPUs (which do very little for an ASIC) to run the nodes.  

But, like I said earlier, only ONE node per IP will be recognized for forging.  The random forging algo uses IP address.  Having 20 or more nodes on one IP is just flooding the system with crap.  

Boris even changed the pay out to every 30 seconds instead of 60 seconds, and it only made the situation worse.

SO you guys with the ASIC?GPU farms.......... ONE node per IP.  More than that and you are wasting bandwidth, power, and forcing us to start blacklisting IPs.

[starik69]

Hm... I do not see any fees, all blocks are empty 

[Litoshi]

Hm... I do not see any fees, all blocks are empty 

Boris is rewriting the script to fix the expolits and issues we discovered.  This is a BETA version, diba

[GreXX]

As soon as we announced the script was running someone started spinning up hundreds of nodes on like 3 IPs which was a free stress test for us that pointed out some things we needed to do. It will be back up shortly.

[Litoshi]

A heads up to you guys trying to game the system by running multiple nodes on the same IP.  It doesnt work.

I am talking to you:
104.131.159.247
104.131.24.219
104.131.25.48
106.187.42.214
109.73.224.63
109.73.224.74
109.73.224.76

some of you guys are running 20 nodes per IP#

The nodes have to be on unique IP #s, othewise they are treated as one node.

how the fuck do see peopels ip ROFLMAO

and post them here dumbfucker 

nice safe 0.5 xcr txids HAHAHAHA not 1 cheap fucks

Forum 8 views   

how the fuck do see peopels ip ROFLMAO

and post them here dumbfucker 

because I learned how to use a computer in the 1970s...... about 25 years before you were born. 

Back in those days you had to know DOS,  and UNIX commands.  The mouse had not been invented yet.  Monitors were green screens.  There were not any PCs, just terminals connected to channels connected to mainframes.

I bet you dont know even the simplest DOS commands, and what they do, because you are a GUI script kitty. 

go " fdisk" yourself.

[GreXX]

We all discussed Wulfs request this morning in regards to open sourcing the Block Explorer and I wanted to give an update.

We will be launching a new release of the node software this week with the new DB structure, some optimization, and a few bug fixes. Updating the DB structure will require us to make a couple of changes to the block explorer so we have decided to release it once we make the changes for the new version.

The plan as per Boris is to have the new release out this week. We will try to post the Block Explorer shortly after. As always these things are subject to change but we will release a version of the block explorer as soon as the DB change is complete.

I am also pushing to go ahead and release the faucet on Github as well so maybe we can get a couple running out there to get some more free XCR flowing (and with it TX fees).

[Bitseed]

Below are more details on option 2 of PoT, the iterative probabilistic method.

1. Separate transaction processing from block generation, so transactions can be confirmed by consensus quickly without being held back by verification of node uptime for block generation.

2. Divide fees proportionally among all nodes according to individual weights for each block instead having one node take all for the block.

3. Have nodes confirm each others' timestamps and transactions by iterative random sample with consensus.

    a. first sample, 10 for example must have 100% consensus. For a sample size of 10 with 10% bad nodes on network, odds of fail are .1^10 =0.00000001% or 1/10 billion.

    b. if first sample is not 100% consensus, second larger sample is taken, for example, 100, requiring 90% consensus. For a sample size of 100 with 10% bad nodes on the network, odds of a fail with 90 or more nodes being bad are effectively 0 (my calculator calculates the sum of the probabilities of 90 through 100 nodes being bad as 0. This may continue through further iterations with increasing numbers of nodes and lower consensus requirements as a failsafe against network attacks by floods of bad nodes.

(for number of nodes N is much larger than sample size, using Binomial Distribution as approximation instead of sampling without replacement, http://en.wikipedia.org/wiki/Binomial_distribution)

    c. The above sample sizes can be adjusted so probability of step a failing is equivalent to probability of step b failing.

4. flag nodes with consistently disagreeing results as bad

    a. ignore in confirmations

    b. alert owners node is malfunctioning

    c. maybe auto-restart node when flagged as bad

    d. too many flags and restarts blacklists node permanently.

5. Since fees are split proportionally, block may be forged randomly with highest difficulty to select valid forks as chains having highest difficulty.

Overall, this amounts to a quality and reliability engineering approach to crypto.

Ideally, the weight should reflect the quality of a node. Currently the metrics are its reliability as expressed in uptime and its activity in the amount it spends. More metrics may be added, such as the speed and accuracy of its results in processing transactions and reaching consensus, the accuracy of its time stamping, and the speed with which it responds to queries from its peers for consensus. The random sampling of nodes may be dynamically weighted to sample nodes of known higher quality more frequently than nodes of lower or unknown quality to improve the reliability of the network.

The probabilistic model is a reliability problem. The required reliability is determined as length of time the network must run with an acceptable probability of failure. If it does fail, it must do so in a graceful manner without catastrophic results, with full recovery possible. In crypto, a graceful failure is degradation of performance, less graceful is a full halt with no data or transaction loss or error. Least graceful is error requiring rollback of the blockchain for recovery. Any fails beyond this are unacceptable as they would be catastrophic, and even a rollback must be avoided.

To anticipate and avoid problems, a Failure Mode and Effects Analysis (FMEA - http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis) will be needed to identify all possible failure modes and what effects they would have on network reliability and its users. The parameters of the probabilistic iterations may be adjusted to achieve the required reliability. It is what is known in reliability engineering as a standby redundant system, where if a primary module fails, a secondary takes its place, and further iterations of consensus act as additional standby redundancy.

[Vagnavs]

Below are more details on option 2 of PoT, the iterative probabilistic method.

1. Separate transaction processing from block generation, so transactions can be confirmed by consensus quickly without being held back by verification of node uptime for block generation.

2. Divide fees proportionally among all nodes according to individual weights for each block instead having one node take all for the block.

3. Have nodes confirm each others' timestamps and transactions by iterative random sample with consensus.

    a. first sample, 10 for example must have 100% consensus. For a sample size of 10 with 10% bad nodes on network, odds of fail are .1^10 =0.00000001% or 1/10 billion.

    b. if first sample is not 100% consensus, second larger sample is taken, for example, 100, requiring 90% consensus. For a sample size of 100 with 10% bad nodes on the network, odds of a fail with 90 or more nodes being bad are effectively 0 (my calculator calculates the sum of the probabilities of 90 through 100 nodes being bad as 0. This may continue through further iterations with increasing numbers of nodes and lower consensus requirements as a failsafe against network attacks by floods of bad nodes.

(for number of nodes N is much larger than sample size, using Binomial Distribution as approximation instead of sampling without replacement, http://en.wikipedia.org/wiki/Binomial_distribution)

    c. The above sample sizes can be adjusted so probability of step a failing is equivalent to probability of step b failing.

4. flag nodes with consistently disagreeing results as bad

    a. ignore in confirmations

    b. alert owners node is malfunctioning

    c. maybe auto-restart node when flagged as bad

    d. too many flags and restarts blacklists node permanently.

5. Since fees are split proportionally, block may be forged randomly with highest difficulty to select valid forks as chains having highest difficulty.

Overall, this amounts to a quality and reliability engineering approach to crypto.

Ideally, the weight should reflect the quality of a node. Currently the metrics are its reliability as expressed in uptime and its activity in the amount it spends. More metrics may be added, such as the speed and accuracy of its results in processing transactions and reaching consensus, the accuracy of its time stamping, and the speed with which it responds to queries from its peers for consensus. The random sampling of nodes may be dynamically weighted to sample nodes of known higher quality more frequently than nodes of lower or unknown quality to improve the reliability of the network.

The probabilistic model is a reliability problem. The required reliability is determined as length of time the network must run with an acceptable probability of failure. If it does fail, it must do so in a graceful manner without catastrophic results, with full recovery possible. In crypto, a graceful failure is degradation of performance, less graceful is a full halt with no data or transaction loss or error. Least graceful is error requiring rollback of the blockchain for recovery. Any fails beyond this are unacceptable as they would be catastrophic, and even a rollback must be avoided.

To anticipate and avoid problems, a Failure Mode and Effects Analysis (FMEA - http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis) will be needed to identify all possible failure modes and what effects they would have on network reliability and its users. The parameters of the probabilistic iterations may be adjusted to achieve the required reliability. It is what is known in reliability engineering as a standby redundant system, where if a primary module fails, a secondary takes its place, and further iterations of consensus act as additional standby redundancy.

what are you a coder or something?
Thanks for the feedback,
Brian

[Wulfcastle]

Below are more details on option 2 of PoT, the iterative probabilistic method.

1. Separate transaction processing from block generation, so transactions can be confirmed by consensus quickly without being held back by verification of node uptime for block generation.

2. Divide fees proportionally among all nodes according to individual weights for each block instead having one node take all for the block.

3. Have nodes confirm each others' timestamps and transactions by iterative random sample with consensus.

    a. first sample, 10 for example must have 100% consensus. For a sample size of 10 with 10% bad nodes on network, odds of fail are .1^10 =0.00000001% or 1/10 billion.

    b. if first sample is not 100% consensus, second larger sample is taken, for example, 100, requiring 90% consensus. For a sample size of 100 with 10% bad nodes on the network, odds of a fail with 90 or more nodes being bad are effectively 0 (my calculator calculates the sum of the probabilities of 90 through 100 nodes being bad as 0. This may continue through further iterations with increasing numbers of nodes and lower consensus requirements as a failsafe against network attacks by floods of bad nodes.

(for number of nodes N is much larger than sample size, using Binomial Distribution as approximation instead of sampling without replacement, http://en.wikipedia.org/wiki/Binomial_distribution)

    c. The above sample sizes can be adjusted so probability of step a failing is equivalent to probability of step b failing.

4. flag nodes with consistently disagreeing results as bad

    a. ignore in confirmations

    b. alert owners node is malfunctioning

    c. maybe auto-restart node when flagged as bad

    d. too many flags and restarts blacklists node permanently.

5. Since fees are split proportionally, block may be forged randomly with highest difficulty to select valid forks as chains having highest difficulty.

Overall, this amounts to a quality and reliability engineering approach to crypto.

Ideally, the weight should reflect the quality of a node. Currently the metrics are its reliability as expressed in uptime and its activity in the amount it spends. More metrics may be added, such as the speed and accuracy of its results in processing transactions and reaching consensus, the accuracy of its time stamping, and the speed with which it responds to queries from its peers for consensus. The random sampling of nodes may be dynamically weighted to sample nodes of known higher quality more frequently than nodes of lower or unknown quality to improve the reliability of the network.

The probabilistic model is a reliability problem. The required reliability is determined as length of time the network must run with an acceptable probability of failure. If it does fail, it must do so in a graceful manner without catastrophic results, with full recovery possible. In crypto, a graceful failure is degradation of performance, less graceful is a full halt with no data or transaction loss or error. Least graceful is error requiring rollback of the blockchain for recovery. Any fails beyond this are unacceptable as they would be catastrophic, and even a rollback must be avoided.

To anticipate and avoid problems, a Failure Mode and Effects Analysis (FMEA - http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis) will be needed to identify all possible failure modes and what effects they would have on network reliability and its users. The parameters of the probabilistic iterations may be adjusted to achieve the required reliability. It is what is known in reliability engineering as a standby redundant system, where if a primary module fails, a secondary takes its place, and further iterations of consensus act as additional standby redundancy.

That's impressive. How long would it appromixately take to code this solution?

[Wulfcastle]

Looking for some help. Trying to load Local Crypti Node Windows. Cannot load Blockchain passed 58777.

Sometimes it just takes a long time to load, especially if you have only 3GB RAM, or you are doing other things o the  computer


Are you on a PC?  If so, check your RAM available.  Best to use Resource Monitor.  There should be 3 listings for node.exe in the memory section.  One will e over 400K, likely 800K to 1 GB.  If you only have 2 node.exe showing in the memory section, then reboot the computer, not just the node, the computer.  Start the node before any other programs.

I run the node on a 3GB laptop that does nothing else.  When I tru it on my 4GB laptop, that I use for work, it will crash the node eventually when the RAM runs out.

Hope this helps

SO you guys with the ASIC?GPU farms.......... ONE node per IP.  More than that and you are wasting bandwidth, power, and forcing us to start blacklisting IPs.

Litoshi, are you saying that you are trying to blacklist IP's from the whole Crypti network?

[imd1]

Any idea about 5000Bitcoins ? He was very enthusiastic about inclusion in SuperNet which GreXX has said they are discussing internally.

Has he left crypti community for the time being ? His 'Let's talk Crypti' forum is also silent.. https://bitcointalk.org/index.php?topic=821046.0

[Wulfcastle]

Any idea about 5000Bitcoins ? He was very enthusiastic about inclusion in SuperNet which GreXX has said they are discussing internally.

Has he left crypti community for the time being ? His 'Let's talk Crypti' forum is also silent.. https://bitcointalk.org/index.php?topic=821046.0

Yeah haven't seen him for a while..., I'm sure he'll be back soon enough.

[50cent_rapper]

I'm still think that Crypti is a good investment. Team just made a "restart"/pivot in PoT, thats not a tragedy.
Wait for new design, PoT solution and CMB. May be the real chance to make money will be not coin itself, but apps.
Wanna to know the price in may 2015.

[Litoshi]

Looking for some help. Trying to load Local Crypti Node Windows. Cannot load Blockchain passed 58777.

Sometimes it just takes a long time to load, especially if you have only 3GB RAM, or you are doing other things o the  computer


Are you on a PC?  If so, check your RAM available.  Best to use Resource Monitor.  There should be 3 listings for node.exe in the memory section.  One will e over 400K, likely 800K to 1 GB.  If you only have 2 node.exe showing in the memory section, then reboot the computer, not just the node, the computer.  Start the node before any other programs.

I run the node on a 3GB laptop that does nothing else.  When I tru it on my 4GB laptop, that I use for work, it will crash the node eventually when the RAM runs out.

Hope this helps

SO you guys with the ASIC?GPU farms.......... ONE node per IP.  More than that and you are wasting bandwidth, power, and forcing us to start blacklisting IPs.

Litoshi, are you saying that you are trying to blacklist IP's from the whole Crypti network?

What I am saying is that there are approx 40 or more IPs that are running 20-100 nodes.  Only one node per IP can forge a block. 

The last look I had at the network a few hours ago, still showed about 60 unique IPs, but over 1000 nodes.  A check of some of the IPs revealed cloud miners.  Others appear to be ASIC/GPU mining farms.

So, the chance of getting a forged block, with 60 unique IPs,  is 1 chance out of 60 per block. 
Not 1 out of 1000; or 100 out of 1000 (for a 100 node IP).  Watching my own node, I seem to get a forged block about every 50 or so blocks. 

Apparently the ASIC farms think that by running 100 nodes, they will have a greater chance at forging a block, but thats not true.  What they are doing , however, is flooding (DDOS) the network. 

A 100 node ASIC farm sends 100 duplicate pings to the network every minute.  Only one ping counts.  The other 99 pings just cause problems.  Have you noticed that we still have blocks forging with 0 XCR?  That's a result of the stress the multi-node IPs are putting on the network.

It will cause even more trouble later, when we have the PoT algo working.  The algo would be pinged by many nodes, with the same IP, all having a different timestamp.  Unsure what the result of that would be, but it wont increase the nodes chance of forging.  It may, in fact, crash the network. 

One defense we are considering is to blacklist the IPs for a set time that are running more than X number of nodes. 

We are, of course, always open to suggestions from the community.

[GreXX]

Basically Litoshi is proposing a solution wherein the network nodes would identify multiple requests from a single IP (multiple connections or however you would want to track it) and then have the nodes refuse to connect to those nodes for a given period of time if they see that behavior. Basically flag it somehow. It's not something the team as a whole is proposing or has a solution for how to accomplish at this point, but if we continue to see behavior like this and if that behavior seems to be impacting the network, we would need to find a solution that would work to limit the impact.

[GreXX]

Any idea about 5000Bitcoins ? He was very enthusiastic about inclusion in SuperNet which GreXX has said they are discussing internally.

Has he left crypti community for the time being ? His 'Let's talk Crypti' forum is also silent.. https://bitcointalk.org/index.php?topic=821046.0

Yeah haven't seen him for a while..., I'm sure he'll be back soon enough.

5000 Bitcoins had a private meeting with some members of the Crypti team and offered up his ideas and solutions for how we might progress moving forward. Solutions like focusing on Custom Blockchains now and finalizing PoT later so that we can show what Crypti is capable of and also some progress. He also talked to us in depth about how he perceives SuperNet as well as the benefit from joining to the whole Crypti community.

He had a lot of really good insight and we are taking all of his suggestions into consideration. For instance, we have decided as he suggested to progress on CMB while we attempt to come to a final solution on PoT.

I'm sure he is just taking a break to help work on SuperNet as he decided to take a small position on one of their teams and may be a little pre-occupied there for the time being as they are still fairly new.