Is anyone having problems with Crypti withdrawals from Bter. I've never had a problem before, or delay more than an hour. I have two withdrawals which have been stuck at "processing" and "waiting for balance..." for two days.

I received a response to my ticket saying problem resolved but the withdrawals still have not shown up ay my XCR address, the two withdrawals still show same status as 2 days ago, and my XCR balance does not show any refund. I've sent another response to the email saying problem resolved, still no response.

It is now Monday in China so it should be possible to resolve this now.

SyRenity is still working on the project. We just had our weekly meeting yesterday. 0.1.9 is in testing.

Looks like a 'selfie' of the photographer with his iphone reflecting off the gold label on the mug - I can see a beard on his face.

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 Mal has proposed has given me an idea on solving the PoT problem. I have never liked the lottery aspect of Bitcoin mining since it encourages the consolidation of mining into mining pools. Joining a mining pool lets the participant earn a steady return instead of hoping to eventually win a block reward.

With Crypti, I would rather see all nodes, or those meeting a minimum threshold of uptime, divide all of the forger portion of fees as they come in. This would eliminate the windfall a node receives if it happens to forge a block containing a large total of fees while other blocks pay less by simply distributing a portion of the fees to each node in proportion to its weight determined by PoT and PoP. This would work as a consensus system to confirm transactions as they come in. It simplifies things a lot by not needing to sort or compare weights from nodes to determine the winner of the next block.

This would maintain the decentralized architecture of Crypti, eliminate the lottery aspect, and improve network performance.

The proposed plan to attack other projects using legal means is a non-starter for me as it goes completely against my ethics. I go out of my way to avoid doing business with companies and professions which receive protectionist mercantile privilege or use the legal system to thwart competition and force people to do business with them.

PoT + PoP is not a lottery since it is determined by the total amount of time a node has been running since its last forge or initial start plus the total amount of spends it has made. Chance may enter into it in the occasional event of a tie, and the runners up in that tie are still at or near the top of the queue to generate a block soon after the tie.

Thanks, glad you like it.

We are following the proven model of cellphones, where the carrier would subsidize the cost of the handset to the customer in exchange for a contract of long enough duration to pay for the actual cost of the phone. This has been a very successful marketing strategy to promote widespread use of cellphones.

Happily, in the case of the Crypti box,  in exchange for running Crypti along with the coin of his choice, the customer receives a device which can make him money, and be used for a Point of Sale system in his business, instead of costing him money for a service contract, other than the electricity at a low price.

The box is also pre-configured and self updating for ease of use and convenience to encourage mass adoption, along the lines of Apple products. Early adopters who participate are also encouraged to contribute to testing and continued development of the system.

Thanks for your suggestions, Mal.

The pcDuino is a top contender to replace the current candidate Cubie boards, reducing cost without sacrificing performance. We are meeting with the pcDuino manufacturer tomorrow to discuss, among other things, adding more RAM to pcDuino so it can reliably run Crypti along with another PoS type coin, most notably NXT. This would also be useful for running Supernet alongside Crypti.

There is a plan being worked on to introduce the Crypti coinbox at or even below cost to encourage operation of independent nodes. The box is being designed to run two coins so another coin with larger forging rewards or other features may be run for more revenue while the Crypti network grows. The box has a SATA port so it is well configured to even run a storage coin like Storj or Maidsafe by adding a SATA drive. The numbers being considered are 500-1000 nodes. The final number will be determined based on consultation with the independent vendor reviewing the Crypti code for security.

The system will also form the core of the mesh networking node to be released at a later date.

I invested in the SuperNET pre-sale and hope it does well. I have corresponded with jl777 on possibly integrating it into a coinbox project a group of us are working on. I consider anonymity and privacy in commerce to be a very important feature, though it is not our main focus in Crypti. Integration of Crypti in SuperNET is being considered, but improving scalability for the Crypti network has been the overriding priority of late.

I very much agree with the philosophy of working with other projects towards a synergistic improvement in progress.

I have a Graphene fetish as well. One of the Crypti board members is actively researching it, has his own tube furnaces.

Cool, you're in Supernet. I invested as well, like idea of covering a lot of well researched coins. Hope it goes well!

Ether. do you do web design?

Thanks!

Skycoin was the planned coin with the Skywire mesh protocol, but with Skycoin's delay we may use a custom blockchain on Crypti instead.

We're looking at CJDNS, which is already running and handles data very similar to TOR. Right now we're trying to get the Edimax 802.11ac modules to run properly on the Cubieboards. It's a Linux driver issue with the Cubian distro which is a stripped down Debian for Cubie. Edimax has a couple of nice USB modules with higher gain antennas - a 4-6 Db omni and a 5-7 Db patch, http://www.newegg.com/Product/Product.aspx?Item=N82E16833315136&cm_re=802.11ac-_-33-315-136-_-Product and http://www.newegg.com/Product/Product.aspx?Item=N82E16833315137&cm_re=802.11ac-_-33-315-137-_-Product .

Yes, very nice. Would make great poker chips as well.

A group of are us are developing an ARM based coinbox for sale, and there is some overlap between the Crypti team and the coinbox team, Bitseed. We initially tried the NanoPC, a quad core ARM Cortex A9 board, which proved to be unstable. We then went to the Odroid, also a quad core board, which runs well but is too expensive to meet our sub-$100 retail price point. We are currently testing the Cubieboard2 and Cubieboard.

The product is meant to be a stand alone low power secure coinbox which can be always on to run PoS type coins, starting with NXT and Crypti pre-loaded for customer convenience.

It is also the core of our cryptocurrency based mesh networking project, where users can earn coin by providing bandwidth and storage to the mesh network, use the coin to access the network elsewhere with mobile devices, and buy or sell the coin as desired. We just had a very productive meeting with a supplier of TV whitespace electronics which has 10-15 mile range without needing line of sight with 19-21 Mbps data rates. This will allow the mesh to start with a much sparser population of nodes than is possible just using WiFi.

The development path is to start with the coinbox to get the units into the hands of users and developers, add the mesh networking hardware to the coinbox to convert it into a mesh networking node, combining the electronics into a single board system to produce a low cost stationary node capable of running on solar power, and then iteratively shrink the system to work first as a compact tethered node to operate with a mobile device, and finally, integrate it into mobile devices like the Google Ara modular phone and/or an open source mobile device which is part of a networked personal wearable system which can integrate a heads up augmented reality display, PTZ cameras, wrist band displays, gesture and voice control, and specialized devices like medical diagnostics and scientific sensors.

This has priority over custom blockchains and Windows installer, since changes here propagate to everything else downstream.

The temporary fix will have random forging on the blocks for a couple of weeks while changing the way nodes check in with each other to verify up-time for PoT calculation. It also prunes forks. The change solves network latency issues from the network growing in size so it scales better. It also prevents a node with highest weight from hanging network by subsequently not generating block.

We are implementing a temporary fix to restart the network with a permanent solution to fix the forking issue a couple of weeks later. I will be talking some more with the developers now and should have more details later. Thank you everyone for your patience on this matter.

Thanks for putting these up. I'm able to edit the paths and fills, do other things in Inkscape after ungrouping. I've been busy working with devs to get network going again but want to try things with design when I get a chance.

This is it! I like it as well. I'd like to play with it in Inkscape. Is there an svg or other vector file available?