Bitcoin Forum
June 19, 2018, 04:38:52 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 ... 86 »
221  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][AR2] Argon2Coin new PoW algo, CPU friendly on: December 21, 2015, 04:17:34 AM
Selling Argon2 coins for 0.000075 BTC/coin.

you maybe want to buy for less than your sell price?
selling 1000 AR2 for 3000 CURE (right now cure only 0.00002381)

Not interested in spending much CURE, but I'll buy 300 AR2 for 750 CURE, get the market moving a tad Smiley

deal
can send them B4vkfJSJjKDe85n6nRBtBybr9pg988nAEN
give me your AR2 addy

Sent the CURE, here's an AR2 address: 4oEvG1hJQmbSZjHrGs2iTtta7b1MpKAzWk

TxID for CURE: 1324c496fe2e30a7dbc9f244ab49b00f9d6b166ef8ef447a92457f301bf56b82
222  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][AR2] Argon2Coin new PoW algo, CPU friendly on: December 21, 2015, 03:57:05 AM
Ouch, we are speaking about a ram eater, it is possible then to mine it in a core2duo with 4gb of ram or it is a waste?

Dev have you think about  to add the coin to some other pool?

thanks

Some people seem to be having trouble with the Windows CPUMiner, but on Linux cpuminer is using less than 50MB of RAM to mine on 8 hyperthreaded cores.

even on ubuntu the standalone miner gives me only 90-100 H/s per thread on my box, while setgenerate gives a little over 300 H/s per thread. I tried building the miner with VS2013 but the libs are missing.

What CPU do you have? In an ubuntu VM I'm having no trouble mining at 700kH/s+ on 5 of my 6 5820k cores, and I spun up an EC2 instance a bit ago, which has no problem hitting ~1000 kH/s per (physical) core. I've noticed that, on machines with very high core counts, performance seems to take a hit below what I'd expect (AKA a c4.2xlarge, which has 4 cores/8 threads, actually runs FASTER than a c4.8xlarge when all cores are committed, although a c4.8xlarge runs at the same speed as a c4.2xlarge when only a fraction of the cores are wired). Also, the Argon2d hashing algorithm is, according to the whitepaper, designed to take advantage of modern x86-platform features, so perhaps you have a very old processor where these optimizations aren't available?

If you're running it in a VM, try some CPU benchmarks to make sure your virtualization isn't giving your CPU power a haircut.
223  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][AR2] Argon2Coin new PoW algo, CPU friendly on: December 21, 2015, 03:47:49 AM
Selling Argon2 coins for 0.000075 BTC/coin.

you maybe want to buy for less than your sell price?
selling 1000 AR2 for 3000 CURE (right now cure only 0.00002381)

Not interested in spending much CURE, but I'll buy 300 AR2 for 750 CURE, get the market moving a tad Smiley
224  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][AR2] Argon2Coin new PoW algo, CPU friendly on: December 21, 2015, 12:48:35 AM
Ouch, we are speaking about a ram eater, it is possible then to mine it in a core2duo with 4gb of ram or it is a waste?

Dev have you think about  to add the coin to some other pool?

thanks

Some people seem to be having trouble with the Windows CPUMiner, but on Linux cpuminer is using less than 50MB of RAM to mine on 8 hyperthreaded cores.
225  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][AR2] Argon2Coin new PoW algo, CPU friendly on: December 20, 2015, 09:25:57 PM
There's a surprising amount of argument over whether a small number of network connections means that GPU miners must be possible.

The number of network connections a particular client has is NOT an indicator of how many people are mining. I can spin up 100 servers with CPUMiner installed, and mine to one server, which would appear as one connection on the network.

Additionally, not everyone on a P2P network is necessarily connected to everyone else. If you are behind a firewall, then you can't directly connect to another peer behind a firewall. Sure, things like NAT punchthrough can help. Personally, I have 96 connections on an argon2 daemon running on an unfirewalled server, and 15 connections on one running inside a strict firewall.

The total network hash rate divided by the number of peers your client can reach isn't an estimation of the average mining speed--some nodes aren't mining at all, some are serving as private pools for tons of miners which don't appear as individual nodes on the network.

As for the feasibility of GPU mining, it certainly is possible. In fact, there's even an OpenCL implementation of Argon2d online. There are two versions of the Argon2 hashing algorithm: Argon2d and Argon2i. Argon2i is designed for password hashing (where side-channel timing attacks are a problem), while Argon2d is designed for uses like cryptocurrencies, focusing primarily on working well on CPUs compared to GPUs. Here's a quote from the specifications whitepaper:

Quote
Argon2 has two variants: Argon2d and Argon2i. Argon2d is faster and uses data-depending
memory access, which makes it suitable for cryptocurrencies and applications with no threats from side-channel
timing attacks. Argon2i uses data-independent memory access, which is preferred for password hashing and
password-based key derivation. Argon2i is slower as it makes more passes over the memory to protect from
tradeoff attacks.

There is an OpenCL implementation of Argon2d available in John the Ripper. Some benchmarking (http://comments.gmane.org/gmane.comp.security.phc/3303) shows that extremely powerful GPUs (like the NVidia Titan) clock in below the speed of a 4770k. A Titan x is marginally faster than the 4770k. This doesn't, of course, mean that a faster implementation (on either platform, CPU or GPU) is impossible, but preliminary OpenCL code written by people who certainly know what they're doing shows that GPUs aren't great at crunching Argon2d.

It probably wouldn't be particularly hard for a GPU miner to be written given an OpenCL implementation of Argon2d already exists, but the benefits of such a GPU miner probably wouldn't be spectacular.
226  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][AR2] Argon2Coin new PoW algo, CPU friendly on: December 19, 2015, 11:14:00 PM
Selling Argon2 coins for 0.000075 BTC/coin.
227  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][AR2] Argon2Coin new PoW algo, CPU friendly on: December 19, 2015, 11:05:39 PM
RPC PORT for solo mining 4444 or 5555 ? please help thanks


5555
228  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][AR2] Argon2Coin new PoW algo, CPU friendly on: December 17, 2015, 12:22:00 AM
To get the ball rolling on trading, offering 80 Argon coins for 0.01 BTC total.
229  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: December 16, 2015, 06:01:09 AM
Oh, and a team member Ivan has been working on putting together a calculator for people to estimate hardware costs and whatnot.

Here's how it looks: http://1.curecoinmirror.com/calculatordemo.html If anyone has anything they'd like added to the calculator, let me know! One feature I have considered is a drop-down to pick the video cards being used, but that seems to messy, given the wild differences different hardware configurations, drivers, etc. can produce (My overclocked 980 Ti gets about 550,000 PPD if running 24/7, although I can find sources on the internet that talk about it running as high as 800,000, and that's a huge margin for a calculator to assume).

We're just starting to test it, so let us know if you find any bugs or abnormalities. It isn't feature-complete yet.
230  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: December 16, 2015, 05:55:26 AM
thanks for the work and the good answers
so there will be swap of CC 1 to CC 2, and after we stop maintaining/mining/trading the CC 1 network ?
is there stats how many CC 1 coins already distributed with mining+folding+staking ?

finally fixed (again) one of the GPU so my ppd improved a little Smiley

Yup, there will be a full swap from CC 1 to CC 2. Given the nature of the new blockchain, it probably won't be automated (1.0 addresses don't make any sense in the context of 2.0) so there will be a semi-automated manual process for the conversion. 1.0 and 2.0 will run alongside each other for a while to facilitate this.

How many cc 1.0 coins have been distributed from mining + folding is easy to estimate. CureCoin has been out for about 585 days, which means 585 days of mining + folding. This should even out to around 9360 coins per day (7488 for folding, 1872 for mining), which equals 5,475,600 coins. Currently, about 23,499,116 coins "exist" on the network (most are not in circulation), the vast majority of which are tied up in the premine addresses used to pay out folders their 7488 coins per day, meaning that, staking factors not considered for premine addresses, there should be about 16,180,000 (which is 21,655,600 - 5,475,600) premine coins that aren't in circulation.

So, if the network reports 22,499,116 coins existing, and we should have about 16,180,000 coins still sitting in the premine holding addresses, then the 1.0 network should have about 6,319,116 total coins in circulation. As a result, it would appear that approximately 5,475,600 coins are from folding+mining, and 843,516 coins have been created from PoS.

This doesn't include dev payouts. I'm not sure of the actual monthly payout, but it shouldn't change the reserved premine numbers by more than a few percent.

And a quick reminder for anyone who doesn't feel like trudging through the last 20+ pages of forum posts: CC 2.0 will eliminate premines, except for the premine created to convert 1.0 coins to 2.0. We won't be paying out from a premine (or at all, the coins will be generated by coinbase on the network for folding, so we don't have to touch them), and the dev funds will also be created as coinbase in some fashion. So on 2.0, whatever number the network reports as the current coin supply will be the total coins in circulation.

Additionally (not sure if I've mentioned this before on the forums), 2.0 will have official burn addresses. While it may seem a bit silly, it'll allow any premined coins that weren't claimed during the conversion process to be officially destroyed, so they won't be counted as part of the coinbase, and everyone can be entirely sure that the coins are, indeed, gone--the burn addresses will be provably invalid, because the network won't allow outgoing transactions from them. Burn addresses have always been something that were obviously impossible addresses (such as an address made entirely, except for the checksum, of the same digit), but mathematically possible. While that was sufficient for everyone to agree that the coins WERE actually gone, network-enforced burn addresses are a cleaner, more elegant solution.

So in summary, there are somewhere around (including a high rough estimate for dev funds) 6,508,689 CureCoins that are currently in circulation and would be eligible for 2.0 conversion if it were to happen right now (realistically, it'll probably be within 1/2 a year or so, but the fact that 1.0 and 2.0 run side-by-side will slightly complicate this). If people are really interested in an exact number, I could have Josh give us a precise total on the current premine holdings Smiley.
231  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: December 13, 2015, 08:29:22 PM
I don't understand how CC2 will work
did Stanford or other scientific researcher/university even agree to be a CA/issue curecoins ?
how is the testing going?
there is sometimes talks about CC2 and then weeks of silence. i can understand the development can take a very long time
what is wrong with current model and coin (besides not getting security updates lately, and premine which folders community currently trust)
will exchanges accept CC2 ?

No DCN has agreed to be a CA yet; the initial 2.0 release will be us signing certificates for publicly-verifiable stats pulled directly from the DCNs. As the project gains momentum and Curecoin-related computation accounts for a higher and higher amount of their computational power, the hope is they will take over as CAs.

Testnet is going great! There's a beta a few posts up with binaries to try out, and we just added PoS.

The current, 1.0 coin has a premine that we payout from, and doesn't offer anything interesting (in regards to the technology itself) that sets Curecoin apart from any other cryptocurrency. We believe the features in 2.0 (Quantum-computer-resistant signatures, a ledger that grows in size with the number of addresses in active use rather than the number of transactions on the network (as in, if the number of users stays constant, and they all use the same number of addresses as they did earlier, the network doesn't take additional storage to run), and a jigsaw-stacking blockchain to prevent forking will interest people beyond the main goal of incentivising computational research. Smiley

As much as possible, 2.0 will adhere to the exact same RPC calls that 1.0 does, to make it easier for exchanges to trade it.
232  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: December 01, 2015, 04:41:25 AM
2.0.0a5 binaries are available here: http://1.curecoinmirror.com/2.0.0a5/2.0.0a5.zip.

As stated earlier, this release adds Proof-of-Stake to the 2.0.0a testnet. Also, the code has been cleaned up, so a compile, in Eclipse, straight from github with java 7 (1.7) should generate absolutely no warnings. The debug output from this new release has been modified to avoid "spamming" the terminal with as much unintelligible gibberish. In order to run, simply download and extract the zip file, and then double-click (on Windows) or run from the command line with java -jar Curecoin\ 2.0.0a5.jar (Linux/Mac) in order to start the daemon.

Then, use either the GUI, or the command-line Curecoin client to connect and interact with the testnet. Note that, in order to test PoS, you need to have an address WITH coins in it. Also, it can't have sent any coins or mined any PoS blocks in the last 50 network testnet blocks. This testnet purposefully has 50-block-ago coin calculation disabled, so that you can mine a block on a new address, and immediately mine a PoS block, as the network won't make sure that you didn't receive those coins more than 50 blocks ago. Obviously, final releases will be different, this is only so that people can effectively test it without having to mine 50 blocks on a generally-quiet testnet. If people want to schedule something, we could all plan a certain time to all mine on the network and submit PoS blocks, to test the network under more load. Internal simulations of network load have been successful, but a lab can never mimic real life.

In this version, PoS doesn't validate the balance you use for nonces, also for testing purposes. That way, pretty much any attempt at a PoS block will succeed, rather than failing due to missing a target with a low address balance. As such, you can send large amounts of coins to an address, stake, and then immediately move them to a new address and stake again. If anyone notices any bugs BESIDES THESE I would love to hear about them Smiley The ones I mentioned will be, of course, addressed in future versions where other components of PoS testing (for which these hacks are useful) have completed. It's a simple algorithm--client just "rewinds" the blockchain 50 blocks, checks the address's balance at that time, checks that balance against the claimed certificate balance, and validates/invalidates based on comparison. That way, coins sent to an address less than 50 blocks ago would not be included in the staking.

The PoS difficulty is set at 100000, as opposed to the PoS difficulty of 150000. Each coin in an address is worth 100 nonces, so an address with one PoW block (100 coins) would be as likely to mine a PoS block as a certificate signed for 10,000 nonces. This means that, on average, an address with 100 coins will be able to mine a PoS block every ~15 blocks. So mine a few blocks, get a good balance (300-500 coins) and try mining a PoS block on a few different blocks until it succeeds.

In Order To mine a PoS block you must use the command-line client, and type the undocumented command "trypos" without quotes. This will attempt to mine a PoS block. If you have a few hundred coins in an address, chances are a PoS block can be mined within a few network blocks.

Attempts to mine a PoS block can look like this (when unsuccessful):
Code:
Pos mining failed with target score 439887573721212
Which is above target 184467440737095

And like this (when successful, example shown is the address C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7 mining block 1215):
Code:
Successfully submitted block!
Certificate earned score 126737679078394
Which is below target 184467440737095 so earned PoS!

They can also reflect failures to mine a PoS block because of outgoing transactions occurring too recently from the main address.

Note that the above target (184467440737095) is equal to the maximum value of a signed 64-bit number (9223372036854775807) divided by the difficulty (100000) divided by two.

Subsequent attempts to mine a PoS block without the testnet receiving a new block should fail with the exact same target score as the previous attempt.

You can run the GUI simultaneously with the command line client, and you can run multiple of each simultaneously if you have nothing better to do. RPC is wide open (no authentication) so you can also connect with netcat or similar.

There's nothing in particular this public beta is checking for other than PoS blocks are being awarded at the expected rate, and don't generate any errors or exceptions. If you find other bugs, they probably existed (unless, possibly, they have to do with block validation/stacking) before this release, but I'd still love to hear about them. I am aware that the debug prints don't seem to go in order, this is a natural effect of non-linear syncing. Don't worry if the last block "added" in the command line is 269.


The next release (2.0.0a6 internal, 2.0.0a7 public release) will be a complete revamp of the source code. Everything will be more modular, streamlined, and efficient. In its current state, the goals of 2.0 are outgrowing the bounds of the current source code. Adding PoS involved a significant amount of code rework, so future versions will be more versatile for adding functionality. They will also have additional data embedded in the blocks in order to indicate things like block type. This code rework will be a forking change, and will likely come with a new genesis block.

The GUI is also going to be revamped, as I mentioned earlier, to use a new graphics engine I've been writing.

Quick recap of working 2.0 features in 2.0.0a5:
-Merkle Trees (instead of ECDSA) (Quantum-computer resistant, so large quantum computers couldn't be used to forge signatures for addresses)
-Variable-tree size (for addresses that can sign more transactions, but take more space for private key)
-OB (outstanding balance) table (instead of UTXO, or unspend transaction outputs) (Runtime complexity of finding address balance is O(1) rather than O(n) where n is number of unspent transactions)
-Proof-of-Work based on authority certificates
-Proof-of-Stake based on self-made 'null' certificates and transaction history
-Full transaction history lookup for any address, instantaneous balance lookups due to blockchain design

And the features that the current protocol would support, given a client with client-side code to handle:
-Partial blockchain storage
-Manual multisig (Merkle Tree roots broken up across multiple owners)

In "gethistory" requests, there is (currently) no distinction between PoS and PoW blocks.
Code:
gethistory C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1207:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1208:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1209:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1210:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1211:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1212:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1213:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1214:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1215:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1216:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
1217:COINBASE:100:C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7
Block 1215 is PoS, as would be visible looking at the null certificate for the block.

Testnet is, naturally, about getting things *working* rather than *efficient*, but you suggestions for efficiency improvements for the current code or proposed features are also welcome.

Testnet coins have no value. Don't mine them for profit. Don't sell them. Don't buy them. Testnet can be reset at any time, and coins WILL NOT transfer from the current testnet to any future valuable blockchains.
233  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: November 30, 2015, 05:47:17 AM
2.0.0a5 code is now on Github--will post binaries tomorrow. Occasional sync bug requires the client to be restarted, such as if it gets stuck in a loop.

Next update for the GUI will use a custom graphics engine I've been working on.
234  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: November 29, 2015, 07:18:23 PM
If anyone's interested, I pushed the first wave of PoS updates to github, which are in private testing. More updates to come soon. Smiley

Great! looking forward for more updates.

Thanks! Fingers crossed that I can push a PoS update to the 2.0 testnet sometime over Thanksgiving weekend. It will be a forking change to the 2.0 testnet, ofc.

Great to hear we are making progress. Do you have a target date for CC.20 launch?

thanks
Programming projects always seem to take orders of magnitude longer than it seems they should... but here's my optimistic timeline:
2.0.0a5 (PoS testnet update) will hopefully be in private team testing today, and public testnet release tomorrow, on Github and with compiled binaries here.
2.0.0a7 (Code cleanup) will hopefully see public release December 17th. No new (major) features, but the code will be far easier to read and work with. Bug fixes, etc.
2.0.0a9 (Variable difficulty, network timing, more advanced peer seeking mechanisms) will hopefully be public by Jan 3rd.

The version numbers skip, because 2.0.0a4 is the internal test, 2.0.0a5 is the public release, 2.0.0a6 is the internal test, 2.0.0a7 is the public release, etc. If no bugs are found in the internal test, the public release code is identical.

After that, it's mainly just fixing bugs the community finds, offering some bounties for any security issues, publishing a whitepaper on 2.0, and adding multisig. Things like code cleanup and refactoring will be ongoing tasks, with probably weekly? github pushes after 2.0.0a9's release. Given no drastic holes found in the 2.0.0a9 code, 2.0.0b1 should be out about a week after 2.0.0a9, which will just be the aforementioned code cleanup and whatnot.

The beta blockchain will start with the release of 2.0.0b1 with a new genesis block, and then subsequent beta releases will be more cleanup, bug fixes, and minor features, like RPC calls and whatnot. The beta blockchain will run for a few months, until we the developers and the community both feel it's solid, at which point we'll do a soft-launch.
235  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: November 26, 2015, 10:04:29 PM
Quite often (like this weekend), F@H servers have problems resulting in points not being rewarded on time and curecoins being paid a posteriori.
Will this fact be acceptable when CC 2.0 blockchain will totally be based on WU generation? Won't all transactions be blocked during 2,3,4 days?

Also, if CC 2.0 will rely on certificates delivered by "scientific authorities" (like universities) who's responsibility will be to secure that process against piracy from outside?

I have the feeling that CC 2.0 will be super robust against quantum computing but will rely on weak authorities. Like putting a huge armored door to a house with paper walls...

I think that if you want credibility and trust (thus investors) in a cryptocurrency you need to have it robust by itself and not needing to rely on any third party.

Relying on only one certificate authority is certainly a recipe for disaster. With the launch of 2.0, the Curecoin developers will still be signing certificates until Folding@Home decides they want to be in charge of the certificates. As such, we'll be signing certificates publicly (aka all certificates can be viewed on our website) based on Stanford stats. The server will automatically "spread out" the hourly bursts of points by signing certificates throughout the hour randomly.

Additionally, we'll have entirely separate, secure servers who can sign certificates that are worthless (as in, no coinbase transaction, no money from mining) to keep the network running smoothly, and to make sure the network never slows down simply because a certificate authority dropped out due to technical issues.

For your question on piracy, I assume you're talking about the party itself signing certificates incorrectly? Correct me if I'm wrong. There's nothing that can directly stop a university from doing this--however we will require the universities to have a public webpage of certificates. Anyone can check that the certificates are valid, and unless they are doing something like signing one rogue certificate every few days (which, in the scheme of things, probably isn't earth shattering) it should be fairly obvious that the distribution of certificates is off. It will require community vetting, and we'll also have web scraper tools to try to detect abnormalities in the certificate pages. This does require some level of trust, though. It's not something we've found a perfect solution for.

Yeah, 2.0 will be robust against quantum computers, and the CAs are likely the weak spot. There will be features in the network to allow CAs to recover stolen identities (namely, keeping several "master identities" safe and offline, and then signing a change of CA issuing address using multisig from these master identities.

You also PM'd a few questions, so I'll quote those here super quick:


Hi,

Thanks for all your work on CC.

I was hopping you'll publicly answer my post from 23 Nov...

I'm not a specialist so I'm aware some of my insights are probably not right but I have the feeling that we should not only aim for CC to just recover the folding costs (electricity) but it should become the second most valuable crypto after Bitcoin. Then we'll have ALL the GPU miners that will switch to folding. They want profit, we get science.

And if there isn't trust in the crypto people will not invest (buy) CC and it's value will not raise.

So my question is, wouldn't it be more effective to focus on the main CC 1.0 issues (e.g. the fact that it was pre-mined, that transactions are not anonymous etc) and what else could increase trust instead of searching for solutions that are intellectually satisfactory (like merkle trees) but are not such a big concern today?

Moreover, unless I'm wrong, frequent F@H server problems for rewarding points prove that they are not able to provide QoS (as they don't care about it). What will be the impact on CC 2.0 blockchain? We'll have all transactions blocked 2,3,4 days??

And what if a certificate authority will get attacked by pirates? We'll vote them out of CC? And if it is Stanford University? We won't fold anymore?

Moreover, universities are public entities so Govs can make pressure on them and this investors don't like very much...

Cheers,
M

I feel the main point here that I didn't answer above was the CC 1.0 issues. 2.0 will remove the premine (all 1.0 premine coins won't transfer to the 2.0 network).

For anonymous transactions, that isn't the goal of Curecoin--while I respect the anonymity offered by other cryptocurrencies, I feel it lends the currency to a lot of unethical use, and I personally believe that the advantages of positive public images and whatnot will outweigh the advantages of having truly anonymous transactions, though I could be wrong. On principle, I don't want to develop a cryptocurrency that can be easily used for immoral activities and to break laws. That being said, I appreciate the purpose of anonymity, and I believe the pseudo-anonymity offered by Bitcoin and Bitcoin-derivatives should be sufficient for most legitimate needs for anonymity. Naturally, the anonymity of Curecoin is the same as Bitcoin--addresses themselves don't have personally-identifiable information, but any transaction can be resolved to a sending and receiving set of addresses.

Governments can certainly pressure universities--public proof of something of this nature would be grounds for a network voting consensus to remove the CA from the network. In reality, a government could likely do two things:
1) Force a university to stop signing certificates (Network wouldn't suffer)
2) Force a university to sign rogue certificates (Any harmful amount should be possible to catch)

A certificate authority can't determine whether a given certificate will solve a block or not, no there can't be any foul play with universities signing some certificates they know will create blocks and others they know won't.

Thanks for the questions, it's always great to get these thoughts in a visible place. As covered above, 2.0 isn't perfect--any system that requires *some* trust will have *some* possibility of abuse. The diversity of research, the size of WUs, and the time they take to complete make any kind of distributed WU checking impossible, and open-sourcing tools for WU verification could potentially allow people to game WU submissions to appear correct despite being wrong. Many WUs also aren't strictly deterministic--some may come up with ever-so-slight differences depending on the capabilities of the underlying hardware. Not enough to jeopardize the science, but enough to make distributed verification even harrier.

Let me know if you have any other questions or concerns, or I missed something. Smiley

Oh, and to add on to the above about investor confidence: compromised certificate authorities wouldn't jeopardize the ability of the network to function. Although blocks could potentially be minted unfairly, the way the network is designed (stacking blocks must be from different CAs, etc.) one or two simultaneously compromised CAs couldn't rewrite blocks, reverse transactions, or stop the network from running. The more CAs in existence, the more that could be simultaneously compromised without affecting any network security. We'll be running tons of CAs putting out regulation blocks (with no block reward, mined by dedicated addresses) which will keep the network on-time and in-step.
236  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: November 25, 2015, 08:32:53 PM

Thanks for the heads up, sometimes Stanford's server doesn't respond to the hourly stats request, which can cause the blank screen.
237  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: November 25, 2015, 08:31:35 PM
If anyone's interested, I pushed the first wave of PoS updates to github, which are in private testing. More updates to come soon. Smiley

Great! looking forward for more updates.

Thanks! Fingers crossed that I can push a PoS update to the 2.0 testnet sometime over Thanksgiving weekend. It will be a forking change to the 2.0 testnet, ofc.
238  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: November 25, 2015, 08:30:39 PM
What's you folding name?

Please PM me why you need this, and how you have the ability to help.

Thanks

I was just going to compare your stats on Extremeoverclocking and the official Stanford stats. There isn't anybody folding with the name "meganite"

I appreciate your help, but I'm not new at this. Been folding since PS3 days. Need one of the pool admins to chime in; Cygnus, anyone?

Hey meganite! PM me your folding@home username and I'll look into the stats. Stanford's end did have a hiccup a few days ago (visible on EoC stats graphs as a zero-sum day for every team), but you should be receiving payments if you're set up correctly.

Here's how to set up your folding:
-> Create an account with a passkey from Stanford's Folding@Home website
-> Create an account with the exact same as your folding name on cryptobullionpools.com
-> Make sure you fold for team 224497 (Team Curecoin)

If you've done the above correctly, I can help you troubleshoot further. Smiley
239  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: November 11, 2015, 04:21:43 AM
If anyone's interested, I pushed the first wave of PoS updates to github, which are in private testing. More updates to come soon. Smiley
240  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]CureCoin -Earn while you solve cures for Cancer. June 11 2015 Client update on: November 04, 2015, 03:09:49 PM
Hey everyone, update within the next week or so to the 2.0 alpha testing which will include PoS.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 ... 86 »
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!