I did not change the "emergency broadcast" key, and only Gavin has the key. That was an oversight. I will change it for the next release.
I think most people would check the forums once they notice that mining has slowed down by a factor of 3. This is assuming 66% of mining power is on the new version. Maybe we could count the pool mining power that is represented on this thread and see what % it is?
I think we should aim to do the switch during a slow period, so that a 5x slowdown will be very obvious to the 1/3 that did not upgrade.
At this rate, block 19,500 seems feasible for the merged mining update to take place given how slow blocks are being mined. It may actually end up being October before we adjust the difficulty.
To be honest I'm very interested in getting merged mining to work ASAP. But on the other hand I'm asking myself if there is anybody out there who has a working configuration which is testable with RC2. I'm anxious that we are committing ourself to a block number only to find out there are a lot of bugs. ATM my alpha pool is the only possibility (I know about) to publicly test a merged mining pool and this pool is down ATM because I'm unable to run RC2 as it's segfaulting as soon as I try to start it in testnet mode. Furthermore there seem to be an issue with RC2 not connecting to peers in non-testnet mode.
I'd really like to get this issues sorted out before we discuss about an earlier release. At the moment I'd like to stick for block 24k. If we get a working configuration and a reasonable amount of people who confirm a RC is working we can start earlier.
nodemaster wrote:To be honest I'm very interested in getting merged mining to work ASAP. But on the other hand I'm asking myself if there is anybody out there who has a working configuration which is testable with RC2. I'm anxious that we are committing ourself to a block number only to find out there are a lot of bugs. ATM my alpha pool is the only possibility (I know about) to publicly test a merged mining pool and this pool is down ATM because I'm unable to run RC2 as it's segfaulting as soon as I try to start it in testnet mode. Furthermore there seem to be an issue with RC2 not connecting to peers in non-testnet mode.
I'd really like to get this issues sorted out before we discuss about an earlier release. At the moment I'd like to stick for block 24k. If we get a working configuration and a reasonable amount of people who confirm a RC is working we can start earlier.
I have RC3 up. It fixes the connectivity issue. That was caused by the API for GetDefaultPort() changing upstream without me noticing. This version also modifies the alert public key for future releases.
I couldn't find any segfault issues. You could try to run it under gdb and post a stack trace, and also clearing out the testnet directory.
vinced wrote:
I have RC3 up. It fixes the connectivity issue. That was caused by the API for GetDefaultPort() changing upstream without me noticing. This version also modifies the alert public key for future releases.
Yes thank you very much. https://alpha.masterpool.eu is now running RC3 in testnet mode. I'm testing with phoenix miner and cpuminer and had no problem so far.
vinced wrote:
I couldn't find any segfault issues. You could try to run it under gdb and post a stack trace, and also clearing out the testnet directory.
Is anybody else experiencing the segfault?
Stupid me Didn't even think about cleaning the directory. I removed everything besides wallet.dat and everything was fine.
Sorry for littering this thread, but there is a question that came to my mind. On Masterpool we are generating Testnet BTC fine. But Testnet NMC are rejected (I guess due to the fact that block 24k is hardcoded) Do we have a possibility to test if the namecoind if working properly above block 24k?
The only solution I can think of is to patch the source to a reasonable low block value, disable IRC in bitcoind.conf and team up with another person who has this version running and letting namecoind connect to only this namecoind. Right? Or are there much simpler alternatives?
nodemaster wrote:Sorry for littering this thread, but there is a question that came to my mind. On Masterpool we are generating Testnet BTC fine. But Testnet NMC are rejected (I guess due to the fact that block 24k is hardcoded) Do we have a possibility to test if the namecoind if working properly above block 24k?
Time to upgrade testnet! We should be able to get most testnet'ers to agree to a switchover testnet-blocknumber and client upgrade. See post
If you want to do some testing of merge mining I have setup 2 new chains to play with using MultiCoin-exp I have a low power chain with difficulty of .05 bitcoin.conf.mergmineTEST and the new high difficulty of 23509.0 with bitcoin.conf.beerA . For more details see bellow.
We now are at preliminary review of the new BeerTokens crypto currency spec that uses MultiCoin-exp as the client. The multicoin-exp config spec is presently published and will be updated from this site: http://exchange.beertokens.info/docs/mu ... conf.beerA . It is set to start at "difficulty" : 23509.0 , That is designed to be merge mined by other namecoin miners and or bitcoin miners. It is designed to pay .0001 BEER for each mined block up to block number 50,000 where it will pay .001 BEER. This is all we could possibly afford to pay for mining at the start. If we find we can't get miners to this payoff we might have to wait for licensed mining. For some details on how to setup MultiCoin-exp for merge mining of BeerTokens see https://bitcointalk.org/index.php?topic ... #msg394289 . If you have any problems setting it up please ask us direct at freenode chat #multicoin so that we know what we need to add to the documentation to make it work for more people. Note the spec is not finalized yet and it will be evolving over the next few days or weeks.
So luke-jr who runs the Eligius bitcoin pool claims that there is a security exploit in the merged mining code:
17:02 < luke-jr> bliket_: will you still like me if I exploit the security hole in merged mining? <.<
...
17:06 < doublec> luke-jr: have you notified vinced of what you think the security issue is?
17:07 < luke-jr> doublec: no, I prefer to exploit it
He's also mentioned it on IRC in the past. Vince, has he got in touch with you about this or is he trolling?