Bitcoin Forum
May 03, 2024, 04:50:31 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 171 »
1221  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: June 14, 2012, 12:36:45 PM
facebook page for recent updates and news? i hate facebook. i would rather get updates and news here pls

I'm planning to add some facebook widget instead of current news bar on the left side, so even people without a FB profile will see major news. I agree that it's necessary to see important updates directly on the website.

I picked FB, because almost everybody have or can have an account, and it is probably to easiest way for the people to give me the feedback. Many people also have problems writing here because of rules for newcomers. Generally I think FB is pretty good tool for building a community, but of course you don't need to register on FB to use the pool :-).
1222  Bitcoin / Development & Technical Discussion / Re: [Stratum] Overlay network protocol over Bitcoin on: June 11, 2012, 03:38:43 PM
I would like to know if you could pass a signed transaction onto another party (say, from the payer to the payee) too. This would be very useful for areas with limited data connectivity, as it would only require the receiver to 'upload' the transaction.

Yes, this is possible with signed transaction.

Quote
You could also have situations where both parties had no Internet access and such transactions could be treated like cheques, which could be cashed when the payee is next online.

But you need to be really careful here. The fact that transaction is signed doesn't mean that it is valid. If you cannot fully trust payind side, you shouldn't receive such transaction offline...
1223  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: June 11, 2012, 03:18:06 PM
Is anyone else having high reject rates after you get a longpoll?

What does "high" mean? Is you miner connected to LP port? What miner do you use? Please post me a PM.

Edit: I re-checked LP mechanism and everything seems fine. Also all my rigs connected on the pool have pretty low stale ratio (~0.15%).
1224  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: June 11, 2012, 01:52:48 AM
I needed some break from work on backends, so today I launched multilanguage support for website. Not all texts are currently translated, especially some emails, but I'll fix it during the time. Currently English, German, Russian and Czech translations are available. If you want pool site in your language and you want help me with it, let me know :-). I'm especially looking for some French or Spanish native speaker...

1: Can a date/time localization be added?

Yes, it's already on my list. However it will come after DGM.

Quote
2: In the statistics page, can an additional field be populated showing the number of shares submitted for past blocks?

Yes, this is part of DGM update which is planned in next days.
1225  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: June 05, 2012, 08:00:48 AM
has the pool been suffering alot of down time? my end seems ok

As far as I remember, there were two noticable downtimes in last week, both because database maintenance. First was around 30 minutes, second exactly 10 minutes (crunchyferrett :-P). I don't think those two outages can affect overall hashrate in some significant way.
1226  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: June 05, 2012, 07:58:59 AM
The hash rate shown on the account page has been consistently 20-25% below what my miner tells me it is, I never really gave it much thought. One or the other, or both, are wrong.

Well, that hashrate on the profile page is just an estimation; hashrate given by your miner will be much more exact. Actually as far as you don't see any connection issues in the miner, don't worry. Pool indicates accepted or rejected shares directly in getwork response, so all possible issues should be catched by your miner.
1227  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: June 01, 2012, 09:12:30 PM
My appologies for recent downtime, it was database maintenance (second and final part). Downtime was less than 10 minutes.
1228  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: May 28, 2012, 07:56:10 PM
OK, BTC payouts working again (I just sent batch of all pending payouts), I'm working on NMC now.

Edit: NMC payouts works as well.
1229  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: May 28, 2012, 07:39:59 AM
Payouts are still disabled, I came at home too late and it's always better to be fresh while handling with coins. I'm working on fix right now and payouts should be enabled very soon.
1230  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: May 28, 2012, 07:39:02 AM
splitt, invalid ratio is slightly under 1% in long term average. Yes, in recent days there were some extra invalids, but as you can trace on blockchain.info, it was really just bad luck, there isn't any obvious mistake. Pool is also directly connected to some well propagated nodes and also to few other pools to minimize latency.
1231  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: May 27, 2012, 06:50:52 AM
Writing from mobile connection; i was fixing one issue on the server, sorry for short outage. Connection from here was incredibly laggy. I also stopped payouts, they'll be back on the evening UTC.
1232  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: May 24, 2012, 09:41:03 PM
Ok, it's back up, downtime was 35 minutes.
1233  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: May 24, 2012, 08:29:08 PM
I'll start linux kernel & database update in following 30 minutes. Unfortunately I need to stop application, expected downtime will be 20-30 minutes.
1234  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: May 24, 2012, 07:00:09 AM
Would moving to PPLNS temporarily be a possibility? Or would you be changing one difficult to solve problem for another?

At this moment is simplier to finish DGM than do all coding and testing for PPLNS and then DGM again...
1235  Bitcoin / Pools / Re: Pool API Standard on: May 24, 2012, 06:13:43 AM
As Inaba said the number and order of fields in JSON is immaterial

To be exact, this is true only for keys of an array. Lists (and history of blocks should be definitely stored in list) are ordered. But I see your point. Actually I'm for defining JSON API as an standard, because it's usually easier to handle in applications, and provide alternate CSV API with block history only (from pool side it's just an iteration over original JSON and columns with expected order).
1236  Bitcoin / Pools / Re: [1094 GH/s] Slush's Pool (mining.bitcoin.cz); supporting p2sh! on: May 24, 2012, 05:55:14 AM
...so it can't be too much harder than PPLNS to implement here - especially when Slush has more experience than anyone at running a pool using exponential scoring).

The main difference between current score implementation is that score equation needs only time as an input, but proper implementation of DGM need to know also count of already submitted shares (across all backends). Pool core is designed quite scalable, there's no online synchronization between backends necessary, but it goes against DGM requirements. And it's the pain and the reason why it takes so much time. Originally I expect that it won't be so hard, but I felt into solving strange threading issues (cause framework which I'm currently using doesn't natively support user's threads).
1237  Bitcoin / Pools / Re: Pool API Standard on: May 23, 2012, 05:10:57 PM
Have you guys seen Luke's BIP?

Yes and I see it overcomplicated, especially that "collab" construction. Better to have more APIs than one huge monster, isn't it? I even think that current API should be split into more calls like account state (balances, address, etc) and worker states.
1238  Bitcoin / Pools / Re: Pool API Standard on: May 23, 2012, 05:08:13 PM
I did that specifically so you could add nmc_balance, nmc_unconfirmed, and nmc_paid.  Although I suppose we could make them a sub array of BTC: or NMC: (or whatever other currency) and then just use balance, unconfirmed, paid.

Having currency name in variable doesn't look smart. Then I prefer - separate calls completely (and have an api for every currency) or have separate section for every currency, like ...'balance': {'BTC': {'unconfirmed': 0, 'confirmed': 0, 'paid': 0}, 'NMC': {...}} ...
1239  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: May 23, 2012, 04:55:52 PM
The only (<market>.scid) files available are the ones I specified in the command line above. There are no other .scid files. You are saying other markets should be available to choose, I'm not sure what's wrong?

Are you using latest version, 0.5?

Edit: I see you're using 0.5. Then if you don't specify any market, feed will use "-s mtgoxUSD,*" by default. It means: Download mtgoxUSD history on startup, then start feed and store all other streams as well (and download market history on first update).

If you're using -s parameter without "*", it will stream only markets which you defined.
1240  Economy / Trading Discussion / Re: SierraChart bridge - Realtime Bitcoin charts [v0.5] (MtGox, Intersango, ...) on: May 23, 2012, 10:07:03 AM
Do I have to start a fresh terminal for each exchange I want to monitor?

No, feed is downloading *all* quotes by default,storing them in separate files (<market>.scid). Default behaviour is that markets are lazy-loaded,that means feed will dowload market history once there's some move. If you specify market in -s parameter, market history will be downloaded actively after startup...
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 171 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!