 Show Posts
|
|
Pages: [1]
|
I don't think I get why the limit is at 2h either. Generating blocks is probabilistic and does sometimes take that long, but that's difference from the current time, not difference from the last block.
1h is needed to prevent a significant part of the network from dropping during DST adjustments. Yes, there are still some systems that don't have a stable internal clock set to GMT, and those are sensitive to local-time resets which are different from country to country, sometimes automated and sometimes not, often forgotten about, sometimes both automated and done by hand, sometimes done the wrong direction out of confusion, etc. The DST changeovers are an old network headache, but less and less important as systems standardize more on internal GMT clocks. It may be time to just drop that hour as having been a bad idea in the first place, but I'm pretty sure that's why at least one hour is there.
It's probably worth adding another 15m or so for people who just have their clocks set wrong. But that gets us 75 minutes, not 120. Why the extra 45?
This should only be issue for miners anyway. They need to accept new block in order to add new blocks after it. If non-miner rejects a block because it's too far in the future, they should accept it later anyway so there's not much harm done. Mining is pretty centralized by mining pools nowdays, so I'd expect there to be multiple paths with reasonably correct GMT clocks that connect most of the mining network. |
|
|
|
- take the last 1.5*N block interval values (the difference between the time stamps of adjacent blocks)
- store the interval values in a double linked list
- go through this list and remove the highest 0.25*N and the lowest 0.25*N interval values (including negative values) which will remove noise and correct time travel intervals (both the before and after intervals).
I think this is the most important point in this algorithm. Bad timestamps provide no information about the block-rate and should be ignored. This doesn’t solve the problem completely, but hopefully the difficulty is less wrong because we don’t make big changes based on bad data. Ideal solution would be a system where timestamps can be trusted. In general we should be more clear to divide the problem in two parts: estimating the current block-rate and calculating the difficulty adjustment based on estimated rate. Control part is not that difficult and simple proportional controller seems to be good enough for lot of cases. The difficulty comes from the fact that block timestamps that cannot be trusted are used as input — it’s garbage-in-garbage-out. I usually work with embedded systems and detecting broken sensors there is pretty straightforward. Here the problem is more difficult because the miners have incentive to lie about the timestamps. There is some outlier rejection in AcceptBlock() (timestamp has to be between median of last 11 blocks and 2h in the future) and it could be made stronger. I don’t understand why the limit is at 2h even for Bitcoin, never mind for the faster altcoins. Extra rejection and smoothing can be done by pre-prosessing the block timestamps before feeding the blocks to difficulty controller (like in Cor2's algorithm before), so that we can still accept blocks even though we don’t trust their timestamps enough to base the difficulty adjustment on them. |
|
|
|
|
bit365 told me he could make a partial payment by March 15th. Didn't receive anything.
|
|
|
|
|
It should be possible, after all proof-of-work is basically just about spam-protection so in principle any kind of captcha could do. Implementation is not easy though :) Some problems:
1. Block generation rate should be pretty constant and it would be hard to come up with human mining system that has adjustable difficulty. You would also need need to have miners available 24/7 to be able to use the system.
2. System should be decentralized: only shared state should be in the blockchain. How would one generate puzzles/captchas without central server?
Because of these problems I doubt you can have purely human mineable coin that is still useful as a coin. Hybrid coin with block generation done by POW/POS and human miners just generating extra coins could work (I think Huntercoin is pretty close to this). Pretty much only difference to faucets that give out premined coins (or Gridcoin, I guess) would be that the system would be decentralized.
|
|
|
|
Pretty much anything is simpler than KGW with silly analogies and magic numbers  These alternatives are easier to tune and debug and I bet they are at least as effective as KGW. Effectiveness of course depends on what we want to optimize for; if the hash power can suddenly change a lot and we are left with too fast or too slow block-rate, we need to react faster and use something like these. I guess this is not very likely scenario for Bitcoin, so slow response time is fine for it. I think PID-controller or EMA would be good options altcoins. |
|
|
|
Can't get the quotes to work correctly.. Anyway, about those addresses that have lot of CGB. Last time I withdrew CGB from Cryptsy it came from 5Ts4Qoybhx9nBDxD37YRptLi4HBNKD1Za8 . That address is top 2 in https://coinplorer.com/CGB/Addresses/0/Top |
|
|
|
0.35 We need more experimental coins like this one. |
|
|
|
If you receive investments back, please remember to update the etherpad at https://etherpad.mozilla.org/MZ3eG4apz2For me, it's now 3 months since I closed my 10 BTC investment and I haven't even received a reply to PMs or emails. |
|
|
|
I still don't think that he started the site with intention to scam. (Yes, I realize the people who get scammed usually rationalize just like this.. "I trusted the site and I'm too smart to get scammed, so it cannot possibly have been a scam."  ) The site was quite weak from technical point of view with slow payouts, timeouts with bets... Seemed like it required lot of manual work, but it seemed like he was trying to make it work. The investment feature was great and I think there was potential for "just-dice"-like growth with that feature. I did two investments on the site: 1 btc that was paid back in October and 10 btc that has been unpaid since early November. It's possible he just lost the btc in October/November somehow; there certainly were a lot of opportunities to lose btc during that time. Assuming he really lost the coins somewhere he should have just been honest and open about it, instead of coming up with nonsensical explanation of technical problems and continuing to pay random small investments and bets. Maybe he hoped someone would lose a big bet on the site. If he wants to continue the site without being accused of scamming and grow the site, he just needs to do normal "Chapter 11"-like deals about payment schedules and try negotiate to his debts down. After removing the link to the thread from the site and finally closing the thread here (just before major sport betting events) while not answering pm:s or emails, it does look like he has finally changed the sites business model to full scamming. |
|
|
|
Hey guys, I would like to give everyone an update. I cashed the following investment out on the November 25th: http://bitcoinsports.eu/inv/2078eand I have just received the coins a few hours ago, Hopefully this will give you guys a heads up on current progress. Nice to hear there's some progress. I'm still waiting 10 BTC from http://www.bitcoinsports.eu/inv/6bc71 that I closed month ago. So it looks like these aren't done in chronological order. |
|
|
|
Hi bit365, Posting here to remind that it's now 2 weeks since I closed http://www.bitcoinsports.eu/inv/6bc71 and it hasn't been processed yet. Please consider closing down site while you fix these issues. If you have an issue that is so serious that it takes over a week to fix, it's probably not a good idea to generate more backlog while you are still debugging. |
|
|
|
|
Posting here as Proof-of-Work (wasting bits) to be able to pm :p
|
|
|
|
|
