Bitcoin Forum
May 03, 2024, 04:40:41 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 ... 171 »
1901  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 11:10:34 PM
So if my physical location is London which is the best URL or IP to be using ( api or api2 or something else ) ? It seems ATM I am not supposed to use an IP or mining.bitcoin.cz right ?

It does not matter, both (api and api2) will point to France since tomorrow. But mining.bitcoin.cz won't be working since tomorrow anymore, I just setup routing thru webserver, which is dirty hack which is only giving time to users to fix their settings.

Btw latency between both servers is under 4ms, so if you're in London, the migration should not affect you at all - connection to France is excellent.
1902  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 11:07:29 PM
Current migration status:

* Website is working in France very well
* There wasn't any issue on mining (if you're using correct URLs)
* The rest (database server, mining backends) are prepared for migration, I'll continue tomorrow.
1903  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 11:01:44 PM
I notice the number is dropping, as people give up.

Um, no. I cut off ~100GHash by moving webserver (mining.bitcoin.cz) from London to France, then I realized a lot of people has been mining on this URL and setup HTTP proxy here, so this hashrate is back. Unfortunately miners using URL mining.bitcoin.cz  are routed thru France server, so their mining experience may be a little... crappy.

Except this issue there wasn't any downtime on pool today, so those two long rounds are just really bad luck. There's no reason to think that anything is wrong, I'm keeping my eyes on pool all day.
1904  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 08:08:42 PM
Yes, I see that problem.

TO ALL MINERS: Don't USE http://mining.bitcoin.cz for your miners! Don't use IPs for your miners! Use just and only api.bitcoin.cz or api2.bitcoin.cz!

As a temporary solution I setup permanent redirect on port 8332 here, however some miners can have problems with following redirects. And also mining against website does not have any sense ;-).
1905  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 08:03:39 PM
what's your IP in miners? Isn't that mining.bitcoin.cz (instead of api.bitcoin.cz or api2.bitcoin.cz)? I redirected website (mining.bitcoin.cz) to new server roughly before half an hour, which can explain your troubles.
1906  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 07:39:25 PM
Restarted all my miners, everything was fine, untill the last LongPoll

Now I get the 'Pool 0 not providing work fast enough'  messages again....

...which makes no sense for me. Actually LonPoll is *providing* job for miner, there's no need to ask server after LP broadcast.
1907  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 05:34:29 PM
Hm, strange. Everything looks ok here, all your requests are responded in less than 5 miliseconds and I also don't see any rejected shares or so, which usually indicate some troubles.
1908  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 05:27:34 PM
What's your pool username? (I don't see submits from DutchBrat in last moments) I'll follow it on my side.
1909  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 05:14:15 PM
Pinging api.bitcoin.cz [178.79.183.97] with 32 bytes of data:

Looking good to me

Yes, it's fine. How often do you see that error? How long it is since last message?
1910  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 05:08:31 PM
Is this because of the switch to a French provider ?

Not yet.

It's cgminer, right? Whats your ping to api.bitcoin.cz?

Edit: I'm monitoring pool response times once they took longer than 2 seconds; it happen time to time and it's an idicator that something is broken. But now there's no problem with response times, they're far under this threshold (actually most loaded pool backend has server load 0.15, which is excellent), so I don't see any reason why you should see this error.

Edit2: Also is there any ping packetloss?
1911  Bitcoin / Pools / Re: are there speed-differences between Pools? on: October 29, 2011, 04:28:25 PM
Meni, you're right. Usually I'm adding my favourite "long term" clause into sentences, however I forgot to do it now :-).
1912  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 03:44:23 PM
It's one exponent function per share PER USER. if you have 200 users you are doing this calculation 200 times for each share? then adding the new score to the cumulative score for each user and storing that in memory? for all the millions of shares?

As you already realized, score is calculated only for one share submit, not for submit*users :-).
1913  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 03:42:37 PM
It is great mining for NMC in Slush's Pool but my luck is real bad on BTC for quite sometime.   

Is your expected round reward significantly lower than it should be? For eliminate effect of score based system, you can take last 50 round rewards and recalculate it with proportional method (your hashrate against pool hashrate, which is pretty constant around 1170 for last few days).

If this fits, then it's pool luck (well, we performed pretty bad last few days). If it don't fit, then we need to investigate more. Usually it's because of some connection troubles, rejected shares or crippled miner software or cards. Actually I don't have a reason to think there's some flaw in pool code, I didn't touch important stuff for many weeks and merged mining cannot affect this.
1914  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 03:23:00 PM
score = score + exp(round_time/C)

This is done for every submitted share immediately.

Quote
reward = user score / total score * 50

This is done on the end of round.

Quote
Is it really done for EVERY submitted share for EVERY user?

Yes, why not? It's one exponent function per share. With current multigigahertz machines it really isn't an issue :-).
1915  Bitcoin / Project Development / [idea] Escrow service / cold storage, building trust for merchants and services on: October 29, 2011, 02:45:14 PM
I've been thinking a lot how to help building real Bitcoin economic. There are many shops and other services built on Bitcoin ("bitcoin shop" on google is giving me 13 milions results!), but I cannot resist the feeling that many of them doesn't look trustworthy.

And building trust on Internet and especially in Bitcoin community is really really hard. You probably remember all those recent scams as bitcoin7 and mybitcoin, right?

I'm personally very cautious which services I'm using and I'm always searching the Internet for good references. But this is chicken and egg problem. When there's new service, how it can prove they're trustworthy? Like this one (Bitzaar.com), which popped up today. It's new web wallet specialized for merchants and looks professional, but isn't that only new generation of mybitcoin scam? How can people trust them with storing funds?

So I have one idea, but it's mostly request for comments, nothing well-advised yet. Maybe we find some major flaw why it won't work, but nevermind.

Let's create escrow specialized for new services and for building their initial trust.

Why:
a) New services can deposit xxx coins to this escrow, which will be used as assurance in case they'll suddenly disappear or they got hacked (you know, many new useful services are usually in alpha or beta stage, it's hard to trust owner AND his alpha software).
b) Existing and well-settled services can use this escrow for their cold storage backup, as act of their openness to community.

ad b)
All bigger services (which are also well designed) are using some kind of cold storage (coins, which are managed by service, but they don't need to be used instantly, so they're stored on some offline medium). This is really good way how to protect user's funds against hackers. However users must believe this cold storage is well designed. Also many services are mostly one-man shows (like my pool :-) ); what happen when owner will die (God forbid!)? All coins will be probably lost, even when this owner had good reputation.

How:
Every service which want to build their trust in community by using this escrow should decide how many coins will deposit here. Of course merchant selling Alpaca socks don't need such big assurance as new ewallet. They can also claim they'll be storing some percent of all received coins here as a cold backup, which also depends on type of business. Typical ewallet or exchange can probably store more than 70% of all coins to cold backup without any problem, because most of received coins is just sitting here forever. Service simply announce their rules for using escrow and then they receive permanent address for storing funds. Finally they can use the fact they're using this escrow/cold backup on their website or promotion. There can exist simple public web UI which display contract details for given service so everybody can check if this service is really depositing enough funds.

Security:
* If it will work and will be succesful, in escrow will be probably huge amount of coins stored for longer time period. Fortunately, they don't need to be accessed online most of the time, so internal cold storage is a perfect way to go.
* Private keys for cold storages can be encrypted with erasure coding and every part can be provided to many well-trusted members of Bitcoin community. Thanks to this, there need to be a consensus of more people before cold storage will be accessed and coins used, because no single entity can take all coins from escrow and disappear.

Known problems:
1) How to check how many coins should be in escrow if service make a promise to pay some percent of their funds?
2) How to decide who to pay after service crash.
3) Service itself can act as many of customers in claiming process after crash, which will reduce paybacks for regular users.
4) How to pick "trusted members"?

ad 1)
It's for longer discussion, but I'm thinking about concept of reversed "green addresses". Service will use their green address for consolidating all income from customers. Every customer can check if his funds sent to this service has been transferred to this address and thus confessed as service income. Of course not many services will want to publicly show their income, but it's absolutely their choice; they'll receive additional trust for their openess. Personally I don't think revealing this information is so much sensitive. Total income and at least rough estimation of cold backup amount for the biggest Bitcoin services is usually publicly known (at least for Mt Gox and other exchanges and for most of the pools).

ad 2)
Depositing coins to escrow is pretty good signal for community that they're serious about their business, however it's only one part of problem. What if this service get really hacked or owner disappear? It's not not easy to answer who to pay and it depends on type of business. I can image that for some smaller business will be enough to make a promise like "If I disappear, use all those coins to Bitcoin development and give it to Bitcoin foundation". However users of bigger services (like exchange) will probably want to receive back at least part of their funds. There are still many solutions in the game, just two extreme ideas:

* Board of trusted members (holders of erasure coded private key for service funds?) will be established and they'll approve user's claims using some facts (realized transactions from private wallets to service wallet, scans of bank transfers etc). This can be a lot of work and nothing for impatient people. This also won't be absolutely fair, because not all users can provide enough evidence about all their funds stored there. But world isn't perfect and the main target is that funds from cold storage will be distributed back between people.

* Second way is more automated. If merchant will be interested, they can provide (daily) snapshots of customer's funds stored there, with absolute amounts or just as a percents of all funds. This report can be private, accessible only for erasure key holders, to protect personal data (account balances) of customers. Actually refunding wallet & share on total funds is necessary. This is of course related to point 3) below, but those snapshots can be used at least as starting point for next investigation (I have some idea for following discussion, if anybody will be interested).

ad 3)
To be discussed. Any idea?

ad 4)
Of course there's tiny chance that trusted members from Bitcoin community and holders of erasure coded private keys will make a devil plan, steal all deposited funds and buy some nice island on Bahamas. But every service can nominate another "trusted users" from Bitcoin community (and it's only up to people if they're trusted enough to believe it's not yet well-elaborated scam). Thanks to this, it's not necessary that all funds stored in escrow will be in hands of few people.

Concept of escrow/cold storage can be very flexible. I can imagine that somebody will deposit 2000 BTC on his service launch and claim his intention to send it (in case of scam/hack) to Bitcoin developers (or ongoing Bitcoin foundation?) as his commitment. Another extreme can be a cold backup of some exchange and tight integration of with escrow, so when service got hacked or operator disappear, every registered member will get his fair share of deposited funds. But it's definitely case to case what will fit better for given business.

Any suggestions?

Edit: Heh, much longer post than I initially expected :-).
1916  Bitcoin / Pools / Re: are there speed-differences between Pools? on: October 29, 2011, 12:50:49 PM
Have i told something else ?

Yes, this:

Quote
The more people the smaller the profit. In a mid- sized pool you earn more but you get paid out less frequent.

This leads to idea that mining on smaller pools is more profitable, which is wrong. The profit per time should be the same. Who care about per-round reward? It's only good feeling that you have bigger part of each block, but it does not affect anything else.

Sorry if I only understand you wrong, my English language skills are sometimes limited Smiley
1917  Economy / Speculation / Re: Rally!!! on: October 29, 2011, 12:45:39 PM

I really doubt that market will go up just because of 2000 BTC lost :-). It's abosolutely insignificant amount.

Edit: I bet that the reason behind price jump is a "short squeeze" on Bitcoinica.
1918  Bitcoin / Pools / Re: are there speed-differences between Pools? on: October 29, 2011, 12:43:13 PM
The more people the smaller the profit.

Bullshit.

In bigger pool you have lower reward PER ROUND, but you have more rounds in time. The reward per day/week should be absolutely the same.
1919  Bitcoin / Pools / Re: are there speed-differences between Pools? on: October 29, 2011, 12:38:15 PM
> could it be that I am mining with lower (or faster) speed than on other pools?

Teoretically no, if there aren't another issues.

> I only receive during last weeks about 1 BTC / day

Did you counted two DDoS attacks during last two weeks? Also yesterday was pretty crappy day with few long rounds, but it sometimes happen.

> Could it be that this is slowing me down

Definitely not.

My questions:
a) Do you see any connection issues?
b) What's your stale rate?
Edit: c) Which miner do you use? Latest one with LP support, ideally poclbm?

Only those two things actually matter. The rest is just a luck.

ad c) Some versions of phoenix are working really weird on some connections. For example latest phoenix has something like 40% of stale on one of my miner, without any obvious reason. But poclbm is rock solid everywhere and additionally it (correctly) supports NTime rolling, which is pretty nice feature for optimizing network communication.
1920  Bitcoin / Pools / Re: [1200 GH/s] Slush's Pool (mining.bitcoin.cz); LP & Ntime, NMC Merged mining on: October 29, 2011, 11:16:20 AM
This weekend (29-30. October) I'm migrating pool from London (linode.com) to France (ovh.com). Although I believe everything will be fine, there will be at least one outage during database migration (probably something around 30 minutes).
Pages: « 1 ... 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 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 ... 171 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!