The source that Hazard posted contained the old, pre-release genesis block, the only difference in main.cpp from what I got off of github yesterday was this:
diff ../../elacoin-hazard/src/main.cpp main.cpp
887c887
<       diff = GetDifficulty2(FindBlockByHeight(nHeight-1));
---
>       GetDifficulty2(FindBlockByHeight(nHeight));


(Granted, I downloaded it about 20 pages after he posted it so I have no way of knowing if released the source with the real genesis block then changed it later)

Fun watching the debug log as the blocks come in.  Looks like there is 1 or 2 a second.  Also seeing lots of long block chain re-orgs:

REORGANIZE: Disconnect 6 blocks; 42f941a6031dc3b41af2..cc03f278f04afbde208a
REORGANIZE: Connect 7 blocks; 42f941a6031dc3b41af2..0c8845a4d9d15e7a7507

REORGANIZE: Disconnect 5 blocks; 42f941a6031dc3b41af2..40341ca5c6965be3481e
REORGANIZE: Connect 6 blocks; 42f941a6031dc3b41af2..cc03f278f04afbde208a

REORGANIZE: Disconnect 4 blocks; 42f941a6031dc3b41af2..4acdf17c62282444c8f8
REORGANIZE: Connect 5 blocks; 42f941a6031dc3b41af2..40341ca5c6965be3481e

And the longest I've seen:
REORGANIZE: Disconnect 13 blocks; f243992c9eda69cee1e7..71117064476dd175253f
REORGANIZE: Connect 14 blocks; f243992c9eda69cee1e7..311620c256d3b658ff55

and

REORGANIZE: Disconnect 15 blocks; 651da75d037edf65f818..6788c730fb52a72f2a41
REORGANIZE: Connect 16 blocks; 651da75d037edf65f818..c9039814ed1318c2e2ce

I agree.  History has now shown that starting an alt coin that uses the same hashing algorithm as an existing, strong, coin is a bad choice.  We now have had several examples of this.

The first was Namecoin, where the difficulty went way up then mining power left and it was stuck for several months at super-high difficulty.

The next was CoildCoin (CLC).  It had merged-mining right from the start in an attempt to have a higher hashrate. However, Luke-Jr (who controled the Elgius pool at the time) set the pool to merge-mine it and not allow anyone elses blocks or allow any transactions in his blocks.  Since Elgius had a much higher hashrate then the rest of the network, he was successful and the network stalled.

For Terracoin (TRC) a single person with a bitcoin ASIC starts mining and causes the difficulty to fluctuate wildly (first difficulty calculation method) or causes it to go up and stay up (second difficulty calculation method).  That person had over 50% of the hashpower and could have done much more damage (and still can if they want to).  They could mine their blocks exclusively, ignoreing any blocks found by anyone else, thus getting all the block rewards, excluding others transactions, and doing double spends at will.

re-using the same hashing algorithm sounds like a good idea, it takes less effort, you don't have to worry about introducing new bugs, and you can take advantage of all the optimized software/hardware to get your hashrate up.  However, an attacker has access to the same software/hardware that you do, may already have a lot of it, and, often has a vested interest in a different coin succeeding so have a reason to use those resources to attack a new chain.

This is certainly true for sha256 and is mostly likely true for scrypt now (if not, certainly when scrypt fpga's come out it will by).

So this means that there is going to be another mandatory update sometime in the near future with yet another difficulty adjustment algorithm?

I like the idea, but have a couple of comments

whitepaper: "BLAKE512, SKEIN512, SHA3-512 (KECCAK512), and SHA2-512 are incorporated with both Salsa20 and Chacha20 stream ciphers."

I like how this makes fpga's and asics harder, but it also means that if there is a flaw in any one of these hashes or stream ciphers then the coin fails.  Is there any other way to achieve this goal?



whitepaper:  "Transactions will largely stay the same as in BTC; coin age will be calculated from the the timestamp of the block in which it appears."

Why calculate from the timestamp and not the block height?  timestamps can be incorrect, the block height can't be. They both give estimates since the block height to time calculation is based on the target block time that isn't always met, but it is good to base as much as possible on truths inherent to the blockchain.

You should try Tenebrix: https://bitcointalk.org/index.php?topic=45667.0

Should be done "real soon now"

The poster was probably alluding to an article like this one: http://www.usnews.com/news/articles/2012/03/14/pilfered-tide-detergent-new-drug-currency

Authorities say a bottle of Tide detergent is relatively easy to steal, hard to track, and can fetch anywhere between $5 to $10 on the black market. Normal retail prices range from $10 to $20.

I like that you are hosting multiple faucets, thanks.

If these are funded by advertising revenue, how are you going to allocate the revenue between them?  Are you tracking which page/faucet the click came from, dividing it equally, dividing it based on number of faucet requests, or something else?

Yes please: 1M7pkz73gX4vkeUACGQaTtgf9T6XyRiXV8

I'd have the structure be like this:
# Alternative Monetary Systems
   # Crypto Currencies
      # Bitcoin
      # Litecoin
      # ...
   # Local Currency Systems

I wouldn't put 'market' under data either.

Solidcoin does this (or did this, with the last change I'm not sure it still does).

I think a better way to capture changes in demand would be to base the reward on  the rate of change of the difficulty instead of the absolute value of the difficulty.  If the difficulty is rising rapidly, the block reward goes up.  If the difficulty isn't changing, the block reward goes back to the standard 50 coins per block.  For example, if the difficulty re-targets from 1,000 to 1,500 then the amount of coins per block goes to 75, if, at the next retarget the difficulty stays at 1,500 then the reward goes back to 50, if it jumps to 3,000 then the reward would go to 100.  This keeps technological breakthroughs from having a permanent effect.  The exact percentage to raise it, and how long to keep it raised would have to be determined.

But it would take hours, if not days for enough people to notice and start ignoring you.  In that time a lot of damage would be done.

These things are very complicated and take a long time to understand, I doubt there are more than a few people in the bitcoin community that really understand them. I'm not even sure these things belong in the block chain instead of being handled outside of it (via Open Transactions or something similar).

Extending the single-purpose bitcoin infrastructures (exchanges and block explorers and mining pool software and etc.) to be multi-coin is a real accomplishment.  Sites like allchains.info, blockexplorer.sytes.net, and the multi-coin exchanges are a big improvement over having lots of coin-specific sites.  You might not consider them innovative, but you aren't giving them enough credit.

Most of attacks on the alt-chains were possible against bitcoin too, bitcoin was just lucky that no one attacked when it was young and didn't have the value it has now.  Even so, a well-funded adversary could easily spam the bitcoin block chain.  Be glad that these issues are being worked out on the alt-chains where the stakes aren't as high.

There has also been a lot of experimentation with the fundamental economic models.  No one knows if  a coin should be deflationary, inflationary, or stable-value, nor do they know the best way to accomplish the goal.  Pre-mining to provide funding for improvements versus no premine and no funding for improvements has been another area of experimentation (it looks like pre-mining lost). The economic basis for a coin can't be changed easily (if at all) so it isn't surprising that is the first area that is worked on.

Merged-mining is pretty innovative, as is namecoin,  both were developed this year.

I think you are trying to get people riled up so that they try and prove you wrong.

Your probably right on this.  It is very hard to make substantial changes to an existing block chain.

That's an impressive improvement.  It doubled my hash power with a small decrease in power consumption.  My spidey sense is tingling, there will be a big jump in difficulty soon.

On the old miner I found that I'd get a small increase in hash power by running more threads than cores, for this one there isn't any advantage to extra threads.

The purpose of the Internet Archive isn't to publicize bitcoin, it is "universal access to all knowledge".  Their accepting bitcoin is great, breaking your pledge because they don't position it as prominently as paypal seems rather petty.

I'm going to come back to the newbie forum and post on random threads.

I won't be taking over, but since I have been digging around the litecoin code recently I decided to see how hard it would be to port my changes to fairbrix.  If people are really still interested in fairbrix they should put together a bounty pool to pay for future updates.

I made changes in line with what coblee did for litecoin, but modified them some to take into account the differing block times and current value of a coin.  I've also put in some other changes that I think will help fairbrix resist attack in the future.  All the changes I made relate to spam transactions being included or relayed by honest nodes.  If an attacker controls a significant portion of the hash power (a real possibility in fairbrix) he can bypass these checks and write 1,000,000 byte blocks.

You can get the source from: https://github.com/beecee1/Fairbrix   sorry, no pre-compiled binaries.

If you like what I have done, you can donate: fVQZtuBPRdVjbNskqHLB4e75Uq64dM9vWN

Here is a description of all the changes I made (and, you have the source code so you can verify it yourself).


In main.h:

From:
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
To 125,000 bytes:
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/8;
Why: reduces the size of a block that an unmodified client will generate, helps protect against block-chain growth attacks


From:
static const int64 CENT = 1000000;
To:
static const int64 CENT = COIN/100;
Why: easier to read, no real change


From:
static const int64 MIN_TX_FEE = 50000;
static const int64 MIN_RELAY_TX_FEE = 10000;
To:
static const int64 MIN_TX_FEE = 1000000;
static const int64 MIN_RELAY_TX_FEE = MIN_TX_FEE;
Why: increase the minimum fee (when fees apply) to 0.01.  This is less than litecoins so you that the fee isn't quite so large when you send an output that is nearly a cent.  However, there is code elsewhere that will increase this fee for very small outputs.


From:
int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;
To:
int64 nMinFee = (1 + (int64)nBytes / 500) * nBaseFee;
Why: This makes large sized transactions cost a more than before.


From:
if (nNewBlockSize < 27000)
To:
if (nNewBlockSize < 12000)
Why: since blocks are faster than in bitcoin, reserve less space for free transactions.


From:
        if (nMinFee < nBaseFee)
            BOOST_FOREACH(const CTxOut& txout, vout)
                if (txout.nValue < CENT)
                    nMinFee = nBaseFee;
To:
        BOOST_FOREACH(const CTxOut& txout, vout) {
            if (txout.nValue < CENT/10) { // outputs smaller than 0.0001
                nMinFee += nBaseFee * 10; // fee of 1
                smallTxOutCount++;
            }
            else if ((txout.nValue < CENT)) {
                nMinFee += nBaseFee;
                smallTxOutCount++;
            }
        }
Also add:
        if(smallTxOutCount > 15)
            nMinFee = MAX_MONEY;
Why:  This is the core change to limit dust spam.  Instead of a flat fee for small outputs charge a fee for each small output.  If there are more than 15 small outputs than don't allow the transaction at all.




In main.cpp

From:
if (dFreeCount > GetArg("-limitfreerelay", 15)*10*1000 && !IsFromMe(*this))
To:
                dFreeRelay = GetArg("-limitfreerelay", 5)*10*1000;
                dPartialRelay = dFreeRelay * 0.75;
                dNewFreeCount = dFreeCount + nSize;
                if( !( dNewFreeCount <= dFreeRelay
                    || dFreeCount < dPartialRelay
                    || IsFromMe(*this)
                  )
                )
Why: another spam attack mitigation. Don't relay more than (on average) 5000 bytes of free transactions a minute.  This is roughly equivilant to 20 normal sized transactions per minute, which is far in excess of the current volume.


Add:
        (nHeight == 15000 && hash != uint256("0x7c7fc755c19616fd3eb156b53dae2bbf058972e0731f3d0ee54785cc222f4bbf")))
Why:  add a checkpoint lockin at block 15000



From:
bool fAllowFree = (nBlockSize + nTxSize < 4000 || CTransaction::AllowFree(dPriority));
To:
bool fAllowFree = (nBlockSize + nTxSize < 1800 || CTransaction::AllowFree(dPriority));
Why:  Since blocks are faster in Fairbrix, don't allow as many exempted free transactions. (But they are slower than Litecoin's so allow more than that).



In wallet.cpp:

From:
int64 nPayFee = nTransactionFee * (1 + (int64)nBytes / 1000);
To:
int64 nPayFee = nTransactionFee * (1 + (int64)nBytes / 500);
Why: matching a change made in main.h

I have a minute or so of delay between when the splash screen goes away and the gui shows up.  How long have you waited?  If you have tons of spam transactions it could be a while.

Check the debug.log, I'm not sure where it is under windows but look in the same directory as the wallet.dat file.  If it is still getting written to then the process is still working and hasn't gotten around to showing the window.

It is really just an acknowledgment that my imagination is limited and other people might be able to come up with something useful that wouldn't be possible with higher fees. Pay per share mining is one possible example, but I haven't every joined a pay per share pool so I don't know what they do when someone is due a very small payout.  I'm also thinking that if someone started trying to spam with >= 0.001 ltc then it would quickly add up to a useful amount of ltc.  Dust spam would still be prohibitively expensive though.

It isn't quite the same since we use nBaseFee other places, like in the small transaction case.  If it is too hard to change then it might not be worth it.


I like your concept of auto-scaling the definition of spam.  Much better than requiring periodic intervention.

I like the idea of charging higher fees for lots of small outputs, however, we risk capturing small-but-useful transactions in the mix.  I also want to have fee formulas we can keep instead of temporarily changing them and planning on changing them back.  Instead of two tiers we could have three with only the lowest tier getting charged per-output fees
large value = no fee
small value = .1 fee per transaction
very small value = .1 fee per output

Make "very small" be 10% of small and all these too small to be useful even when aggregated transactions are really expensive, but leaves open the possibility of small but potentially useful transactions (like paypershare mining)

If we are making the fees additive, we'd want to remove the "if (nMinFee < nBaseFee)" check so people can't escape the per txout fee by making the block larger.

We can also have a higher fee for large-sized transactions.
From:        int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;
To:          int64 nMinFee = (1 + (int64)nBytes /  500) * nBaseFee;

That would only have an effect on blocks larger than 27000 bytes (but we could make that smaller too).

This would be independent of any nMinFee scaling that was done based on difficulty.