yes, on the terracoin client, export the WIF address so you can later import it on your btc client and get the bitcoins.

on the terracoin client :

then on your btc client :

how would you achieve that in a "trusted", fair way ?

found an error :

from http://www.devtome.com/doku.php?id=a_massive_investigation_of_instamines_and_fastmines_for_the_top_alt_coins#terracoin :


Terracoin (TRC) is not scrypt.

donations only.

you did not read a single line in the above answer (from gweedo) to your question.


we're speaking of btc p2p messages here, nothing to do with rpc commands ; p2p network should still work whatever the 'coin' use to create new blocks.

other nodes requesting ... data. ..


are you seing pow blocks ?
if you know anything about pow/pos they are easy to identify.
If you don't, have a look at sourcecode to see what rules a pos block must follow to be valid

I don't know what fork we're speaking here, but i think it should clearly state (in its sourcecode) that pow blocks are invalid past a given block height / timestamp / whatever, if it's a pos only fork.
AcceptBlock() and/or CheckBlock() should refuse pow blocks past the switch point.

some of you probably already noticed, this p2pool node was updated during the night with the latest changes pushed by terracoin.

Let's hope this is the last update before it gets into p2pool main repos! i'll keep an eye on it and watch pool stats.

bitcoin provides no privacy/anonymity at all.

I wouldn't trust another kiddie-forked btc clone for providing it either though.

If you're concerned about anonymity/privacy, you already use a few well-known tools to provide some more layers, some of them being fully supported by btc (or the other way around, according to the tool)

so .. my answer to
is also "YES"

i guess you could rely on another established blockchain as a datasource :

we could imagine that:

1.  your wallet/client would regularly query some bitcoin nodes (randomly choosen in included hardcoded list of dozens/hundreds of existing btc nodes), waiting for a given block height to be mined by the BTC network (with X confirmations),

2. explicitely (original code from your wallet sourcecode, since it was first released) use some properties of that future btc block (let's say nNonce & nTime) as your own genesis block properties ; also explicitely for N btc confirmations for that block, to prevent accidental use of a temporary btc forked chain.

This way, everyone should use the exact same genesis data. One would have to mine it thought, this could imply some major modifications to the client, so it allows genesis block generation (meaning full startup with no block loaded, and so on)

This would require some basic extra connectivity (btc p2p) to query other btc nodes, but yeah .. that could be "fun" somehow
Again .. you'll soon have to release another version of your client, hardcoding choosen genesis block data.

This looks extremely dangerous thought .. if you really release your client long enough before genesis block gets choosen/created, malicious users would have enough time to fake the whole thing, mining their own chain at low diff, later making that blockchain the longest one .. with no hardcoded genesis block, many nasty things could be possible then

Again, this would negate your own user's confidence in your coin, right from the start i guess

there's probably a clever way to do that, so it does not rely on a network message from you to decrypt the genesis block data on a given time / event / whatever, but .. can't find one right now.

But again, hitting the users trust limit is not that far, i guess

i think i understand what you mean : you want to be able to widely distribute a client sourcecode and/or binaries, without granting anyone the ability to mine on that blockchain until _you_ decide it's ready ?

I guess you could then make that client "wait" for some signed message from you, including the genesis data.
(the client would include your public key so it can verify your signature).

But then ... another "problem" appears : what would eventually prevent you from later messing around with the genesis block, eventually changing it, invalidating it or whatever ?

A solution to this could be another client release, hardcoding the previously broadcasted genesis data, but then .... you'll force your users to download your client again, making the whole thing useless

early BTC users joined the bitcoin utopia because they could trust the client for behaving exactly as stated in its sourcecode ; includign above magic into a new client would .. go against that

first thing : understand bitcoin, what it is and how it works (meaning : read and understand at least 80% of the core core - skip script details til you are more familiar with them).

then ... well ... if you understood what you read, you don't need a 'fork bitcoin for dummies' guide anymore

starting with something as "big" as bitcoin in terms of understandings it requires may be a bit overwhelming, anyway, here are a few things:

i just had a look at your 'create an altcoin howto' page, i don't really like the way they 'explain' how to create the genesis block.

Personally, i generate mine using the following procedure :

this is, supposing you already understood and set the network parameters.

1. choose the proofofworklimit i want for my network (>> 24 for tests for example) chainparams.cpp : bnProofOfWorkLimit per network

2. set those accordiningly:
genesis.nTime = something close to current time, just for information purpose
genesis.nBits = accordiningly to your bnProofOfWorkLimit
genesis.nNonce = 0; // start with zero onfirst run (or whatever)

eventually properly set the coinbase output (you'll have to know how to generate public keys)

3. right before assertion on hash & merkle, add something like this:

4. build and run for the first time. this will take some time, according to your proofofwork limit & nbits (you're actually 'mining' the genesis block right now), then have a look at the logs _you_ generated ; copy genesis block data (ntime, nNonce, merkle & hash) to your sourcecode.

5. disable code added in step 3, rebuild, voila ....

This way, you really have valid data starting with your genesis block. Many altcoins have genesis blocks that already violates their own rules ...

Note that you'll have to log your genesis block data by yourself, as no logging is initialized at that point.




Last thing (yeah, i know this gets boring, but it's the only way you'll end up _really_ learning anything) : try things, LOG things, do not ask for copy/paste answers as soon as a problem comes in, logging is the key, when facing serious problems that you couldn't solve by intense logging/debugging i bet you'll get quite some serious answers to .. your serious questions

i second this ... every day you get that kind of request ...

if you just can't figure out how to generate the fcking genesis block ... for god's sake .. wipe out your repository right now !

again ... if you couldn't find that out by yourself, please ... stop trying and do not release another fork !

Just in case someone would ask something like this (see below), here is what i would answer, hopefully helping other people :

But ... again ... if you can't find this out ... building, maintaining and releasing another fork just may not be a thing for you to do !



so .. here's what i'd answer :

just .... log it damnit

find the line that outputs this log entry and ... just log the stake modifier checksum!


If you can't find that out either (ooooo ... this coin's gonna be SOMETHING) :

kernel.cpp is the answer
hardcoded list of stake modifiers checksum there

as FlyForFun said, there's no need to run your client 24/7 unless you have coins ready for stake minting.

check your ppc fork PoS rules (STAKE_MIN_AGE and STAKE_MAX_AGE) :

If none of your coins are older than STAKE_MIN_AGE then you have nothing to mint.
If some of your coins are older than STAKE_MAX_AGE then they are ready for full pos minting.

To get "ready for minting", your coins must not move for STAKE_MIN_AGE seconds (30 days for PPC).

Hold them for a month (or 3 months for full pos minting) then keep your client running until you find a pos block.

If you want the client to automatically keep a given amount of coins ready for minting, while still using the currency, have a look at the 'reservebalance' option (RPC / cli)

If these are peercoin forks, then the answer is YES :

the BitcoinMiner() method takes an extra argument, when compared to the original btc implementation : bool fProofOfStake which is set to true when the proof-of-stake mining thread is spawned, on wallet startup.

when this fProofOfStake is true, the BitcoinMiner thread will :

 - check wallet isnt locked (if it is, display a warning and wait 1 second before re-checking)
 - check we are connected to some peers, if not wait 1 second and retry
 - create a new block following the PoS rules
 - then cycle this : increment the extranonce (bignum in coinbase input script), test it to see if we just found a valid PoS block. then wait 500ms before retrying

In a few words : this is a shorter/simple version of BitcoinMiner, with 2 extranonce tests per second, plus the PoS rules checks.

So yes, that BitcoinMiner(pwallet, true) has to be running for you to actually create a PoS block.

Because of the 500ms delay involved, it can take quite some time before you mint a pos block.
that delay allows the client to be running in the background with a barely noticeable cpu usage impact / energy consumption, while still constantly hashing block headers, looking for a valid PoS block.

Running multiple copies of the same wallet may help a bit, by increasing your "chances" of finding a PoS block (you'll hash twice as much pos blocks per second with two clients running on the same wallet). Because of the different ReserveKey(s) then used, block header should differ, actually increasing the chances you have to mint a valid PoS block.
Reducing that 500ms sleep delay could also help, but then the cpu usage impact would grow significantly, going against ppc original low energy consumption goal.

feel free to upgrade your terracoin p2pool node

i updated mine a few days ago, using instructions from http://terracoin.org/2014/06/06/new_p2pool_settings_released.html but i feel quite alone there at the moment

from the miner point of view, those new parameters looks slightly better though, especially once the total pool hashrate stabilized
At least miners have some more time to work between job restart requests

when they announced they were delisting TRC (end november/december 2013) the trc price achieved its all time record, reaching USD 1.3 per TRC (BTC was traded at 1 kUSD at that time) and volumes went crazy, so were btc-e profits then i guess.

As someone said above, keeping it live should not cost them that much, 2 to 8 BTC volume per day still grants them some daily incomes ; time will tell, but TRC is still quite young - 1.5 to 2 years i think