is it Schrödinger's cat? not dead, not alive, it's a zombie cat!

hi!
sorry I've been very busy this week

I'll take a look at jl777's supernetwork

cinnamon_carter, thanks for your thoughts. Just to clarify: when I started to work on RIC, I first was going to name it primecoin, but I saw that the domains and github were already taken, so I had to choose another name. Then, primecoin was announced before RIC. By the time xpm was announced I had a working prototype but I hadn't had announced yet. So probably primecoin started development before ric, and also finished first, however it was concurrent and independent work since nothing was known about xpm until it's release. In fact I remember freaking out when first reading xpm's pre-ann and then being relieved when the details were revealed because I saw it was a different idea. It looks like time to market played an important role, and the market was starting to saturate on ric's launch.
In case we went for RIC2, it shouldn't alienate RIC holders, they should understand ist's a step forward and should be able to move from RIC to RIC2 seamlessly.

I see dead pixels!

agreed that the odds of a reversal are calculated based on number intervals independently of the duration of those intervals. However my point is that since there are more opportunities if intervals are shorter, the odds of it actually happening in a given timeframe are higher (which is what matters to users: probability of problems in a given timeframe, not for a given number of intervals).

Ok, I'll take the opportunity to point everyone to Riecoin. riecoin.org - https://bitcointalk.org/index.php?topic=446703.0
It's unique technology is good: it solves the problems primecoin has with pooled mining and works on a more interesting math problem.
We have stratum pool server and minig code and are looking for more pools.

demonstrated? how?

I understand the Poisson process, but: if you want to double spend in a network that uses 6 confirmations, and it has 10 min intervals you must sustain your attack for an hour (in average). If it had 5 min intervals, then sustaining your attack for 30 minutes is enough. So the costs of your attack (if you rent hashrate per time) are halved.

Also, more blocks per hour mean more chances to attack per hour. Imagine that you achieve 25% hashrate. This is not the 51% required to be certain that your attack will succeed, however with 25% hashrate there is a probability that you can eventually find 6 blocks in a row before the network does and perform a double spend. Now let's say that 25% means that you need in average N blocks before you succeed (I'm too lazy to do the math but it should be around 5000 blocks). So if you can attack once every, let's say 5000 blocks, then you can successfully attack about once in a month at 10 minutes per block. But at 5 minutes per block, your ETA ("estimated time to attack") is halved to around 15 days.

so they're not "equally secure"

shorter time between blocks would mean we'd have to wait for more confirmations for the same level of security.
It does help with the 7tx/sec limit and gives more granularity in the level of security that you want, but if you had to wait 20 mins for 2 confs then you'd still have to wait 20 mins for 4 confs or you wouldn't have the same security

I think LTC proved that 2,5 mins can work, (async protocols like stratum helped with the problem of wasting power in old blocks) but I'd recommend against anything lower than that.

yes, please! I'd order it...

trusting people to be selfish is a safe bet, granted, but trusting them to be smart enough to realize how to maximize their selfish interest is not a safe bet.

no way. When you start dumping, price drops. So it's not linear, there isn't enough buy support to dump 1000btc. Even dumping 1btc will lower the price!

no, it did not

nope, thought about it, looked at moto's source code, but didn't have the time to actually do it


looking forward to it!
I might still do tetriscoin one day

congrats! looks like you made it work!
hope it lasts

thanks for the reply
I see... I'm starting to like it (except for the centralized server... is it open source?). What happens with orphans? if there are 2 competing blocks, will the server sign both? or (for a given height) the one that reaches the server first is the only one that gets checkpointed?

hi!
I didn't find much documentation, so let me see if I get this right.. you publish the "checkpoints" that decide the winners, making it a centralized lottery, don't you?

does the miner pay the winners? so a miner with bad luck could loose money? as a miner I wouldn't publish a block that doesn't give me a reward, so I'll assume that the money is just created in order to pay the winners. In that case, if I'm a miner I could create a dice transaction and publish the block only if I win, right? Of course, I would "throw away" lots of blocks and hashrate, but when I do find a winning block, I win 1024x what I "betted"? (not really betted because there was no way I could lose it since the bet was not broadcast until I knew it won)

hi!
I've been helping debug c.figgis' pool.


Thanks, we came to the same conclusion, 120 was too short, but we left it at 300, I think it would be enough and would put less stress on the server than 600.

I'm now debugging the windows miner.

regards!

I'll look into that. Are you willing to test debug versions of miner to help diagnose the problem? thanks!


I'm having only 2% to 3% rejects on nonce-pool, but my ch/s are much lower than yours, don't know if it has something to do.

please upgrade to 0.9.2. If you upgrade and let it run for a few minutes it should sync

hi! I've been away a couple of days. Still debugging the miner's windows issue: I'm almost sure it's a race condition. After that I'll try to check the android wallet with the api

using your own words:



sorry, couldn't resist the temptation... 
I agree with you this time: I don't believe it either...