Did I understand correctly: we need to recalculate the global variable "s" after each submitted share?
Suppose there is a large pool which handles a few TH/s (a hundreds shares per second). What if operator will recalculate 's' only on each 100th share? How it will affect miners? The calculations are lightning fast, updating s hundreds of times per second shouldn't be a problem. Well, doing it locally in your front end system and then storing it/updating it every so often. I wouldn't want to do hundreds of sql updates per second just to update the value of s. Update it on every share and store it every 100 (or some number) of shares in your database. If you have 100 shares/sec and store it every 500-1000 shares, then if the front end crashes/etc you only lose 5-10 seconds of data which may not be all that bad. Or do it every 100 shares. 1 sql query per second is no issue. Thanks, but you answered a different question =) I agree that 100-1000 multiplications per sec is not a problem. But I'd like to know if recalculating 's' on every i'th step is a reasonable optimization for large pools? Not really. I'm still not sure what is the motivation, "recalculating" s is more or less one multiplication, it's completely trivial. Storing it in the db might be more expensive, but aren't you storing each share in the db anyway? Shift-PPLNS and shift-DGM are more friendly for scalability. |
|
|
|
Issue resolved.
The problem was caused by BitcoinCharts API returning only 20,000 records instead of the full range (I don't know if this is documented or not).
I modified the app to save a daily snapshot of the peak price into a database, and take the max of bitcoincharts data and the previous day's peak.
Thanks again for reporting!
Was the exact peak 266.00 or did you just put that in there manually? I seem to recall it being something like 265.95 but I could be wrong. According to the data in bitcoincharts.com it was exactly 266. |
|
|
|
Close to 0%, but currently securing bitcoins is very hard and the system isn't very scalable. You need multisig and more sophisticated scripts to keep bitcoins secure, you need payment channels to allow trustless off-chain payments, etc.
And, yes, I currently enjoy very little utility from Bitcoin in its intended purpose. It will be more useful when it is more widespread, but that will happen only if it's scalable and easy to secure.
You don't need scripts to do multi-sig accounts. You can just define such account type. And defining account types in code is more powerful than scripts because you have access to current network state. You can example make accounts with withdraw limits per day. And please do not say anything about scripts flexibility because in reality every use case of script needs to be enabled by developers and accepted by miners. They could as well just write code handling new account type. Ok, I have a better idea now of what it is you are suggesting, you could hard-code the more commonly needed functionality. However, I will say that scripts are more flexible, and furthermore that we should move away from having to approve each script individually. |
|
|
|
Cryptocurrencies are almost useless without scripts.
Any specifics? How many percent of current bitcoin transactions are something OTHER than simple pay to address? Is bitcoin useless because of it? Close to 0%, but currently securing bitcoins is very hard and the system isn't very scalable. You need multisig and more sophisticated scripts to keep bitcoins secure, you need payment channels to allow trustless off-chain payments, etc. And, yes, I currently enjoy very little utility from Bitcoin in its intended purpose. It will be more useful when it is more widespread, but that will happen only if it's scalable and easy to secure. |
|
|
|
The paper says each bitcoin is 10M satoshis, the correct number is 100M. Let's consider some new awesome possibilities that arises when we get rid of bitcoin scripts and adopt account tree, so this thread won't die off.
Cryptocurrencies are almost useless without scripts. This idea will obviously need to make use of P2SH; the account addresses will be hashes of scripts rather than public keys, and the defining script will be given in the spending transaction. |
|
|
|
PayPal כנראה לא יעזור לך.
תנסה לקנות ביטקוין מאחד החלפנים בהעברה בנקאית ואותם אתה יכול להכניס לריפל דרך Bitstamp.
https://failover.bitcoin-central.net/זוהי אפשרות אמיתית? אני חושש שהם מרמים. הם זקוקים למספר חשבון הבנק שלי. זה לא ממש רלוונטי, זה דף זמני של אתר שכרגע למטה. לא הבנתי מה בדיוק אתה מנסה לעשות... לקנות ביטקוין? למכור? להכניס ביטקוין לריפל? מדוע החלטת כי מדובר בדף זמני? למה זה עשוי? אני רוצה לקנות Bitcoins הבורסה Bitcoin-Central סגורה כרגע עקב בעיות עם הבנקים. הדף הראשי שלהם הוא https://bitcoin-central.net/. הלינק שנתת הוא בסאבדומיין "failover" כלומר שזה נועד כגיבוי למקרה שאתר הראשי לא פועל. הוא לא עודכן עם ההתפתחויות האחרונות. בכל מקרה - איפה ראית שהם מבקשים את חשבון הבנק שלך בשביל לקנות ביטקוינים? אם אתה רוצה לקנות ביטקוין תסתכל ב - http://wiki.bitcoin.org.il/index.php/איך_קונים_ביטקוין. |
|
|
|
PayPal כנראה לא יעזור לך.
תנסה לקנות ביטקוין מאחד החלפנים בהעברה בנקאית ואותם אתה יכול להכניס לריפל דרך Bitstamp.
https://failover.bitcoin-central.net/זוהי אפשרות אמיתית? אני חושש שהם מרמים. הם זקוקים למספר חשבון הבנק שלי. זה לא ממש רלוונטי, זה דף זמני של אתר שכרגע למטה. לא הבנתי מה בדיוק אתה מנסה לעשות... לקנות ביטקוין? למכור? להכניס ביטקוין לריפל? |
|
|
|
|
PayPal כנראה לא יעזור לך.
תנסה לקנות ביטקוין מאחד החלפנים בהעברה בנקאית ואותם אתה יכול להכניס לריפל דרך Bitstamp.
|
|
|
|
According to the paper of satoshi, If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. The blocks are generated about every 10 minutes all the time. And it has only been 4 years since it launched in 2009, it should be 16.8 MB. Where did I go wrong? Satoshi was talking here about block headers stored in RAM and SPV clients. Not storing complete blocks on disk. Indeed, full nodes don't need to keep 10GB in RAM, and you can already use an SPV client such as Multibit. |
|
|
|
Yes. That's kind-of the point. There is no flexibility. All you can do is initiate the deposit of the coins to wallet X
You're confusing the end with the means. The goal is to keep your bitcoins secure. "Funds in a 2-of-2 address" is a better way to do it than "funds that can only be deposited to wallet X" - what these methods have in common is that they rely on two pieces of information that are both needed. What I meant by "flexible" is that with multisig you can have other ways to secure your coins, potentially better - e.g. 2-of-3. No. That's pretty much the *only* attack vector.
Ok, "additional attack vector", singular. The attack they have in common is stealing both pieces. Slightly incorrect. You can add more funds. You'll just never be able to get them out.
That's not adding funds, that's discarding them. By "wallet" I don't mean "address", I mean "someplace that you keep bitcoins". If you can't get them out they're not "kept" and thus not in a wallet. |
|
|
|
|
So basically, you have two pieces of information (the tx and the private key of the target address), and spending your coins requires having both. So this is in no way better than putting the coins in a 2-of-2 multisig address. But there are several ways it's worse:
- Less intuitive
- The deposit procedure is more convoluted
- Less flexible (there's no obvious way to extend to, say, 3-of-5 without involving multisig logic)
- Additional attack vectors - e.g., attacker steals just the target private key, and beats you to the tx that moves coins from it when you cash out
- Impossible to add more funds to the same wallet
|
|
|
|
Nevermind, stupid question. I sent 0.1 BTC to the address in your sig. Thanks for your help.
Transaction sent
ID:d2cef4ca0c0abb39480009413b33153203c2f58dee171f43f30b29c259410f92
Cool, thanks! |
|
|
|
Ok, ok. so to put the share difficulty and the block difficulty in the same range I will multiply the difficulty by 65536 and compare to difficulty 16 shares (in the same scale as reported by cgminer) as generated by the server.
So the formula would be 2 * (BlockDiff / ShareDiff) (Difficulty values are used as reported by cgminer)
the result would be 2 * (106,734.80 / 16) = 13,341.85
Round it up to 13,342 and use that for the lastNshares value. Is that correct ?
Sounds right. But again I'd prefer it if people used the accurate variant to prevent difficulty retarget hopping. |
|
|
|
It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0. The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine. Then maybe I am not understanding what "difficulty" in this example is. WDC difficulty is 1.62864385 (or it was when I made my OP). How do you correlate that to number of shares ? More likely I'm unfamiliar with the WDC terminology. In Bitcoin and Litecoin the average number of (difficulty-1) shares per block is equal to the difficulty. If in WDC it is difficulty*65536 then by all means you should multiply by 65536. It should be the same as litecoin. Most of the altcoins are clones of litecoin. But current litecoin difficulty is 602.33824219 which would make the lastNvalue 1,204. That can't be right though. You're right, I see now that Litecoin pools too use fractional difficulty shares ( https://github.com/litecoin-project/litecoin/wiki/Comparison-of-mining-pools). In all cases the average number of shares per block is (Difficulty / share difficulty) so your N will be X * (Difficulty / share difficulty). |
|
|
|
It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0. The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine. Then maybe I am not understanding what "difficulty" in this example is. WDC difficulty is 1.62864385 (or it was when I made my OP). How do you correlate that to number of shares ? More likely I'm unfamiliar with the WDC terminology. In Bitcoin and Litecoin the average number of (difficulty-1) shares per block is equal to the difficulty. If in WDC it is difficulty*65536 then by all means you should multiply by 65536. |
|
|
|
It needs to be based upon the block difficulty at the time.
Well, that's not the correct way either. Every share needs to be scored based on the difficulty at the time it is submitted, see https://bitcointalk.org/index.php?topic=39832.0. The fact that in scrypt the hashrate is lower is irrelevant. You'll want the window to be a few times larger than the time to find a block, 2 * difficulty should work fine. |
|
|
|
Ive been sticking with bitparking thru their problems.
Right now my mining has been pretty stable yet the 'reward' seems to have dropped thru the floor. Is this normal for this kind of reward system or do they have a flaw or what? Did the difficulty just jump an order of magnitude or what?
If you mean the payout per round, take into account that Bitparking's hash rate has almost doubled since yesterday. Indeed. If the pool's hashrate doubles, you have twice as many rounds with half the reward each. But if that's not the issue, I'd need more details to know what is. |
|
|
|
POS would mean keeping your coins in an unlocked wallet like by PPcoin and I wouldn't say that is a security improvement.
You can have separate private keys for voting and spending. |
|
|
|
|
Show Posts
