 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
|
My dream scenario is that Zach gets his BFL refund in bitcoins and immediately distributes them to the bond holders so that the lawyers can't get them. That would be a wonderful "bonus" for the week.
|
|
|
|
|
Oops, I just read that I can't do M of N lockboxes with older versions of Armory.
So the question remains, will there be an offline bundle for Ubuntu 10.04?
|
|
|
|
|
I have Armory on an offline wallet using 10.04 and I see there's no offline bundle for v. 0.92.3. Is there a bundle on the way for 10.04, or do I have to find a newer computer for the wallet? I'm looking to move from cold storage to M of N security. I understand that I can do this with older versions of Armory, which is awesome. So for now I'm good, just curious about the long term plan for 10.04.
Thanks for a great wallet!
|
|
|
|
Is there a graceful method of shutting down the p2pool terminal? I haven't been able to find anything for it so I'm simply using Control C ... is there another / better option?
That's as graceful as it gets........you could sing a lullaby  You don't really want to be turning it off - let it run, & run, & run........ Thanks for the answer. I'm still experimenting so it's on and off at the moment. Next step is set it up for merged. Ordered new dual xeon server to be dedicated to pools, once it's ready to go then it will run & run & run ... I wouldn't buy hardware to run p2pool. My miners and my p2pool node are not in the same place and my efficiency is currently 108%. Pay $20 a month for a Linode near your miners and stop paying when you stop mining (which for most of us is any minute now). You'll get incredible network connectivity and the flexibility to turn things off without being stuck with equipment you don't need (like thousands of dollars of ASICs  |
|
|
|
What the frack just happened with the blocks? 2 in a row and so fast?
Lol, someone with a better understanding then I will have to figure this out, but both those blocks had the same height (321414) on the Bitcoin blockchain, but different hashes on the p2pool share chain. It looks like we orphaned our own block??? From Coin Cadence's p2pool logs (the lower one was orphaned): Note: Our stats will not be able to show the Orphan block for a while (because they were submitted at the same height), I'll be sure it is added soon... That's what it looked like to me. P2pool is so awesome we orphan our own blocks and keep the one with higher transaction fees. |
|
|
|
If you are mining on P2Pool.org you are paying a 100% fee!I was afraid this might happen... After 2 weeks of being pointed to http://minefast.coincadence.com with instructions to switch nodes, and an additional week of being completely offline I restarted the p2pool node at p2pool.org at a 100% fee, there is still over 800GH/s mining there. On Thursday when we launch the new site it will become apparent why we are running p2pool.org at a 100% fee. Anyway, if those are your miners and you do not want to contribute 100% of your mining power to p2pool.org, you may want to move them to another node Hi windpath, If your goal is to shut down the p2pool node on p2pool.org, I think the most direct way to accomplish that would be to turn off the p2pool software. Taking 100% of the mining proceeds could be interpreted in a negative way, especially by the miners connected to the node. Sure, you could say that they should have paid closer attention to their equipment but they may not see it that way! Maybe there is a technical reason that you can't turn off the p2pool node and the 100% tax is the only way to get people off of the node? I'm not trying to criticize you personally, I just think that this could be handled in a way that doesn't potentially lead to angry miners, lawsuits, bad publicity for p2pool, etc. Thanks for all of your efforts to make p2pool easier to use and enhance its popularity. I know that you've worked hard to grow p2pool, and I appreciate your efforts. |
|
|
|
No issues at all, and it is much faster with hardly any resource usage. No need to compile it, it's ready to run from within the client folder. Yes, I run it with the standard p2pool code. Well worth it Edit: Makes me wonder how much better p2pool would be if it was also in C++...... I've also starting using the C++ client. It came down to RAM usage. Here's average usage on my node: Matt's Java client: 150 MB Matt's fork of p2pool + Relay Node: About 50 MB more RAM usage than vanilla p2pool Matt's C++ client: 2MB So since RAM is very limited on my node the C++ client is the clear winner. Also it gives you the flexibility to upgrade the Relay Node client without restarting p2pool which can be painful, mess up stats, and/or cost you shares. |
|
|
|
On a brighter note - 7 blocks & counting...... That's great. Now if only it was usable by smaller miners. I was squeezed out. My node is empty because all of them had the same hash rate or me (1.2 TH/s) or lower, and couldn't get any shares. There are few things more frustrating than waiting 18 hours for a share only to see it roll off in 24 hours without a block.  M Not to sound harsh, but mining in general is not going well for small miners. This doesn't appear to be a p2pool problem, but a general bitcoin problem. It's the nature of the beast. |
|
|
|
Ok, this was my line of thinking. But you took it waaaay further. For that, I applaud you!
I'm beefing up my peers with a slightly different strategy: sort the node list by uptime and use the oldest nodes with reasonable latency. I figure that the oldest nodes will have the deepest roots into the p2pool network. Ok, I hope we just didn't ruin our competitive advantage here...
This kind of approach rarely works. In fact, by simply decreasing peering within the relay network, relay times improved. Mostly, using this approach means your peaks (remember when a new block is found you get huge bandwidth peaks, even though amortized across even a second, you wont see all that much bandwidth) will be significantly higher, leading to strange things on the network, mostly increased packet loss. This means instead of getting a block pretty quick, you'll have to wait for the packet to timeout and get a resend. I would recommend finding only a handful of peers which are both geographically local and have high hashpower so you'll get blocks they found directly from the horse's mouth. Matt, we're referring to p2pool peers, not bitcoin peers. I think that the p2pool blocks (the "shares") are very very small in comparison to bitcoin blocks. Since my node is the origin of the newly found share (the share is outbound to the rest of the p2pool network) it can only get out as fast as the maximum outbound bandwidth of my node - it seems to me that I want to try to hit that max (which in my case is 250 Mbps) so that there are many spokes to my hub (this seems to me to be hub/spoke topology in the first set of share transmissions, then it turns into a graph as the share gets retransmitted by my peer nodes). Am I totally off base here? I'm not an expert on p2pool, I just read some stuff. |
|
|
|
Heh, I went for the "scorched earth" peer list approach to see what happens... I went to the p2pool node info page, sorted by country, exported to CSV, then some grep, awk, cut and echo'd the 84 U.S. nodes that resulted. Currently it appears I've active peering connections with 60+ of them outbound (hovering between 62-64 average connected). I'm of the mindset that it doesn't hurt to peer with as many nodes as you are able to reliably communicate with, since you want to get your shares out to the network as fast as possible, before everyone else. If you are able to announce your share outbound quickly to as many nodes as you can, you might just win that race. I could be completely off in my thinking, and hurting myself by having so many peers connected. Time should tell tho I think, and if my efficiency suffers, then it might be better to approach it more methodically. Ok, this was my line of thinking. But you took it waaaay further. For that, I applaud you! I'm beefing up my peers with a slightly different strategy: sort the node list by uptime and use the oldest nodes with reasonable latency. I figure that the oldest nodes will have the deepest roots into the p2pool network. Ok, I hope we just didn't ruin our competitive advantage here... |
|
|
|
|
Thanks for the info kgb2mining.
It looks like the java version is using about 70 MB of RAM and 0.2% CPU. Since I already have the startup scripts, and upgrading is so simple, I think I'll just keep running the java version. It gives me some flexibility when it comes to upgrading (like, I can just upgrade the RelayNodeClient without restarting p2pool).
Interesting about your p2pool peer experimentation. Would you mind sharing your peer list? Has anyone found that there is an optimal number of peers? Several of these peers are gone now, but here's my list:
-n p2pool.org
-n minefast.coincadence.com
-n 14.17.121.234
-n 58.22.92.36
-n 115.201.192.188
-n 125.126.130.134
-n 107.170.178.16
-n 50.251.148.42
-n 115.202.27.30
-n 182.41.211.14
-n 50.248.204.210
-n 192.71.218.197
-n 107.170.116.123
-n 173.160.157.222
-n 82.196.8.44
|
|
|
|
|
Nice to see Matt being so responsive to the folks who are Java-averse. That's the way you build a user base!
Has anyone who ran p2pool + RelayNodeClient.jar compared the resource utilization with the 100% python version (Matt's fork of p2pool)? I'm interested in either a decrease in RAM or CPU utilization. I've been running the Java client on 2GB of RAM w/2 CPUs and haven't noticed trouble. I'm looking for some hard data to convince me that the switch to pure python is worth it.
Thanks for helping me be lazy and still run a bitchin p2pool node.
|
|
|
|
Just grabbed the new version, working perfectly. Also adding -Xmx my virt mem went from 11GB down to 2GB usage, so I'm a happy camper.
Great work Matt!
Hey guys, running windows 8.0 Bitcoin core and my p2pool node. Is there anyway for me to get this all up and running with this sort of setup? I cant figure out how you guys are doing this. Must I be running lenox? Any info would be much much appreciated.... Thanks. You should be able to download the latest Java JRE from Oracle, then run the same command: java -Xmx100m -jar DRIVE:\PATH\TO\RelayNodeClient.jar public.YOURRELAYREGION.relay.mattcorallo.com 127.0.0.1:8333 I'm not a Windows user, so I might have a minor detail wrong, but Java is cross-platform and works on many operating systems. |
|
|
|
Ha! Aug 25 22:44:32 p2pool.domain.name java[13614]: Aug 25, 2014 10:44:32 PM com.google.bitcoin.core.Peer processVersionMessage
Aug 25 22:44:32 p2pool.domain.name java[13614]: INFO: Connected to 127.0.0.1: version=70002, subVer='/Satoshi:0.9.2.1/', services=0...=317494
Aug 25 22:44:32 p2pool.domain.name java[13614]: Connected to local bitcoind!
Aug 25 22:44:32 p2pool.domain.name java[13614]: Connected to node with version: fuck it, ship it!
Aug 25 22:44:35 p2pool.domain.name java[13614]: 1409021075219: Received transaction bdece7858e2fdaa412f904dae818db7b7591f290056eae9...428ac7f |
|
|
|
kgb2mining is correct, the arguments to RelayNodeClient.jar include the host:port of your local bitcoind and the port for the Relay Network host is not required. The java application connects on 8336 only: [root@p2pool ~]# netstat -a |grep relay
tcp6 0 0 p2pool.domain.:45203 do-nyc1.relay.matt:8336 ESTABLISHED Glad I could help make p2pool that much more awesome! Kudos to Matt for reaching out to me and the thread to announce the upgrade, clear up our questions, and most importantly his massive improvement to the Bitcoin network. |
|
|
|
This may not be too useful since most people don't run CentOS7 / RHEL7, but here's a systemd script to run the RelayNodeClient application. Systemd has the very nice feature that it will restart the process if it dies, and all stdout messages can be monitored with "journalctl -f -u relaynodeclient". Put the text below into a file such as: /etc/systemd/system/relaynodeclient.service Then change the following to appropriate values: Change to the name of your bitcoind systemd unit file: Change to the name of your relaynodeclient user and group: User=YOURRELAYUSER
Group=YOURRELAYGROUP Change to the Relay Network region closest to your p2pool node: ExecStart=/bin/java -Xmx100m -jar /PATH/TO/RelayNodeClient.jar public.YOURRELAYREGION.relay.mattcorallo.com 127.0.0.1:8333 [Unit]
Description=relaynodeclient
After=network.target
After=bitcoin.service
[Service]
Type=simple
User=YOURRELAYUSER
Group=YOURRELAYGROUP
ExecStart=/bin/java -Xmx100m -jar /PATH/TO/RelayNodeClient.jar public.YOURRELAYREGION.relay.mattcorallo.com 127.0.0.1:8333
Restart=always
[Install]
WantedBy=multi-user.target *Edited to add Matt's suggestion of limiting java's heap space to 100 MB to conserve RAM. |
|
|
|
^ That's what he says. |
|
|
|
|
Good idea. I'll see what he says.
|
|
|
|
If you're running RelayNodeClient.jar it looks like it's time to upgrade. I got the following email from the author, Matt Corallo: Sorry for the inconvenience, please upgrade your relay client node as an incompatible server change was made . Still, fitting most blocks in one TCP packet is probably worth it. I'm waiting to hear back from him to see if he will be producing a .jar file, right now there's only RelayNodeClient.java. |
|
|
|
Yes, RelayNodeClient.jar is nice. Add node option can be checked with=> host public.us-east.relay.mattcorallo.com which gives IP=> public.us-east.relay.mattcorallo.com has address 162.243.69.180 then, netstat -lant | grep 162.243.69.180 Should give established connection between local IP and 162.243.69.180 To check actual traffic between local node and 162.243.69.180 tcpdump can be used. tcpdump -neivv -i MyNetworkInterface host 162.243.69.180 Change MyNetworkInterface respectively with your network interface. 0 packet captured means something is wrong, else should be fine. Cheers, Thanks for that info. The reason I didn't think a direct connection from bitcoind to the Relay Network worked for me is because after I did the "addnode" I checked bitcoind with the "getaddednodeinfo" command. I got the following output: [
{
"addednode" : "public.us-east.relay.mattcorallo.com",
"connected" : false,
"addresses" : [
{
"address" : "162.243.69.180:8335",
"connected" : "false"
}
]
}
] Also, the number of bitcoin peers from "getinfo" stayed the same. Thus I concluded that something was wrong and I went down the RelayNodeClient path. I would prefer to connect bitcoind directly to the Relay Network and save the RAM that RelayNodeClient uses, but its not a big deal (30 MB of RAM, I believe) either way. Has anyone else had success connecting bitcoind to the Relay Network without RelayNodeClient? |
|
|
|
|
