Call me a noob, but running this simply didn't do anything. No error message or nothing. Should I put the config file somewhere specific? %APPDATA%\Multicoin ?
No... it needs to be started from the command line to work as namecoin. What I have is a structure like multicoin.exe/ /data/namecoin/bitcoin.conf <--this is the config file I liked to above renamed. then you launch it >multicoind -datadir=data/namecoin/bitcoin.conf you could set up bat files to do it. It is not really meant as an end user tool, but for people that want to mess with different block chains. As I wrote https://bitcointalk.org/index.php?topic=24209.msg459926#msg459926 when I first was learning it, it is not really an end user client, though I have some ideas for code changes that could make it more so. I really need more hours in a day lately! Are you familiar with the cli/bat files? if so you should be able to get it going set up like above, if not, it probably is not yet the tool for you. |
|
|
|
Thanks. I don't know twobits myself, can some recognized/trusted forum members vouch for him?
(Nothing personal, just trying to get a little trust that what I'll be downloading isn't a trojan)
I vouch. He's provided namecoin binaries for a while that work well. Thanks. Let's say I trust you guys enough to try this (although more assurances are always nice, since I'm not sure I've seen doublec as well, as don't feel like going over his post history right now). twobits - can you provide an updated build? All right, though multicoin is a bit of a pain to set up for the most people that are the ones that want a gui. You need to grab the config file, and rename it bitcoin.conf and have that in the datadir , may want to make a bat file and use -datadir= to do it. http://www.wuala.com/jbw9/pub/Bitcoin/multicoin/MultiCoin-exp/src/multicoin.exe/and http://www.wuala.com/jbw9/pub/Bitcoin/multicoin/MultiCoin-exp/doc/bitcoin.conf.namecoin/ |
|
|
|
So what do i need to do to get merged mining working if i am at this pool?
do i use namecoind or can i use my bitcoin miner?
For mining at a pool you would use your bitcoin miner. |
|
|
|
I have been doing windows builds of multicoin-exp, but have not heard of anyone using them so don't keep it up to date unless I get a request usually. http://www.wuala.com/jbw9/pub/Bitcoin/multicoin/MultiCoin-exp/src/bitcoin.exe/ is actually mutlicoin, however I am pretty sure this version only works with the config file that would have been compatible with .62 and needs to be updated for .63 now that we have passed block 19200. I can update it if anyone wants it to be. |
|
|
|
Each fork takes ~184 to 240 meg of ram on the server. If nobody is using it, and there are no pools, and no exchanges... I don't really consider it a fork anymore... I see your point though. I will look into hosting the clients on other machines and sending in remote updates to get back to "all chains" if others share your opinion. Right now i think I should optimize resources to what people use most.
Thanks for the input.
You could probably reduce memory usage a bit by using a dynamically linked version of multicoin for those chain it can support. You probably could also reduce memory usage a decent amount by changing bdb flags at the expensive of speed, which for this use would not matter too much. |
|
|
|
Merged mining is only a few blocks away now and from what I can see the bitcoin side of the equation is grossly underprepared. I hope I'm wrong but I don't think this is going to go well. The problem as I see it is that the merged mining community has prepared itself but not given the bitcoin community the tools it needs to adapt. Let me explain.
The thing is, it is not like it has come out of the blue, it has taken many months to get here. People had been complaining about how long it has taken to get here. The bitcoin community does not need to be prepared. They can just continue to ignore it if they want to. Documentation is woefully lacking. Basically limited to a wiki page a some scattered discussion threads on the namecoin forum. Miners don't need to do anything but bitcoin pools that wish to adopt merged mining need to implement the spec one way or another. Currently the only way to do this is to use vinced's patched bitcoind and namecoind along with the python merged-mining-proxy. This proxy has to sit between the poolserver (e.g. pushpool, poolserverj or custom) and the bitcoind. This represents both a potential bottleneck and an extra point of failure and to my knowledge has never been tested on a load greater than about 50GH. The alternative is for pools to implement the merged mining spec themselves. This is easier said than done. The spec is NOT documented anywhere.
Yep, lack of a single place to find most information and much of anything to read that is not code is a real pain. Vinced's patched *coind stuff is not the only way to do this. sacarlson's multicoin-exp has supported merged mining since June now, and he used to post hoping to get others helping to learn and test things out with it. He has even set up a number of test chains for merged mining. Almost no one joined in. People have chosen mostly to ignore mm. I do agree the documentation should be a lot better. It is very fragile it seems, and you do need to read code to tweek it at all. The thing is though it is an OSS project, and they need to do things to get people involved as they are always short man power. I am tearing my hair out trying to figure out why merged mining works with these two chains, but fails when I add this third chain, but not another third chain etc.. I really wish it was easier to set up. It is not going to get to be so though with the current man power on it. Status: Ready for testing. Implemented using python.
Ready for testing.. but then how many actually have help them with the testing? So the bottom line is that every pool that wants to adopt merged mining currently has no choice but the use the untested merged-mining-proxy black box. So the MM spec is not documented and frankly I think it's grossly irresponsible of the people pushing MM to have let it get this far without doing so well in advance of the cutover block. Without hours/days of poring over the code (in 2 different languages) it's essentially a black box. The provided solution creates a number of problems and the sensible thing to do would be for pools to simply refuse to touch it until that situation is addressed.
Unfortunately merged mining has created a situation where adopting the change is very difficult to resist. Once one pool adopts it, it puts enormous pressure on the others to follow as the miners will flock to the pool that offers free extra Xcoins for the same mining effort. End result is we have a mass of pools struggling to cope with new xcoind patches and an unproven python point of potential failure/bottleneck and no one available to support it except the merged mining developers who seem to be online for about 10 mins/week.
Yep, that's it... once it is active, people will take an interest finally, and help developed the needed infrastructure if they want it. Since pools will probably need it to stay competitive they will probably be a major source of the manpower or bounties to finally get what is needed done after all these months. If there are problems and 1/2 pools roll back it still doesn't create any incentive for the MM crowd to step up and do the job properly because their motive is increase hash power on the NMC network and they will have acheived that whatever the consequences to bitcoin mining might be...
IMHO merged mining should be stopped until this situation is properly addressed.
Thing is, we have already had months to work on things, and no one has till it is almost here. I don't see a delay changing that. People need real coins to mm or they won't , as the lack of interest in the multicoin-exp test chains shows. |
|
|
|
I actually think BAT files are for DOS.
I thought I recall that picture being of a TI-99/4A. That Cosbycoin screenshot displays an impressive number of colors - I thought the TI-99/4A had a maximum of 16 (either total, or onscreen at a time from a larger palette).
yeah, DOS, OS/2 and Windows all have them though. They are definitely still around in windows 7 even. Think cmd is preferred now though. |
|
|
|
I donwloaded the source and I assume I use the batch file to start it ?
Eh? bat files are for windows, if you downloaded the source you need to use the makefile usually, and compile it first. You may want the .7z file instead? One doesnt just compile cosbycoin in mordor  I think those are ring coins..... |
|
|
|
I donwloaded the source and I assume I use the batch file to start it ?
Eh? bat files are for windows, if you downloaded the source you need to use the makefile usually, and compile it first. You may want the .7z file instead? |
|
|
|
1. Small blockchain - bitcoin out
2. 5,000,000+ pre-mined coins - Tenebrix and geistgeld out
3. Already crashed - fairbrix out
4. Horrible Difficulty algorithm - namecoin out
Seem the only one left is ixcoin until solidcoin comes out and replaces them all!
We need a new exchange.
ixcoin is not viable right now, they need to fix the time warp bug at least. I also think they need to revert the asymetric difficulty changes. |
|
|
|
What are thoughts on this possible fix for the issues of having an exchange safely operate in a low hash rate system. Centralize the block chain around the exchange.
The exchange can broadcast a message, signed by a private key, that contains the latest checkpoint that the exchange wants to lock in. It broadcasts this message whenever it confirms a deposit (ie. a deposit reaches the number of confirmation blocks the exchange requires). Nodes then automatically get updated with the block chain the exchange is using and refuse reorganizations beyond this check point.
My initial thoughts: It should be a new blockchain if it is tried out. It would be preferable to somehow have it be a confederacy of exchanges and/or maybe pools so it is not totally dependent on one site. |
|
|
|
I'll get right on it. However, regarding passwords, I feel an OpenID system is better than storing usernames/passwords on the exchange itself. This way, people can log in with their (for example) gmail accounts, without storing any credentials on the server.
I agree, at least the choice of an openid login should be an option. |
|
|
|
I'm sure I'm still on the chain I had before I shut down, now with 3 peers. If there was a fork it was before 1720.
think they said block 57 |
|
|
|
|
Ah, someone just said on irc that is looks like someone also forked the original fairbrix chain, that may explain what we are seeing... they fixed that issue then forked it.
|
|
|
|
Would be interesting ... but not enough Yes it would & yes, not enough! When I re-downloaded the chain, all the zero blocks up to 1720 were validated by my client with "custom_inflation" removed, then my generated's from 1720 up to 1886 were confirmed, plus the immature ones waiting for the block count to increase. Does this mean that, if people had just made that config change everything would have continued as planned? Ironic that the relaunched chain suffered the bigger fork! As ArtForz pointed out in anther thread, it doesn't take much of a botnet to eat a cpu mined chain. While I was typing this, the count has gone up to 2070, and my balance has increased accordingly. The clients should all have to agree on how many coins are in a block to validate them. This is what prevents someone from mining 5000 coins a block for themselves. Either the validation code in fairbrix is bugged or zero coins is treated differently. It should not be working like you are seeing, but since it is doing that either due to a bug or a some special logic it should have worked then. Now what happens if you mine 250 coins a block? That would see if the bug is only for zero coins. |
|
|
|
It got to 1886 (four were mine!), and sat there for ages. Then ticked over to 1887. So I guess there's still someone mining.
and before you said you were at over 2000? Would be interesting to see just what the blockchain looks like now.. but not not enough so for me to want to try and set up abe for the chain. I think with the issues with the relaunch I am sticking with tenebrix for cpu mining for now. |
|
|
|
Connected to 2 peers, downloading chain. 4 blocks have gone to "generate".
Can't know, of course, whether these 2 peers made the "remove custom_inflation" change or not.
Yeah, getting to be too many variables with fairbrix already. How many blocks of the chain did you download? |
|
|
|
Maybe there was a block chain split and most of us were on the wrong side of it?
Yeah, probably someone with a lot of cpu power was disconnected from the rest of the network and reconnected with their block chain or something similar. Wonder if it was on purpose or not. |
|
|
|
|
Show Posts
