OpenID sign up says bad request.
Can you PM me the open id provider you are using? |
|
|
|
See my message here for details on the closing of the exchange: Recent events have shown that running an exchange is way to risky and stressful to me in the current alt coin climate. Prices have risen to a point where I'm not comfortable I can provide a reasonable level of service. To this end I'm closing the exchange and encourage all users to move to vircurex. The following details are on the exchange site: 2013-04-05: The Bitparking exchange is closing down. I've decided the risk involved in dealing with the current high prices for the alt coins has moved from the 'fun hobby' level the exchange originally started with and requires a more serious approach to operation. I've been in contact with the Vircurex exchange and I encourage all existing customers to move their funds and continue trading their.
The exchange will close trading Friday 5 April 2013 22:00 and new deposit addresses will not be able to be created. Trading operations will also be disabled. Withdrawals will be available for a few days after that at which point the exchange will close and all funds sent to their emergency withdrawal address. Withdrawal fees are removed during this period. Thanks for using the exchange and enjoy a better and more professional experience at Vircurex.
|
|
|
|
Anyone ?
Something like: litecoind listtransactions "" 1000|egrep -A3 'immature|generate' |
|
|
|
|
Pool is having issues with the bitcoin daemon hanging. I've restarted it again and will monitor it to try and find out the problem.
|
|
|
|
|
Pool down due to a daemon crash. Bringing it back up now.
|
|
|
|
put a sell order for namecoins on BitcoinParking, but I don't see it on the sell list
just trying to get my namecoins converted to BTC
Does your balance still show your namecoins? If so, your order didn't take into account the fees. Click the "Calculate" button and it'll tell you how much to take into account for that. If your balance has the order subtracted from it but it doesn't show in your list of orders then the trade went through immediately. |
|
|
|
Is it actually necessary to submit to aux chains first before submitting to main chain?
Shouldn't the submissions all be able to be done at once as distinct threads none having to wait for another?
The process of submitting to the aux chain involves a couple of RPC calls. One to the aux chain and one to the parent chain. This is repeated for all aux chains being mined. Then an RPC is done to the parent chain again to check if it solves the parent block. If the parent chain is done first then the call made as part of the aux chain check can become invalid (my understanding based on code inspection). |
|
|
|
|
There's also a cost in more possibility of orphans. Before submitting a result to the parent chain a number of requests are made to the auxiliary chains to see if they've been solved. The more auxiliary chains you have, the longer the delay before the parent chain is informed of the resulting hash. If the daemons for the auxiliary chains are overloaded then that delay can be even longer. If some other miner finds a result in that delay time you can be orphaned.
An attacker could work on giving a merge mining pool more orphans by overloading the auxiliary chains with transactions. Satoshidice caused overloading on the bitcoin chain. Imagine if each child chain a pool was merge mining was 'satoshidiced'. The load and delay would be magnified for each chain the pool was mining.
|
|
|
|
That was one of the ideas that I came up with previously. Upside is that it's quicker to release new checkpoints. Downside is that it could cause many different forks if people all have different checkpoints configured. At least with the current way, I know that if you are running 0.6.3c, you will be on the same chain as me.
I considered, and partially implemented, a similar idea with i0coin, dynamic checkpoints, where new checkpoints could be sent using the P2P protocol that are signed by the coin creator. Users could also use a command line argument to indicate who's checkpoints they trusted. In the end I came to the same conclusion as you though, more hash power, not more checkpoints, is a better answer. Maybe something like the checkpointing could be done for new coins as a safeguard though. Code is in my github repository for i0coin if interested. |
|
|
|
For some strange reason, the last two BTC transactions that I've received from withdrawing from the pool aren't getting any confirmations. I simultaneously made a withdrawal from MtGox and it has received 6 confirmations already. This was over an hour ago. Is this unusual?
I see two unconfirmed transactions. I'm looking into it now. And as I wrote that one got confirmed. Can you let me know if they still show unconfirmed for you? It looks like the bitcoin network is under a fair bit of load. My node as almost 2000 transactions in the memory pool. That might be why things are taking longer to confirm. |
|
|
|
For some strange reason, the last two BTC transactions that I've received from withdrawing from the pool aren't getting any confirmations. I simultaneously made a withdrawal from MtGox and it has received 6 confirmations already. This was over an hour ago. Is this unusual?
I see two unconfirmed transactions. I'm looking into it now. |
|
|
|
The new code will have all the recent Bitcoin fixes.
The code doesn't seem to have changed the switch on times for BIP 16 and BIP 30 in main.cpp. This can cause issues depending on whether the new client or the old client has majority computing power and whether it hits this code. You might want to change the dates to a future time such that it turns on when it's likely more people are running the new code. You can convert the date formats at a site like http://www.convert-unix-time.com. Or have you turned off the relevant code somewhere else? If so, disregard :-) |
|
|
|
|
There were a few periods of downtime today while I updated some components of the pool. The downtime was just stopping and starting the pool so should only have been a few seconds. There was a period of increased stales during that time lasting about 5 minutes while I fixed a misbehaving component. The changes reduce the cpu load of the pool enabling it to handle load better. I was previously using the namecoin merge mining proxy to handle the merge mining. This was written in Python and becoming a bottleneck so I rewrote it in a lower level language to get better performance.
|
|
|
|
Just asking
Other than testing different ideas, none really. They're somewhat useful to see what will happen to bitcoin down the track. For example, geistgeld is pushing the memory limits with its large blockchain. i0coin is also getting up there. i0coin also shows that the code to halve coin subsidies works since it hit that a while back. |
|
|
|
I never was a fan of merged mining. Yes security is the big reason why.
I call it inflation of cryptocurrencies. Freely produced as a byproduct of producing say bitcoins...
Merge mining seems like a great idea for non-currency blockchains to give them security. Unfortunately there aren't any. Namecoin comes closest but people still use it as a currency. For currency based blockchains it seems to make that currency pretty much worthless. Maybe a currency could be done that merge mines up to block X to seed the coins widely, then at X it switches off merge mining and uses a different proof of work (like litecoin) from then on. The 'goldrush' during the merge mining phase might be fun to watch. |
|
|
|
t's simply that the lack of discussion about Namecoin is worrying me.
Discussion on Namecoin development goes on in the namecoin forums. |
|
|
|
Can your pool handle bitforce singles and others asics joining in october?
I'm currently working on pool backend improvements to enable it to scale better in case there's a dramatic increase in load, so hopefully. I'm certainly working towards it. |
|
|
|
Which pool carried out that attack?
See this post and related thread. It's a contentious issue so rather than concentrating on the who, concentrate on the fact that it happened. Any large pool or miner can do it, so any new merge-mineable coin would need to be able to handle it. |
|
|
|
|
Show Posts
