namecoind
For namecoind grab the latest version from vinceds repo and follow the instructions found in the doc directory for your platform or just use the latest version from dot-bit main page. The current implementation starts merged mining on block 19200 on production blockchain and on block 0 if you have configured testnet blockchain. http://dot-bit.org/Merged_Mining#namecoindAh, okay... Does that mean someone with a large proof of stake can now enable merge mining on the chain and then attack it using someone's BTC pool? So the chain is pretty much able to be held hostage by anyone with a large proof of stake? |
|
|
|
|
Namecoin has a different genesis block and chain and is still able to be merge mined with bitcoin.
|
|
|
|
Oh really? How would they 51% the stake blocks? Mine tons of PPC and hold them as stake? Wait, "Merged mining works like this, you have two totally separate block chains, they are not related in any way nor does either contain any data from the other. When you mine you generate hashes that may be the solution to the current block, this is very very improbable per hash, its like a lottery where everyone generates tickets until someone finds the winning one. Normally you make tickets and check them against the Bitcoin block chain to see if they are the solution. With merged mining you create a ticket and check it against both the Bitcoin block chain and the Namecoin block chain, Bitcoin and Namecoin know nothing about each other, they are two totally different lotteries with different winning numbers, you just sent a copy of your ticket to both. Since you are sending the same ticket to two lotteries you increase your chances of winning one or the other. No Bitcoin data goes into Namecoin no Namecoin data into Bitcoin they remain totally separate, you simply run both the Namecoin and Bitcoin clients on the same machine and submit hashes to both networks, if your hash is the solution to the Namecoin block you get Namecoins if you hash is the solution to the Bitcoin block you get Bitcoins, its exactly like if you where mining on just one network, except you submit the same work twice." I don't understand how the checkpoints prevent merge mining if you just submit the share against both chains...? |
|
|
|
Well, regardless of merge mining, the first person to get a couple of ASICs can 51% the entire currency.  |
|
|
|
PPC: util.h#include <openssl/sha.h>
template<typename T1>
inline uint256 Hash(const T1 pbegin, const T1 pend)
{
static unsigned char pblank[1];
uint256 hash1;
SHA256((pbegin == pend ? pblank : (unsigned char*)&pbegin[0]), (pend - pbegin) * sizeof(pbegin[0]), (unsigned char*)&hash1);
uint256 hash2;
SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
return hash2;
}
template<typename T1, typename T2>
inline uint256 Hash(const T1 p1begin, const T1 p1end,
const T2 p2begin, const T2 p2end)
{
static unsigned char pblank[1];
uint256 hash1;
SHA256_CTX ctx;
SHA256_Init(&ctx);
SHA256_Update(&ctx, (p1begin == p1end ? pblank : (unsigned char*)&p1begin[0]), (p1end - p1begin) * sizeof(p1begin[0]));
SHA256_Update(&ctx, (p2begin == p2end ? pblank : (unsigned char*)&p2begin[0]), (p2end - p2begin) * sizeof(p2begin[0]));
SHA256_Final((unsigned char*)&hash1, &ctx);
uint256 hash2;
SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
return hash2;
}
template<typename T1, typename T2, typename T3>
inline uint256 Hash(const T1 p1begin, const T1 p1end,
const T2 p2begin, const T2 p2end,
const T3 p3begin, const T3 p3end)
{
static unsigned char pblank[1];
uint256 hash1;
SHA256_CTX ctx;
SHA256_Init(&ctx);
SHA256_Update(&ctx, (p1begin == p1end ? pblank : (unsigned char*)&p1begin[0]), (p1end - p1begin) * sizeof(p1begin[0]));
SHA256_Update(&ctx, (p2begin == p2end ? pblank : (unsigned char*)&p2begin[0]), (p2end - p2begin) * sizeof(p2begin[0]));
SHA256_Update(&ctx, (p3begin == p3end ? pblank : (unsigned char*)&p3begin[0]), (p3end - p3begin) * sizeof(p3begin[0]));
SHA256_Final((unsigned char*)&hash1, &ctx);
uint256 hash2;
SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
return hash2;
} Bitcoin: util.h#include <openssl/sha.h>
template<typename T1>
inline uint256 Hash(const T1 pbegin, const T1 pend)
{
static unsigned char pblank[1];
uint256 hash1;
SHA256((pbegin == pend ? pblank : (unsigned char*)&pbegin[0]), (pend - pbegin) * sizeof(pbegin[0]), (unsigned char*)&hash1);
uint256 hash2;
SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
return hash2;
}
template<typename T1, typename T2>
inline uint256 Hash(const T1 p1begin, const T1 p1end,
const T2 p2begin, const T2 p2end)
{
static unsigned char pblank[1];
uint256 hash1;
SHA256_CTX ctx;
SHA256_Init(&ctx);
SHA256_Update(&ctx, (p1begin == p1end ? pblank : (unsigned char*)&p1begin[0]), (p1end - p1begin) * sizeof(p1begin[0]));
SHA256_Update(&ctx, (p2begin == p2end ? pblank : (unsigned char*)&p2begin[0]), (p2end - p2begin) * sizeof(p2begin[0]));
SHA256_Final((unsigned char*)&hash1, &ctx);
uint256 hash2;
SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
return hash2;
}
template<typename T1, typename T2, typename T3>
inline uint256 Hash(const T1 p1begin, const T1 p1end,
const T2 p2begin, const T2 p2end,
const T3 p3begin, const T3 p3end)
{
static unsigned char pblank[1];
uint256 hash1;
SHA256_CTX ctx;
SHA256_Init(&ctx);
SHA256_Update(&ctx, (p1begin == p1end ? pblank : (unsigned char*)&p1begin[0]), (p1end - p1begin) * sizeof(p1begin[0]));
SHA256_Update(&ctx, (p2begin == p2end ? pblank : (unsigned char*)&p2begin[0]), (p2end - p2begin) * sizeof(p2begin[0]));
SHA256_Update(&ctx, (p3begin == p3end ? pblank : (unsigned char*)&p3begin[0]), (p3end - p3begin) * sizeof(p3begin[0]));
SHA256_Final((unsigned char*)&hash1, &ctx);
uint256 hash2;
SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);
return hash2;
} PPC: script.cpp // Serialize and hash
CDataStream ss(SER_GETHASH, 0);
ss.reserve(10000);
ss << txTmp << nHashType;
return Hash(ss.begin(), ss.end()); Bitcoin: script.cpp ( old version) // Serialize and hash
CDataStream ss(SER_GETHASH, 0);
ss.reserve(10000);
ss << txTmp << nHashType;
return Hash(ss.begin(), ss.end()); Am I missing something here? It sure looks merge minable to me. |
|
|
|
|
I hope LTC price keeps going down so the difficulty does too, I want to mine as much as possible with my 2.5 mh/s before ASICs take over bitcoin.
|
|
|
|
|
they're all cpu, gpu, fpga, and asic mining algorithms?
sha256 is ~100-500x more efficient for asics as compared to gpus.
scrypt is estimated to be ~10x more efficient for asics as compared to gpus.
solidcoin2 algorithm (a derivative of BLAKE) is about 1:1 CPU:GPU in terms of performance, but as realsolid coded it it may be susceptible to attacks/refinements yet. as far as i know it didn't use any additional memory, so it's likely to be at least 100x more efficient with asics.
|
|
|
|
2. It was not necessary but as he told me when wanting to bail on the original SC it was chance to start over and do it his way. When you upgraded to the SC2 if you had your wallet.dat from the original SC in the SC2 directory then it converted those coins in that wallet to the new SC2 coins. One of the main ideas of the SC2 was the skimming off of the fees to trust nodes which RealSolid controlled plus massive pre-mine of coins in said trust nodes. This was supposed to be for the protection of the network, something I highly doubt as I already by that time knew what a scamming dishonest fucker he was.
Oh yeah, I forgot about the 12 million coin premine as well as the CPF ("Coinhunter Personal Fund"), where all the amounts from the blocks the trust nodes mined would go to Coinhunter/RealSolid too. RealSolid forgot to put it into his code that the coins from the CPF should all be signed from the same address and thus go to the same private key-pair, so there was an attack in SC2 where someone rerouted the CPF payments to their own wallet hilariously. All the drama and lulz are coming back now.  |
|
|
|
I know how it started, but not the rest of the story. And I don't have time to read all forum posts... So it would be great if somebody can provide a summary.
I'm willing to pay like 25 LTC for a summary (or equivalent about in BTC). Maybe more if it is necessary...
Particularly I want to know:
1. What happened to first version of SC, why did it die? 51% attack. It was merged mined with BTC so this was easy to do for any pool operator. This is the same reason why no exchange will add TRC, because the possibility of a 51% is outrageously high since the authors didn't bother to change the mining algorithm. 2. Why SC2 was necessary, what were the features (!), was there SC->SC2 upgrade process (I mean, keeping coins)? Addressed 51% attack by using trusted nodes to solve every other block and thus make it impossible to achieve 51% of the network hash rate without being a trust node. The trust nodes were mostly RealSolid/CoinHunter and his friends. A 5% tax on all transactions was added. Additionally a new hashing algorithm was implemented; interestingly, this algorithm hashed with AMD cards only slightly more quickly as with nVidia cards and CPUs. 3. What happened to SC2, why haven't it took off? 1. Nobody trusted the trust node system because of RealSolid's megalomania 2. RealSolid decided it would be neat if he were to manipulate the market by making blockreward nearly 0 for a long period of time (in order to "make the blockreward correspond to the amount of electricity costs used to produce it", whatever that means). Soon after the price of the currency tanked. 3. Taxes. 4. Why do they want to make MicroCash, what interesting features will it have?
Because the price of the chain died after RealSolid's Communist manipulation of the currency market. Nobody knows really. |
|
|
|
|
It looks like bASIQ ASICs for BTC are about to ship, so we may see the price or at least the difficulty of LTC explode very soon.
|
|
|
|
Order ID: 952 Date Ordered: 02/10/2012 Your order has been updated to the following status: Ready To Ship To view your order click on the link below: http://www.btcfpga.com/index.php?route=account/order/info&order_id=952The comments for your order are: Hello, we are excited to let you know that your order and payment has been processed. Your shipping invoice has been printed and will be ready to go when your bASIC has been assembled and released from test. Thank you for your business! The BTCFPGA Team Please reply to this email if you have any questions. So we can infer: 1. Final ASICs have been cut out from the wafer and will be tested. 2. PCBs will be assembled soon after. It looks like December will be the month of ASICs and BFL will fall flat on shipping before anyone else. |
|
|
|
|
All BFL has really done has been to shoot themselves in the foot by announcing their crazy non-existing ASICs so that the competition could pour in and beat them to it.
Imagine if BFL had simply found someone privately to fund the development and then carried it out quietly... BFL would be lightyears ahead of everyone else and reaping profit instead of what looks like a loss of 2/3s of the market share to BTCFPGA and Avalon.
People should be questioning BFL for this market strategy alone.
|
|
|
|
|
Also note ASICs haven't come out yet, which is the major driving force for ltc adoption
|
|
|
|
|
Well, that's the point of talking about it.
It brings up a very important point about litecoin's memory hardness, mainly that it seems to only partially protect the chain from ASIC mining. A true GPU only chain will probably need a hardware specific encryption algorithm that takes advantage of all of the design features on the AMD GPUS.
|
|
|
|
Am I interpreting this right?
Memory requirement based on time == growth of requirement without relation to network realities
memory requirement based on difficulty == Potential attack vector
Limiting the percentage of change over time/blocks just slows down the attack, but still requires other miners to acquire systems with more RAM to continue to compete once the full correction is felt. It does not solve the root issue, just blunts the volatility.
Well, not if the start quantity of RAM is low enough and the adjustments are small enough. For instance if the start quantity of RAM is 16 MB and adjustments are only 5-10% in 35 days, within a year we'll be at ~46 MB of RAM required per thread with 10% adjustments every 35 days. Thus an attack on the network to enhance RAM consumption to unsustainable levels would have be maintained for years to really influence the mining market and monopolize the coin. Limiting the adjustments within the 5-10% range for 35 days periods should allow the market to be self-determining. The important thing is starting with a flexible memory size and envisioning that with maximal scaling it will not proceed over a certain threshold for at least 4 years, say 512 MB/thread. The memory difficulty settings in terms of time would have to be approached with caution to prevent attacks; perhaps a maximum of 5% in the upwards direction and 20% in the downwards direction would be ideal (~4 years or 44 35 days periods, the maximum increase in memory usage would yield 137 MB). |
|
|
|
None. It will crash. The only worthwhile alternate coin is PPCoin. The rest are complete garbage.
ppcoin  |
|
|
|
$858,291
or ~1% of that of bitcoin
i think you are off by about a factor of 10. ? Bitcoin's is $114,396,700 |
|
|
|
|
Show Posts
