Sure, eat this, 51% attackers. No one can perform a network overtake, because the actual network actually produces only 50% of the coins.
That would be 50% of the blocks, not 50% of the coins wouldn't it? The 1 difficulty even blocks are for less coins - they are the protection fund coins IIUC. |
|
|
|
not a programmer but i do understand higher math and the calculation that 30,000 cpus joined in the first two hours is conservative and impossible. multi forks is the reason
You must be using a definition of fork that I'm familiar with. BCX claimed to be mining a fork and followed with "Some of you are on my fork I suspect.". The only way they could be on that fork and not the main chain is if there was a break in the network somewhere. Peers share their blocks so the fork will become the main chain if it has a greater sum of work. For BCX to have a fork with a greater sum of work than the main chain he'd have to someone stop that from being distributed to the other peers. In which case the "Some of you are on my fork" can't be true. It's certainly possible for blocks to be solved faster even while difficulty is increasing. All it requires is hash rate to increase faster than difficulty. This is happening on namecoin at the moment as merged miners come on board, drastically increasing the hash rate while difficulty increases are capped at 4x. |
|
|
|
I think a time based difficulty change (every 24 hours), combined with blocks found / per hour, is a must have.
One lesson learnt from the original i0coin, time based difficulty changes are a disaster. Multiple nodes disagreeing on the time resulting in block chain forks. |
|
|
|
Is there a problem with Namecoin?
When I launched Namecoind today it started downloading blocks, but it stalled at 19,199.
Can anyone confirm this?
Are you running the latest software version, 0.3.24.63? If so, you might not be connected to other 0.3.24.63 nodes. Try doing an add node to one: namecoind -addnode=178.32.31.41 That node is run but the dot-bit.org maintainer. |
|
|
|
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. |
|
|
|
Why would this guy(s) use the same address again...
Do bankrobbers use the same car twice?
If they want to re-use those coins, short of rewriting the blockchain again, they'd have to pull them from that address. |
|
|
|
jLSn51oKE27uc9JJ74ccscyRdj3mnMTVAY appears to contain the coins that were used for double spending on the bitparking i0coin exchange. If you run an exchange and see a deposit coming from this address you know you're at risk from the double spender.
|
|
|
|
The large number of namecoins moving was the bitparking pool closing down and paying out the remaining balances. The total amount moved is inflated due to the block chain explorers counting the 'change' address multiple times. |
|
|
|
This is a known bug in bitcoind. Sometimes when we send funds, the original funds are too fragmented, and cannot be used to actually send anything. In that case it's often possible to send smaller amounts until the fragmented transactions are spent.
I got this a lot in my alternate block chain exchanges as well. It's very frustrating. |
|
|
|
Tried to compile it, but it does not run through, telling something about problems with the "net.cpp" according the miniupnpc.
Try compiling without upnp: make -f makefile.unix USE_UPNP= i0coind |
|
|
|
Eh. nvm me then - probably misunderstood a PM exchange (thought the Fairbrix w/auto-lockin code was gonna have a new name for some reason...)
There was generic discussion about approaches for exchanges to deal with low hash rates. I don't know if this means anyone is actually working on it beyond experimenting with ideas. |
|
|
|
Well your title and domain is all chains so you would think all the chains are there by that and I fail to see how a couple of rows extra are going to leave you cramped for space on the page, its your site but I would say leave them there for complete picture of the chains out there at the moment. And why no Fairbrix?
Each running daemon takes quite a bit of memory. The more chains the site supports the more memory it'd need. The bitcoin daemon on one of my sites is 1GB of memory. The namecoin daemon is 400MB. I can't imagine how cramped it must be on allchains.info fitting all those chains. |
|
|
|
Dropping ixc and sc from the stats page to make room for TBX and sc2 (lol). Please let me know if this is a problem for anyone. The hashrate on those are almost non existent.
I'll donate some BTC if you keep ixc until the end of the month when my exchange closes completely. It's useful to see the hashrate to diagnose issues with withdrawals not going through. |
|
|
|
Y not mine Geist Geld ? It's GPU friendly and has 15s blocks and Escrow transactions (and might soon get other funnehs)
Meanwhile, if you want to mine a CPU-friendly cryptocurrency while mining a GPU-friendly cryptocurrency you can mine Tenebrix
P.S.:
Full disclosure - both are currencies I am strongly associated with and allchains.info sez that NMC is by far the most lucrative GPU currency to mine.
Are you using the escrow code from multicoin? Isn't that broken? There was a discussion on the bitcoin-dev mailing list about issues with it IIRC. What testing have you done on it? |
|
|
|
How does system respond ?
My idea doesn't cover multiple exchanges. It would only work with one. More thought would be needed to extend it to other exchanges if needed. This is what I meant by centralizing around the exchange. So for the 'one true exchange' idea I'd see one order book managing deposits, withdraws and orders. This is the entity doing the checkpointing. Perhaps other 'exchanges' use an API to access the order book and provide functionality on top. |
|
|
|
I think that is a very bad idea. Why should I trust exchange operators? Because they are in business and hold coins? That doesn't qualify them to control an aspect of a crypto coin. Which exchange operators would we trust? What if the exchange got hacked and the key stolen? A thief would know who to target to get the key and exchanges are already juicy targets. What if an exchange is sold? Then the buyer(s) gets to do what they want with the chain?
Right, there are problems to resolve. But this is for the specific case of low hash rate chains. It's trust the central authority to provide lockins or have coins stolen by block chain rewriters. |
|
|
|
I am far from being a Real Programmer, but I have a sort of hunch that various "dynamic lockins" (be they timestamp-based or "magical transaction" based) could open a rather large can of net-scale DoS worms.
I don't see how an exchange sending out a signed transaction containing a checkpoint to nodes is any different from a coin creator regularly updating the client with a checkpoint and asking for clients to upgrade. The advantage with the former is it's automatic and nodes upgrade automatically. |
|
|
|
well, first the guy got the bitcoins and THEN revealed his longer chain that invalidated the older spends
so it doesn't help
Right, this is what happened. If you want to centralize around the exchange one thought I posted in another thread is have the exchange broadcast to the network the checkpoint for blocks when it confirms a deposit to the exchange database. Nodes then accept this message as a 'lockin' checkpoint. Expanding this to multiple exchanges might be wanted but in the 'one true exchange' case it'd work. |
|
|
|
Where did all my i0coins go from i0exchange.bitparking.com?
it's hard to answer this without more information. Are you saying your balance is lower than you thought? If so email admin@bitparking.com with details. |
|
|
|
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.
Right, I'm throwing out ideas for low hash rate chains moreso than 'fix i0coin'. I agree about a confederacy of exchanges/pools. Maybe have some way of all nodes voting to accept the message? Currently a low number of nodes with large hash power have a big impact on what gets accepted on the network. It'd be nice to be able to move this to all nodes somehow. |
|
|
|
|
Show Posts
