|
I'm going to have to get an FPGA and see if I can plug it into my chumby.
|
|
|
|
the Ledīs in the dummy plugs are not really usefull for everybody. they do the only job to show me if there is a card damaged.
for the reason that it is very cold and drafty in the room and that iīm very sluggardly i decide to install the ledīs
because so i can see without open the glass door between the rooms that every card is ok. if there is a card doing not enought hashes i need only restart the miner by remote and to 98% the led will not light if the card is damages after the miner has restart.
I am interested in what kind of contact plugs connected LEDs?! Mine on Linux, you'll never have to deal with dummy plugs. But those LEDs look so cool! |
|
|
|
I ordered 3 copies because I want one for myself and 2 of them in places where others can read them for free. Universities and libraries come to my mind when I think about the possibilities.
Leave one at the dentists office. Thats a good idea. I think the dentist's office is the last place that I touched a magazine. |
|
|
|
With a namecoin lite client, the server could direct you to a phishing site (which a public DNS can do anyways) but your client would trust the fake ssl certificate. That's a deal breaker for me. Most users of namecoin probably won't even have any coins so having their balances protected isn't really helpful.
I'm not sure of a good solution for a namecoin lite client.
I don't follow this. If the legitimacy of the certificate is somehow depending on how/where you look up the name, maybe whatever the problem is that you are perceiving could be fixed by putting a hash of a self-signed certificate into the namecoin blockchain or something? I do not follow though how the way you go about looking up the name has anything to do with whether the cetificate presented at the IP address or i2p destination or .onion address or whatever you end up at is going to be thought by your browser to be a legitimate certificate. -MarkM- I am only talking about lite clients here. The full client has no trouble with checking the validity of a name or SSL cert. If you are running a lite client, you don't have the blockchain. Any verification of data against the blockchain is impossible because you don't have the blockchain. If you ask a remote provider to resolve a namecoin name for you, you have to trust them. Trusting someone to hand you the real SSL certificate is not a good idea |
|
|
|
If anyone does not have the technical skill, time, hardware, or whatever to run their own instance of p2pool, feel free to point your miner to "p2pool.stitthappens.com:8336" with your username set to a bitcoin address and the password being w/e you want. The more I look at it, the better I think p2pool is for bitcoin. Since it is non-trivial to run a p2pool node (although I wouldn't say it is hard), I'm willing to run this node for anyone. If you use my node and want to donate something, I appreciate it. 1GH2r1uELMdn5726zxufpi5A3KswWNKU6Y I've also setup a tor hidden service for access to p2pool: id7ibznt6zsfp4kr.onion Not sure if there are any uses for mining over tor or how the latency affects stale rate, but what better way to know than to test? |
|
|
|
Hmm.. So how long should it take for the p2pool stat to change? 22:29:17.321000 Pool: 97434MH/s in 17642 shares (9305/21649 verified) Recent: 0.
00% >0H/s Shares: 0 (0 orphan, 0 dead) Peers: 9 Especially the "0H/s". Will it update once I solved my first share, or a few seconds after I start working with a connected miner? Oh. I'm not sure how that one works. H/s is output in so many places lol |
|
|
|
So I will solve shares in hours, and the stated mh/s is calculated by the solving-rate of shares?
The MH/s is the total number of hashes (good or bad) per second. It has nothing to do with the solving rate. |
|
|
|
I run a node (169.237.101.192) that is located in California. For some reason it shows up as being in Cairo at http://blockchain.info/connected-nodesIt might be because this same node runs a tor hidden service, but I'm not sure. Any response to this? |
|
|
|
I have knotwork.bit, I also have knotwork.i2p, knotwork.com and knotwork.net
Do I have to tell namecoin just one destination, or can I tell it about an i2p way to get there, a .onion way to get there, a .com way and a .net way and so on?
-MarkM-
I think you can (and should) put all of the possible ways. I'm not sure how good the current namecoin resolvers are at picking the "correct" one though. I know using the public DNS servers will only give you the IPs. If you run namecoind locally you should be able to choose which way to go. |
|
|
|
I just updated to git head to try and use the cool graphs that you added, and now p2pool does not work.
Older version of rrdtool apparently didn't have the --no-overwrite option. It wasn't necessary, so I removed it from the current git version of P2Pool... so git pull and try again?  3d4b58e fixed the error about rrdtool and now p2pool starts. Thanks! I still get the depreciation warning. $ ./run_p2pool.py
/home/user/.virtualenvs/p2pool/src/p2pool/p2pool/bitcoin/data.py:220: DeprecationWarning: object.__new__() takes no parameters
return Type.__new__(cls, bits, endianness)
2012-01-27 10:36:23.289400 p2pool (version 3d4b58e)
EDIT: What flavor of linux do you use to develop p2pool? I'm running p2pool in a vm so I have no problem installing something not ubuntu. Mine is only ubuntu because thats the ISO I had |
|
|
|
I just updated to git head to try and use the cool graphs that you added, and now p2pool does not work. /home/user/.virtualenvs/p2pool/src/p2pool/p2pool/bitcoin/data.py:220: DeprecationWarning: object.__new__() takes no parameters
return Type.__new__(cls, bits, endianness)
2012-01-27 00:26:35.821253 p2pool (version 6bc7e5a)
2012-01-27 00:26:35.821342
2012-01-27 00:26:35.909783 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'XXX'...
2012-01-27 00:26:37.006202 ...success!
2012-01-27 00:26:37.006344 Current block hash: 37b6cb25596d2f958329c09b804740b9ec17354c5ddfb2b54d0
2012-01-27 00:26:37.006382
2012-01-27 00:26:37.006434 Testing bitcoind P2P connection to '127.0.0.1:8333'...
2012-01-27 00:26:37.088783 ...success!
2012-01-27 00:26:37.088886
2012-01-27 00:26:37.088926 Computing payout script from provided address....
2012-01-27 00:26:37.089064 ...success!
2012-01-27 00:26:37.089374 Payout script: Address. Address: XXX
2012-01-27 00:26:37.089423
2012-01-27 00:26:37.090254 Loading shares...
2012-01-27 00:26:37.483400 1000
2012-01-27 00:26:37.877625 2000
2012-01-27 00:26:38.262550 3000
2012-01-27 00:26:38.716094 4000
2012-01-27 00:26:39.108707 5000
2012-01-27 00:26:39.511317 6000
2012-01-27 00:26:39.902087 7000
2012-01-27 00:26:40.299090 8000
2012-01-27 00:26:40.697647 9000
2012-01-27 00:26:41.103349 10000
2012-01-27 00:26:41.496330 11000
2012-01-27 00:26:41.891135 12000
2012-01-27 00:26:42.380966 13000
2012-01-27 00:26:42.829835 14000
2012-01-27 00:26:43.227463 15000
2012-01-27 00:26:43.628644 16000
2012-01-27 00:26:44.021879 17000
2012-01-27 00:26:44.426356 18000
2012-01-27 00:26:44.829588 19000
2012-01-27 00:26:45.214943 20000
2012-01-27 00:26:45.611580 21000
2012-01-27 00:26:46.169637 22000
2012-01-27 00:26:46.574828 23000
2012-01-27 00:26:46.972577 24000
2012-01-27 00:26:47.374394 25000
2012-01-27 00:26:47.761511 26000
2012-01-27 00:26:48.150344 27000
2012-01-27 00:26:48.553780 ...inserting 27972 verified shares...
2012-01-27 00:26:49.573026 ...done loading 27971 shares!
2012-01-27 00:26:49.573193
2012-01-27 00:26:49.573491 Initializing work...
2012-01-27 00:26:51.034321 ...success!
2012-01-27 00:26:51.034499
2012-01-27 00:26:51.035137 Joining p2pool network using port 8335...
2012-01-27 00:26:51.220395 ...success!
2012-01-27 00:26:51.220551
2012-01-27 00:26:51.223841 Listening for workers on port 8336...
2012-01-27 00:26:51.224123 Worker password: XXX (only required for generating graphs)
2012-01-27 00:26:51.228432 > Traceback (most recent call last):
2012-01-27 00:26:51.228539 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 354, in _startRunCallbacks
2012-01-27 00:26:51.228590 > self._runCallbacks()
2012-01-27 00:26:51.228625 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 371, in _runCallbacks
2012-01-27 00:26:51.228675 > self.result = callback(self.result, *args, **kw)
2012-01-27 00:26:51.228710 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 879, in gotResult
2012-01-27 00:26:51.228753 > _inlineCallbacks(r, g, deferred)
2012-01-27 00:26:51.228787 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 823, in _inlineCallbacks
2012-01-27 00:26:51.228820 > result = g.send(result)
2012-01-27 00:26:51.228860 > --- <exception caught here> ---
2012-01-27 00:26:51.228897 > File "/home/user/.virtualenvs/p2pool/src/p2pool/p2pool/main.py", line 736, in main
2012-01-27 00:26:51.228930 > grapher = graphs.Grapher(os.path.join(datadir_path, 'rrd'))
2012-01-27 00:26:51.228962 > File "/home/user/.virtualenvs/p2pool/src/p2pool/p2pool/graphs.py", line 102, in __init__
2012-01-27 00:26:51.229010 > 'RRA:AVERAGE:0.5:30:288', # last month
2012-01-27 00:26:51.229042 > rrdtool.error: unknown option '--no-overwrite'
2012-01-27 00:26:51.657401 Got new merged mining work! Difficulty: 516181.436892
2012-01-27 00:26:51.658127 Outgoing connection to peer 24.23.118.244:9333 established. p2pool version: 2 '7b8922d'
2012-01-27 00:26:51.658320 Got share hash, requesting! Hash: c2d9a6c4
2012-01-27 00:26:51.854667 Outgoing connection to peer 208.81.152.74:9333 established. p2pool version: 2 '633dd68'
2012-01-27 00:26:51.855205 Outgoing connection to peer 94.23.34.145:9333 established. p2pool version: 2 'a6ce02f'
2012-01-27 00:26:52.226962 Requesting parent share c63fc81e from 24.23.118.244:9333
2012-01-27 00:26:52.460567 Outgoing connection to peer 24.151.129.98:9333 established. p2pool version: 2 '82b4516'
2012-01-27 00:26:58.063172 Outgoing connection to peer 173.170.54.85:9333 established. p2pool version: 2 '633dd68'
2012-01-27 00:27:00.935492 Outgoing connection to peer 173.11.125.162:9333 established. p2pool version: 2 '7b8922d'
2012-01-27 00:27:05.305568 Outgoing connection to peer 109.74.195.142:9333 established. p2pool version: 2 '2ec1b55'
2012-01-27 00:27:05.970793 Have 100/1000 block headers
2012-01-27 00:27:12.243669 Outgoing connection to peer 82.154.113.60:9333 established. p2pool version: 2 '8ddab1b'
2012-01-27 00:27:12.880222 Outgoing connection to peer 66.41.108.220:9333 established. p2pool version: 2 'unknown'
2012-01-27 00:27:16.786067 Have 200/1000 block headers
2012-01-27 00:27:17.433484 Outgoing connection to peer 174.60.71.248:9333 established. p2pool version: 2 'c7feb00'
2012-01-27 00:27:26.995516 Have 300/1000 block headers
2012-01-27 00:27:37.387910 Have 400/1000 block headers
2012-01-27 00:27:47.408237 Have 500/1000 block headers
2012-01-27 00:27:47.500448 Got new merged mining work! Difficulty: 516181.436892
2012-01-27 00:27:57.979251 Have 600/1000 block headers
2012-01-27 00:28:08.209367 Have 700/1000 block headers
2012-01-27 00:28:18.363864 Have 800/1000 block headers
2012-01-27 00:28:29.101140 Have 900/1000 block headers
2012-01-27 00:28:39.313058 Have 1000/1000 block headers
2012-01-27 00:29:04.993332 Got new merged mining work! Difficulty: 516181.436892
2012-01-27 00:30:05.326778 Got new merged mining work! Difficulty: 516181.436892
2012-01-27 00:30:56.512763 Got new merged mining work! Difficulty: 516181.436892
I have the worker port set to 8336, but netstat shows nothing open there. The p2p port on 8335 is open though. $ sudo netstat -anp | grep 8336
$ sudo netstat -anp | grep 8335
tcp 0 0 0.0.0.0:8335 0.0.0.0:* LISTEN 8720/python
$ python -V
Python 2.6.5
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.3 LTS"
$ rrdtool
RRDtool 1.3.8 Copyright 1997-2009 by Tobias Oetiker <tobi@oetiker.ch>
Compiled Feb 23 2010 21:36:53
I also installed pysci, pygame, and PIL. p2pool version c7feb00 still works fine. |
|
|
|
Hi everyone,
Been mining great at home now but have made some arrangements to move my rigs to a cooler space that, unfortunately, have a craptastic wireless signal.
Bought a USB modem to generate / boost the wireless strength so that should solve my ocassional connection hiccups. The only caveat though is that the plan has a month to month personal limit of 5GB with an incredibly nasty overage charge.
I figure since Bitcoin does not really show bandwidth, could I just note the packets transfered from Windows 7's connection properties to determine just how much bandwidth I'm using in a day for my miners? Have any of you guys checked to see how much data transfer you're doing? These are standalone miners so they are just connecting to the pool I'm on and sending over whatever hashing / share data that they have to do. They *do not* have to download the blockchain thankfully, so that saves a ton of data use. Thanks in advance.
My server that runs a bitcoind node, a namecoind node, a p2pool node, and a stratum server send 4.4G and received 3.5G in the last 7 days. I think p2pool is the majority of the usage, but I don't have logs for that. |
|
|
|
Right now I am pretty sure none. Changing the bitcoin rules scares the shit out of me, esp if I (and most people) do not understand it.
Next time there is a vote they should tell the votes what they want to change and why.
I'm not voting because I am anti the change, I am not voting because I am ignorant.
Sounds like a sane approach to me. Thanks |
|
|
|
I don't see this as off topic at all. If I am going to invest money in someone, knowing how the want the network to operate is definitely a factor. |
|
|
|
|
Which BIP (16/17/none) is this pool voting for?
|
|
|
|
|
Which BIP (if any) are your miners voting for?
|
|
|
|
ByteCoin
So which BIP are you voting for?  |
|
|
|
I would like to propose one more thing that Stratum should keep track of, and perhaps one LESS thing.
The More thing: Nodes should inform Stratum that they can exchange P2P information about subject X, where X is an arbitrary string that is chosen by the developer of whatever X is. In turn, Stratum helps nodes aware of subject X find one another.
The Less thing: The block chain should not be assumed as something that will be exchanged by default, but rather, should be one of many subjects that can be subscribed to.
This is a really great abstraction. Building the stratum protocol to transmit arbitrary data is a great idea. Someone who accepts a pruned block chain is ultimately putting their trust in whoever pruned it. This is a tradeoff that becomes more likely to happen every day the block chain gets bigger. Someone who accepts a pruned chain also cannot participate in exchanging historical blocks with orthodox clients - they can only exchange such blocks with others who trust in the same chain. Hence Stratum being an ideal hookup mechanism for these clients - but without Stratum having to bear the burden of being the relay (except where the operator chooses to make his server relay such things).
I was under the assumption that the pruned blockchains would have verifiable hashes in them so that you wouldn't have to trust the distributor. Stratum should definitely keep this in mind. Let's say somebody else goes and creates a combined client that can trade Bitcoins, Namecoins, Litecoins, and whatever other kinds of coins, but all within the same client and protocol. Ideally, Stratum should help that client find other like-minded clients so they can exchange all of those blocks, all without burdening Stratum with block types its server operators don't want to waste resources on.
Wow. This is a great idea. I don't want to have a run a stratum server for bitcoin and a stratrum server for namecoin and so on. |
|
|
|
|
Show Posts
