Bitcoin Forum
June 25, 2017, 12:31:30 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 [125] 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 ... 211 »
  Print  
Author Topic: [ANN]CureCoin - Protein Folding Research based Proof of Work  (Read 529043 times)
Vorksholk
Legendary
*
Offline Offline

Activity: 1554



View Profile WWW
July 06, 2014, 04:53:07 AM
 #2481

Hey guys! Work continues on conference-related stuff, but we developers are also brewing a few other elixirs of interest.

One of the ideas thrown around the virtual, coffee-stained conference table recently was the use of quantum-computer-resistant signature algorithms. Without going too deep into concepts tangentially related the matter at hand, hashing functions, due in part to the 'loss' of data that occurs during the function (Imagine a simple example of a 'secret' being the two numbers 12 and 20. A *very* simple, collision-prone, insecure method of verifying those numbers at a later point in time without storing the actual numbers would be to store some mathematical, repeatable function of the two, something such as multiplication. If a person were able to acquire the hash '240' and try to find the original inputs, they would get a ton of matching input pairs: (1, 240), (2, 120), (3, 80), ... (15, 16). This availability of collisions makes the actual function 'lossy'. Such an example is clearly an exploitable system, and is only for visualization purposes. The complex reduction, data loss, and mixing occur primarily through logical (AND, OR, XOR) operations, rolling reels of numbers effecting each other, sponge functions, etc., and make reversing an output back to an input 'impossible'.) are assumed to map inputs to realistically-unique outputs of a (usually) fixed length. As such, they are not prone to math-based attacks from quantum computing algorithms against classical computational encryption algorithms (RSA, ECDSA...).

What's so important about cryptographic signatures? For the purposes of a terribly inaccurate analogy, imagine your cryptocurrency wallets as a checkbook. You can write an amount, a destination, and a dollar value, but without your signature, the filled-out check has absolutely no ability to actually transfer currency. However, once you put your signature (which is, historically, important since they are *relatively* hard to imitate as well as hard for the signer to deny signing the check) on the check, it can be used to transfer funds. If you wrote a check for $10 to your friend but never submitted it to the bank (blockchain), the money never gets transferred. However, once the check gets cashed by your friend, the funds get transferred from your account to your friend's, and if you later deny signing the check, someone can simply show your signature. Either your signature was compromised, or you signed the document. This is known as a promise of non-repudiation. Signatures on the blockchain work to ensure that anyone can see the balance of an address (to verify you have the money you are trying to spend), but you can only spend money from an address you have control over. Asymmetrical cryptography allows for signatures to be privately generated but publicly verified.

Bitcoin addresses are formed in the following manner: address = Base58(versionByte + RIPEMD-160(SHA-256(publickey)) + SHA-256(SHA2-56(RIPEMD-160(SHA-256(publickey)))).substring(0, 4)) where ‘+’ represents a concatenation operator. Fun, right? If you prefer a visual simplification:


As such, simply accepting coins at an address does not reveal your public OR private key to the network. As such, the Bitcoin network is unable to differentiate between a valid and an invalid address--the only possible sanity check is a built-in checksum as shown above (the second, partial SHA256D hash appended to the end) which helps to eliminate mistypes. However, due to the nature of hashing functions being assumed to be one-way, the only way we can prove we own such a certain address, when we decide we want to spend the coins, is to publicly reveal the public key. In the absence of an efficient way to factor large numbers (either by an *extremely* unlikely breakthrough in mathematics, or more likely through the practical implementation of Shor's algorithm (or in the case of ECDSA, a modified derivative) or another quantum-computer-algorithm), ECDSA and RSA are extremely secure. However, when very large numbers can be efficiently factored, there are serious concerns about the safety of classic computational cryptography as it exists today. The only way the Bitcoin network would be safe in the event of a quantum computer capable of factoring large numbers would be to switch to a one-time-use address system. Today, one Bitcoin address can send and receive as many transactions as desired with safety. However, due to the nature of address generation above, after the address signs one transaction, the public key is revealed, in order to prove ownership of the address. Until a valid transaction originates from an address, the public key behind the address is safely masked by one-way cryptography (hashing functions). However, upon signing a transaction and broadcasting the public key, quantum computer attacks on that address become possible.

In a post-quantum-computing environment, as soon as an address signs a transaction, and remaining coins on the address are put at risk. As such, the various methods by which Bitcoin addresses are used multiple times today (tip jars, many payment processing services, etc.) would have to transition to a system of one-time address use, which not only decreases the compressibility of the blockchain, but also acts to make the currency harder to use. Imagine having to give your workplace a new bank account to deposit for every payday...

ECDSA has several properties that make it desirable for use in efficient cryptocurrencies: small signature size, fast verification, and small public key size. Additionally, the computational power required for key generation is trivial.

Any alternative to ECDSA aimed at being quantum-computing-resistant must, to avoid blockchain bloat and computational bloat, have relatively small signatures, public keys, and be easy to verify, allowing for network growth. Under the validated assumption that cryptographic one-way algorithms such as the popular SHA-family of hashing functions are secure against quantum-computers based on their reliance on lost data rather than on mathematically-hard problems, signatures built on top of hashing algorithms inherit similar properties. One simple example of such a signature method is the Lamport Signature, which is a one-time signature.
To summarize Lamport (when used with SHA256, and where 'User' refers to a computer generating and using an address):
-> User generates 256 random inputs (preferably somewhat long, and a mix of numbers, letters, symbols, and even non-printable characters if desired)
-> User divides these 256 inputs into 128 pairs of two inputs
-> User hashes each input and stores the hash output
-> User publishes all 256 outputs to the network (for our purposes, consider this group of 256 outputs to be the public key and address!)
-> User signs away coins the network recorded as belonging to the published public key/address by:
--->User writes and hashes a transaction message (simplification: "I sign all 8.3 coins from transaction (TxID) to address (address)")
--->User lays out the SHA256 hash in binary
--->User submitts the corresponding private keys (For example, if they were signing the four bits "0110", they would submit the first (position: zero) private key from the first group, the second (position: one) from the second group, the second (position: one) from the third group, and finally the first (position: zero) from the fourth group) to the network. The network can then hash the private keys and see that they match the public keys, and can also verify that the user signed that particular message by hashing the message, and seeing that only the private keys corresponding to the binary representation of the hash of the message are published, while the others (the 2nd in the 1st set, the 1st in the 2nd set, the 1st in the 3rd set, and the 2nd in the 4th set) are not made public. If the address owner were to sign another message, he or she would have to reveal other parts of their private key, which compromises the security by allowing full sets (rather than one of two hashes in a set) to be published, allowing an attacking party to possibly forge messages. As such, Lamport signatures are one-way, one-use.

Lamport signatures have two obvious shortcommings: huge public key sizes, and one-time use.

However, the basic logic lamport signatures are based on can be extended in such a way that a Lamport-esque signature scheme can be reduced to a *very* small public key (in some capacity smaller than ECDSA) as well as having reasonable signature sizes (larger than ECDSA, but not large enough to be impractical for blockchain usage). Such implementations use merkle trees to make signatures able to sign huge amounts of transactions (think 2^20 to 2^40, far beyond practical application, and thus not limiting the effectiveness of an address generation/transaction signing algorithm pair) while only adding much size to the blockchain when actually creating a transaction, and when creating a transaction adding what iss still a manageable amount of data. Such a system would allow the network to be resistant to quantum computing attacks against every implemented cryptographic method, and would make addresses reusable, while not drastically increasing the footprint of the blockchain. Optimized versions of such a signing algorithm (such as CMSS and GMSS) offer all of the above properties, and, given an efficient, cryptographically-sane, time-tested hashing algorithm, are extremely secure. GMSS, currently, is mildly impractical due to the time taken to generate private keys, and thus CMSS is the valid, considered option of the pair.

The hashing algorithm can be comprised of several chained hashing algorithms, so that if some of the hashing algorithms were ever cracked, or at the least attacked with some form of reduction function, the network would still be secure, as there would still stand unbreakable links in the signing algorithm due to the unbroken hashing algorithms. For a simplification, imagine I have the ability to perform four processes on a string. I do all four in order, twice, such that I take the output of process one, put it into process two, take that output, into process three, from three to four, then from four to one to two to three back to four, so they are stacked and none end the chain without also appearing elsewhere in the chain. A mild acquaintance of mine knows how to reverse processes four and two, but is unable to undo processes three and one. Given the output, he is able to reverse it from 8 stages to seven stages of length (or how the string of text I had appeared once it went 1->2->3->4->1->2->3 when it was about to enter process four again). From here, he would have to reverse process three in order to continue on. Since he is unable to do so, he is unable to reverse the entire function, despite having a fully functional attack against one of the components. Likewise, if several hashing algorithms are chained together (such as is done in X11/X13/X14/X15/X<your weekly flavor>), multiple algorithms can be broken without causing insecurities in the currency.

While the isn't the guaranteed be-all-end-all solution to the quantum computing problem, lamport-based signature schemes and other similar schemes based only on the cryptographic integrity intrinsically provided by hashing functions is a promising next step in future-proofing cryptocurrency networks. Such a system also opens the interesting possibility of a tradeoff between computational power to generate a private key, and the security/size of the keypair, though the security offered by a default-parameter implementation of aforementioned algorithms would provide more than sufficient security.

Fold Proteins, earn cryptos! CureCoin.
https://bitcointalk.org/index.php?topic=603757.0
1498350690
Hero Member
*
Offline Offline

Posts: 1498350690

View Profile Personal Message (Offline)

Ignore
1498350690
Reply with quote  #2

1498350690
Report to moderator
1498350690
Hero Member
*
Offline Offline

Posts: 1498350690

View Profile Personal Message (Offline)

Ignore
1498350690
Reply with quote  #2

1498350690
Report to moderator
1498350690
Hero Member
*
Offline Offline

Posts: 1498350690

View Profile Personal Message (Offline)

Ignore
1498350690
Reply with quote  #2

1498350690
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ChasingTheDream
Sr. Member
****
Offline Offline

Activity: 293


View Profile
July 06, 2014, 10:02:54 PM
 #2482

Hey guys! Work continues on conference-related stuff, but we developers are also brewing a few other elixirs of interest.

One of the ideas thrown around the virtual, coffee-stained conference table recently was the use of quantum-computer-resistant signature algorithms. Without going too deep into concepts tangentially related the matter at hand, hashing functions, due in part to the 'loss' of data that occurs during the function (Imagine a simple example of a 'secret' being the two numbers 12 and 20. A *very* simple, collision-prone, insecure method of verifying those numbers at a later point in time without storing the actual numbers would be to store some mathematical, repeatable function of the two, something such as multiplication. If a person were able to acquire the hash '240' and try to find the original inputs, they would get a ton of matching input pairs: (1, 240), (2, 120), (3, 80), ... (15, 16). This availability of collisions makes the actual function 'lossy'. Such an example is clearly an exploitable system, and is only for visualization purposes. The complex reduction, data loss, and mixing occur primarily through logical (AND, OR, XOR) operations, rolling reels of numbers effecting each other, sponge functions, etc., and make reversing an output back to an input 'impossible'.) are assumed to map inputs to realistically-unique outputs of a (usually) fixed length. As such, they are not prone to math-based attacks from quantum computing algorithms against classical computational encryption algorithms (RSA, ECDSA...).

What's so important about cryptographic signatures? For the purposes of a terribly inaccurate analogy, imagine your cryptocurrency wallets as a checkbook. You can write an amount, a destination, and a dollar value, but without your signature, the filled-out check has absolutely no ability to actually transfer currency. However, once you put your signature (which is, historically, important since they are *relatively* hard to imitate as well as hard for the signer to deny signing the check) on the check, it can be used to transfer funds. If you wrote a check for $10 to your friend but never submitted it to the bank (blockchain), the money never gets transferred. However, once the check gets cashed by your friend, the funds get transferred from your account to your friend's, and if you later deny signing the check, someone can simply show your signature. Either your signature was compromised, or you signed the document. This is known as a promise of non-repudiation. Signatures on the blockchain work to ensure that anyone can see the balance of an address (to verify you have the money you are trying to spend), but you can only spend money from an address you have control over. Asymmetrical cryptography allows for signatures to be privately generated but publicly verified.

Bitcoin addresses are formed in the following manner: address = Base58(versionByte + RIPEMD-160(SHA-256(publickey)) + SHA-256(SHA2-56(RIPEMD-160(SHA-256(publickey)))).substring(0, 4)) where ‘+’ represents a concatenation operator. Fun, right? If you prefer a visual simplification:


As such, simply accepting coins at an address does not reveal your public OR private key to the network. As such, the Bitcoin network is unable to differentiate between a valid and an invalid address--the only possible sanity check is a built-in checksum as shown above (the second, partial SHA256D hash appended to the end) which helps to eliminate mistypes. However, due to the nature of hashing functions being assumed to be one-way, the only way we can prove we own such a certain address, when we decide we want to spend the coins, is to publicly reveal the public key. In the absence of an efficient way to factor large numbers (either by an *extremely* unlikely breakthrough in mathematics, or more likely through the practical implementation of Shor's algorithm (or in the case of ECDSA, a modified derivative) or another quantum-computer-algorithm), ECDSA and RSA are extremely secure. However, when very large numbers can be efficiently factored, there are serious concerns about the safety of classic computational cryptography as it exists today. The only way the Bitcoin network would be safe in the event of a quantum computer capable of factoring large numbers would be to switch to a one-time-use address system. Today, one Bitcoin address can send and receive as many transactions as desired with safety. However, due to the nature of address generation above, after the address signs one transaction, the public key is revealed, in order to prove ownership of the address. Until a valid transaction originates from an address, the public key behind the address is safely masked by one-way cryptography (hashing functions). However, upon signing a transaction and broadcasting the public key, quantum computer attacks on that address become possible.

In a post-quantum-computing environment, as soon as an address signs a transaction, and remaining coins on the address are put at risk. As such, the various methods by which Bitcoin addresses are used multiple times today (tip jars, many payment processing services, etc.) would have to transition to a system of one-time address use, which not only decreases the compressibility of the blockchain, but also acts to make the currency harder to use. Imagine having to give your workplace a new bank account to deposit for every payday...

ECDSA has several properties that make it desirable for use in efficient cryptocurrencies: small signature size, fast verification, and small public key size. Additionally, the computational power required for key generation is trivial.

Any alternative to ECDSA aimed at being quantum-computing-resistant must, to avoid blockchain bloat and computational bloat, have relatively small signatures, public keys, and be easy to verify, allowing for network growth. Under the validated assumption that cryptographic one-way algorithms such as the popular SHA-family of hashing functions are secure against quantum-computers based on their reliance on lost data rather than on mathematically-hard problems, signatures built on top of hashing algorithms inherit similar properties. One simple example of such a signature method is the Lamport Signature, which is a one-time signature.
To summarize Lamport (when used with SHA256, and where 'User' refers to a computer generating and using an address):
-> User generates 256 random inputs (preferably somewhat long, and a mix of numbers, letters, symbols, and even non-printable characters if desired)
-> User divides these 256 inputs into 128 pairs of two inputs
-> User hashes each input and stores the hash output
-> User publishes all 256 outputs to the network (for our purposes, consider this group of 256 outputs to be the public key and address!)
-> User signs away coins the network recorded as belonging to the published public key/address by:
--->User writes and hashes a transaction message (simplification: "I sign all 8.3 coins from transaction (TxID) to address (address)")
--->User lays out the SHA256 hash in binary
--->User submitts the corresponding private keys (For example, if they were signing the four bits "0110", they would submit the first (position: zero) private key from the first group, the second (position: one) from the second group, the second (position: one) from the third group, and finally the first (position: zero) from the fourth group) to the network. The network can then hash the private keys and see that they match the public keys, and can also verify that the user signed that particular message by hashing the message, and seeing that only the private keys corresponding to the binary representation of the hash of the message are published, while the others (the 2nd in the 1st set, the 1st in the 2nd set, the 1st in the 3rd set, and the 2nd in the 4th set) are not made public. If the address owner were to sign another message, he or she would have to reveal other parts of their private key, which compromises the security by allowing full sets (rather than one of two hashes in a set) to be published, allowing an attacking party to possibly forge messages. As such, Lamport signatures are one-way, one-use.

Lamport signatures have two obvious shortcommings: huge public key sizes, and one-time use.

However, the basic logic lamport signatures are based on can be extended in such a way that a Lamport-esque signature scheme can be reduced to a *very* small public key (in some capacity smaller than ECDSA) as well as having reasonable signature sizes (larger than ECDSA, but not large enough to be impractical for blockchain usage). Such implementations use merkle trees to make signatures able to sign huge amounts of transactions (think 2^20 to 2^40, far beyond practical application, and thus not limiting the effectiveness of an address generation/transaction signing algorithm pair) while only adding much size to the blockchain when actually creating a transaction, and when creating a transaction adding what iss still a manageable amount of data. Such a system would allow the network to be resistant to quantum computing attacks against every implemented cryptographic method, and would make addresses reusable, while not drastically increasing the footprint of the blockchain. Optimized versions of such a signing algorithm (such as CMSS and GMSS) offer all of the above properties, and, given an efficient, cryptographically-sane, time-tested hashing algorithm, are extremely secure. GMSS, currently, is mildly impractical due to the time taken to generate private keys, and thus CMSS is the valid, considered option of the pair.

The hashing algorithm can be comprised of several chained hashing algorithms, so that if some of the hashing algorithms were ever cracked, or at the least attacked with some form of reduction function, the network would still be secure, as there would still stand unbreakable links in the signing algorithm due to the unbroken hashing algorithms. For a simplification, imagine I have the ability to perform four processes on a string. I do all four in order, twice, such that I take the output of process one, put it into process two, take that output, into process three, from three to four, then from four to one to two to three back to four, so they are stacked and none end the chain without also appearing elsewhere in the chain. A mild acquaintance of mine knows how to reverse processes four and two, but is unable to undo processes three and one. Given the output, he is able to reverse it from 8 stages to seven stages of length (or how the string of text I had appeared once it went 1->2->3->4->1->2->3 when it was about to enter process four again). From here, he would have to reverse process three in order to continue on. Since he is unable to do so, he is unable to reverse the entire function, despite having a fully functional attack against one of the components. Likewise, if several hashing algorithms are chained together (such as is done in X11/X13/X14/X15/X<your weekly flavor>), multiple algorithms can be broken without causing insecurities in the currency.

While the isn't the guaranteed be-all-end-all solution to the quantum computing problem, lamport-based signature schemes and other similar schemes based only on the cryptographic integrity intrinsically provided by hashing functions is a promising next step in future-proofing cryptocurrency networks. Such a system also opens the interesting possibility of a tradeoff between computational power to generate a private key, and the security/size of the keypair, though the security offered by a default-parameter implementation of aforementioned algorithms would provide more than sufficient security.

Very interesting post!  I had no idea the issues you are talking about were actually issues.  Thanks for sharing your thoughts.
LasersHurt
Member
**
Offline Offline

Activity: 70


View Profile
July 07, 2014, 03:04:48 PM
 #2483

There's a new post on the website with some updated information. Check it out!
crazyearner
Legendary
*
Offline Offline

Activity: 1638



View Profile
July 08, 2014, 11:01:33 PM
 #2484

Wheres price going up as one place am mining on currently says that cure is at market value of $0.11 per coin and climbing
FifthGhostbuster
Full Member
***
Offline Offline

Activity: 154


View Profile
July 09, 2014, 01:12:50 AM
 #2485

Price is climbing =p only about 10k cure left before price hits 1$!! keep minning/folding Now is the time!

Go CureCoin!
n0gard
Member
**
Offline Offline

Activity: 79

BTC - DGB - XMR


View Profile
July 09, 2014, 05:42:50 AM
 #2486

keep folding !!   Grin

crazyearner
Legendary
*
Offline Offline

Activity: 1638



View Profile
July 09, 2014, 08:29:21 PM
 #2487

Well looks like value gone from $0.11 last night back down to $0.06 and still going. Time to re buy in and make a nice 200% again if it goes back up but waiting to see where this next value stops at.
FifthGhostbuster
Full Member
***
Offline Offline

Activity: 154


View Profile
July 10, 2014, 05:37:32 PM
 #2488

Seems like there is some decent size buy orders though. Considering how many coins are available on the market. http://coinmarketcap.com/1     currently ranked 99

Go CureCoin!
crazyearner
Legendary
*
Offline Offline

Activity: 1638



View Profile
July 10, 2014, 06:45:36 PM
 #2489

Seems like there is some decent size buy orders though. Considering how many coins are available on the market. http://coinmarketcap.com/1     currently ranked 99

Thats true however this coin needs to get back no track as devs hardly active and all market moved to LTC would be nice to get it back in BTC markets and grow again but sadly seems more are begining to remove this coin  from their markets.
FifthGhostbuster
Full Member
***
Offline Offline

Activity: 154


View Profile
July 11, 2014, 05:45:31 AM
 #2490

Seems like there is some decent size buy orders though. Considering how many coins are available on the market. http://coinmarketcap.com/1     currently ranked 99

Thats true however this coin needs to get back no track as devs hardly active and all market moved to LTC would be nice to get it back in BTC markets and grow again but sadly seems more are begining to remove this coin  from their markets.

Devs are not hardly active though. Join in the IRC ha. They seriously never quit working. So many new things in the works Wink

Go CureCoin!
cameronpalte
Sr. Member
****
Offline Offline

Activity: 294


View Profile
July 12, 2014, 03:01:05 AM
 #2491

Seems like there is some decent size buy orders though. Considering how many coins are available on the market. http://coinmarketcap.com/1     currently ranked 99

Thats true however this coin needs to get back no track as devs hardly active and all market moved to LTC would be nice to get it back in BTC markets and grow again but sadly seems more are begining to remove this coin  from their markets.

Devs are not hardly active though. Join in the IRC ha. They seriously never quit working. So many new things in the works Wink

But that doesn't matter - most buyers don't come from IRC - what the coin needs to do is start getting buy offers starting getting back up to where it was at over a dollar each at 300 to the Bitcoin. And you do that by maintaining a strong public presence. The features are great but if no one hears of them they are useless.

Bitcoin Facuet List - Free http://bitcoinsfaucetslist.blogspot.com/
FifthGhostbuster
Full Member
***
Offline Offline

Activity: 154


View Profile
July 12, 2014, 05:50:18 AM
 #2492

Have you not checked out curecoin.net?Huh Alot of things are in the works.

Go CureCoin!
LasersHurt
Member
**
Offline Offline

Activity: 70


View Profile
July 12, 2014, 02:48:35 PM
 #2493

Seems like there is some decent size buy orders though. Considering how many coins are available on the market. http://coinmarketcap.com/1     currently ranked 99

Thats true however this coin needs to get back no track as devs hardly active and all market moved to LTC would be nice to get it back in BTC markets and grow again but sadly seems more are begining to remove this coin  from their markets.

Devs are not hardly active though. Join in the IRC ha. They seriously never quit working. So many new things in the works Wink

But that doesn't matter - most buyers don't come from IRC - what the coin needs to do is start getting buy offers starting getting back up to where it was at over a dollar each at 300 to the Bitcoin. And you do that by maintaining a strong public presence. The features are great but if no one hears of them they are useless.

Maintaining a strong public presence and building buy pressure takes a community effort. One cannot expect to sit back and relax while other people do the work needed to spread the word and build value.

The developers should be doing what they do best, improving the coin and the core services around it. The Community should be doing things like bugging Merchants, voting on places like CoinPayments (to make it much easier for merchants), posting on relevant forums and groups, etc.

Bitcoin did not become huge because 2 core developers did all of the work to get the word out.

And last - do recall this is a BitCoinTalk Forum thread. CureCoin has its own presence at CureCoin.net, and it has the IRC channel. There's a Reddit, LinkedIn, GooglePlus, Facebook, Twitter... If you feel like it's a bit quiet here, look around.
yavuzc78
Hero Member
*****
Offline Offline

Activity: 756


View Profile WWW
July 12, 2014, 05:51:25 PM
 #2494


bezekal
Jr. Member
*
Offline Offline

Activity: 56

Digital Design


View Profile WWW
July 14, 2014, 01:25:58 AM
 #2495

I wish this coin was more successful

Earn Devcoins by Writing
DVC: 1LMio17dWNBEPHW9KXpacMNe6vNCsanDzw
ChristianVirtual
Member
**
Offline Offline

Activity: 71


View Profile
July 14, 2014, 03:35:45 AM
 #2496

Something wrong with the current allocation concept. As per pool info the team produced 4.6M PPD, much less compared to normal day. Luck of for those who made it before the stat server stopped. Unlucky for those who's point comes in the next batch.

Really suggest to build some safety mechanism in. Right now it doesn't matter too much, but one the coin grow and big money comes in they might not accept that unbalance.

The easiest one is that 7844 points get only fully allocated when the stats server was fully active. A downtime of stat server of 12 hours should reduce the daily coins to 3922. And increase once that stat servers are back.

Kind of "cut and carry over". I know the points in PG don't get lost, they might get delayed. The same flow the "coin cake" should take
Vorksholk
Legendary
*
Offline Offline

Activity: 1554



View Profile WWW
July 14, 2014, 04:08:29 AM
 #2497

Something wrong with the current allocation concept. As per pool info the team produced 4.6M PPD, much less compared to normal day. Luck of for those who made it before the stat server stopped. Unlucky for those who's point comes in the next batch.

Really suggest to build some safety mechanism in. Right now it doesn't matter too much, but one the coin grow and big money comes in they might not accept that unbalance.

The easiest one is that 7844 points get only fully allocated when the stats server was fully active. A downtime of stat server of 12 hours should reduce the daily coins to 3922. And increase once that stat servers are back.

Kind of "cut and carry over". I know the points in PG don't get lost, they might get delayed. The same flow the "coin cake" should take


The backend software is showing a total of the correct number of points in the last round, and continues to run well, though I'm going to make some modifications tomorrow to fix a few small issues. The frontend stats.curecoinfolding.com page, which aside from time synchronization is completely independent of the actual backend server, seems to be having issues which I am looking into currently.

Here is the backend XML showing up for your account:
Quote
<user>
<username>ChristianFAH</username>
<total>9062757</total>
<gain>0</gain>
</user>

After a bit of investigating it appears due to the fact that it is scrabbling user data from the stats page for looping through an array of user scores, but it is grabbing the user scores from here: http://fah-web.stanford.edu/cgi-bin/main.py?qtype=teampage&teamnum=224497 which caps out at the top 1000 users, so the software is throwing an index out of bounds exception, of course. What's surprising is that this issue didn't come up until now.

Either way, the backend fetches stats for each user from http://fah-web2.stanford.edu/teamstats/team224497.html which doesn't have the 1000 user limit. The backend is working perfectly fine, and coins should be going out at the appropriate rate regardless of the frontend error. If this is NOT the case, please let me know.

I'll work on migrating the public pure-aesthetics frontend (stats.curecoinfolding.com) over to use http://fah-web2.stanford.edu/teamstats/team224497.html sometime tomorrow, and so all stats should be updated and working correctly there by the day after.

Fold Proteins, earn cryptos! CureCoin.
https://bitcointalk.org/index.php?topic=603757.0
ChristianVirtual
Member
**
Offline Offline

Activity: 71


View Profile
July 14, 2014, 02:19:27 PM
 #2498

Overall the mechanics are ok, my point remain that I still struggle that on days when the stat server is down 200kPPD makes around 1000 coins which is much more compared to regular days, when stat server are up. It has a quite a gamble character. And whenever the stat server comes back the ratio is much worse.

FAH has the concept of equal points for equal scientific work (letting the discussion another that out of here). I think a similar concept should be build in the coin allocation; a pro rata allocation based in valid hours for stats update. No official stat updates, for all users, no coins.

As for the stat servers:
https://foldingforum.org/viewtopic.php?nomobile=1&f=18&t=26191&start=90#p266974
merc84
Hero Member
*****
Offline Offline

Activity: 770


View Profile
July 15, 2014, 12:03:13 PM
 #2499

http://www.foldingcoin.net/ What The??
LasersHurt
Member
**
Offline Offline

Activity: 70


View Profile
July 15, 2014, 03:21:01 PM
 #2500


Begun, the clone wars have.
Pages: « 1 ... 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 [125] 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 ... 211 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!