Im not enought experienced to use this but i love to help new projects, so i dl this and keep it on my torrent client for future downloaders.
Cool, thanks for seeding. And if you'd like to try it, I'd be happy to try to walk you through setting it up. |
|
|
|
p2pool and bitcoind generate a lot of small writes. Nobody is worried about this killing usb drives?
I use usb linux on each of my rigs (6) and then point them all to a non-mining machine running bitcoind & p2pool on a HDD.
If you have 4 GB of RAM, it uses ram disk. Also, no, I'm not worried about killing the USB drive even a little bit. It would take months or years, and you can get 16 GB sticks for under $20 now. Hmm. Interesting. So it doesn't keep p2pool & blockchain persistent (written to usb drive). What happens on reboots? During a clean reboot, it tries to synchronize the bitcoin and namecoin chains to persistent storage, if you have it. And then when it boots, if it sees a local copy, and if that local copy isn't more than 2 weeks old, it will try to use it, rather than fetching it from the network again. No attempt is made to save the p2pool database. Your shares are already in the cloud, so there isn't any point. |
|
|
|
Oh, one other thing. Bitcoin earnings are generated directly to the address provided, so it is no big deal if the wallet created by bitcoind is lost every time you reboot when using the RAM drive.
The same is not true of namecoin. There is a script that runs from cron and checks the wallet balance every hour. If it finds anything, it attempts to send it to the address provided. This script is not well tested, and even if it were, you'd still have a huge window where a reboot could eat your wallet, and thus coins. Please keep that in mind.
I don't know how BAMT deals with persistency, but couldn't you do something similar to prevent issues like this? Obviously this would need a UBS stick and not a CD boot. What I'm thinking of doing in a future release will be to give the option to download the wallet.dat for namecoin from an external source. There are some security implications of that, of course, but since p2pcoin nodes should be running behind firewalls, it may be a good choice for people that care about the chance of losing their namecoin earnings. |
|
|
|
p2pool and bitcoind generate a lot of small writes. Nobody is worried about this killing usb drives?
I use usb linux on each of my rigs (6) and then point them all to a non-mining machine running bitcoind & p2pool on a HDD.
If you have 4 GB of RAM, it uses ram disk. Also, no, I'm not worried about killing the USB drive even a little bit. It would take months or years, and you can get 16 GB sticks for under $20 now. |
|
|
|
|
Oh, one other thing. Bitcoin earnings are generated directly to the address provided, so it is no big deal if the wallet created by bitcoind is lost every time you reboot when using the RAM drive.
The same is not true of namecoin. There is a script that runs from cron and checks the wallet balance every hour. If it finds anything, it attempts to send it to the address provided. This script is not well tested, and even if it were, you'd still have a huge window where a reboot could eat your wallet, and thus coins. Please keep that in mind.
|
|
|
|
p2pcoin-0.0.iso.torrentI'm setting up the seeds for the torrent now. This ISO works as a bootable CD, or you can use unetbootin to write it to a USB stick, or you can extract the files and set it up for PXE booting on your network. The easiest way to use it is with network configuration. To do that, you need to add a TXT record to your DNS. This needs to coordinate with your DHCP server. If your DHCP servers provide "example.com" as your default search domain, the record needs to be "p2pcoin.example.com", etc. The answer returned needs to be a URL where the box can download the configuration file. In bind 9, it would look like this: p2pcoin (tab) TXT (tab) "http://www.example.com/p2pcoin/options.txt"
When it boots, it will append "?id=" and the MAC address of eth0 to the URL and then download it. This way, you can specify different options for different boxes, if you need to. The configuration file takes a bunch of options. The parser is really dumb, so you need to get the format right. Every option needs to be the exact key in all caps, an equal sign, and the value. No spaces, no tabs. Look in /etc/p2pcoin.defaults for examples of what this file should look like. BITCOIN_CHAIN_SOURCE=a URL that rsync can use to download blk0001.dat and blkindex.dat (and eventually blk0002.dat, etc) NAMECOIN_CHAIN_SOURCE=a URL that rsync can use to download the chain files for namecoin (blk*.dat and nameindex.dat) TEMP_POOL=the full URL for the regular mining pool that you want to use during bootup, before p2pool starts BACKUP_POOL=the full URL for the backup mining pool that you want to use if there is a problem after p2pool starts, or if the TEMP_POOL has a problem during bootup BTC_ADDRESS=a bitcoin address where you want your earnings to go NMC_ADDRESS=a namecoin address where you want your earnings swept to BTC_ADDR_SOURCE=a URL that returns a bitcoin address NMC_ADDR_SOURCE=a URL that returns a namecoin address DONATE=1 (the percentage that you want to donate to the author of p2pool (not to me)) PHOENIX_DEFAULTS_SOURCE=a URL that returns a file with phoenix configuration lines for your cards You don't need both BTC_ADDRESS and BTC_ADDR_SOURCE, one or the other is fine. Same goes for the NMC versions. It adds ?id=MAC to those web requests if you include them. If you include a PHOENIX_DEFAULTS_SOURCE, that format is tricky too. It needs to be the exact output of aticonfig --list-adapters, then a tab, and the options to be passed to phoenix when mining on p2pool, then another tab, and the exact options to be passed to phoenix when mining on the startup pool. Look at /etc/phoenix.defaults for examples of this file. Side note, please send any good configs to me so that I can include them in future releases.If you are not using network configuration, you should edit /etc/p2pcoin.defaults and /etc/phoenix.defaults directly, which means that you need to set up persistent storage. To do that, you need to have a ext2/3/4 filesystem available on the machine labelled "live-rw". If you are using a USB stick, you can just partition it with a 1 GB FAT partition bootable, and use the rest for persistence. If you are booting from a CD, you can use a USB stick or a hard drive for storage. If you have enough RAM, which is about 4 GB, it tries to run bitcoind and namecoind completely out of RAM disk, which is very fast. If you don't have enough RAM for that, you will need about 4 GB of persistent storage available. I've probably forgotten a bunch of stuff. Let me know if anyone has any questions.
|
|
|
|
Ok, I may be hung over, but the script is working. I wanted to just paste it into the forums, but when I do, it messes up the tabs and spaces. Instead, you'll need to download them. Build ScriptMakefileDownload these two files into a normal user's home directory ( /home/whatever ), set the script executable, then run it. The script will fetch the packages, build them, then build bitcoind. |
|
|
|
Ok, I can verify that this process works as I now have bitcoind running on CentOS 32-bit! \o/
kjj, would you care to explain any drawbacks to using this procedure? Is the resulting bitcoind lacking anything or is it possible that this build process is likely to introduce problems when used to build later versions of bitcoind?
Heh. I have no idea, to be honest. I know it doesn't include UPNP, but that shouldn't be a problem for most people running CentOS. When I was tweaking the makefile, I kept getting strange warnings about static builds trying to dlopen shared libraries. I think that will be a problem if someone compiles it on one box, then moves it to a box with different libraries. I'm not really sure which libraries, if any, would cause those problems. It could possibly also cause problems if someone updates the libraries on the box it is on. Also, I saw that someone else had asked for a single document showing all of the steps. I'm not much of a document sort of guy, but this might be of interest to someone. Save it as a shell script in your user's home directory, alongside the makefile.new from above. Then set it executable, and run it. You should end up with a working bitcoind. Note that I haven't tested this yet. I'm running it right now, and so far so good, but boost takes forever to build, so it might not finish before I leave for the bar. I'll let everyone know how it goes when I can, but that might be tomorrow. Ignore this script. It doesn't work, and I don't have time to fix it right now. Check back tomorrow.#!/bin/bash
if [ ! -x /usr/bin/wget ] ; then
echo "for some silly reason, wget is not executable. Please fix this (as root do chmod +x /usr/bin/wget) and try again"
exit
fi
USERNAME=`whoami`
cd ~
mkdir Bitcoin
cd Bitcoin
mkdir Libraries
mkdir Trunk
mkdir Deps
cd Libraries
wget -qO- http://sourceforge.net/projects/boost/files/boost/1.49.0/boost_1_49_0.tar.bz2/download | tar xjv
cd boost_1_49_0
./bootstrap.sh
./bjam --prefix=~$USERNAME/Bitcoin/Deps link=static runtime-link=static install
cd ..
wget -qO- http://openssl.org/source/openssl-1.0.0g.tar.gz | tar xzv
cd openssl-1.0.0g
if uname -a | grep -q x86_64 ; then
./Configure no-shared --prefix=~$USERNAME/Bitcoin/Deps --openssldir=~$USERNAME/Bitcoin/Deps/openssl linux-x86_64
else
./Configure no-shared --prefix=~$USERNAME/Bitcoin/Deps --openssldir=~$USERNAME/Bitcoin/Deps/openssl linux-generic32
fi
make
make install
cd ..
wget -qO- http://download.oracle.com/berkeley-db/db-5.1.19.tar.gz | tar xzv
cd db-5.1.19/build_unix
../dist/configure --prefix=~$USERNAME/Deps/ --enable-cxx
make
make install
cd ../..
mkdir bitcoin-master
cd bitcoin-master
wget -qO- https://github.com/bitcoin/bitcoin/tarball/master --no-check-certificate | tar xzv --strip-components 1
cd src
#cp -vap ~$USERNAME/makefile.new .
cat ~$USERNAME/makefile.new | sed s/kjj/$USERNAME/g > makefile.new
make -f makefile.new bitcoind
|
|
|
|
kjj, can you post your modified makefile? patch fails for me and I'm not sure if it's whitespace or what...
I found with openssl that it doesn't like relative paths so it's probably best to make these build instructions use only absolute paths throughout.
In regards to the bounty and the hackiness of this approach, who will bless it? If it works and is presented in a single document, I would be inclined to call it done.
makefile.new below. The make command was make -f makefile.new bitcoind# Copyright (c) 2009-2010 Satoshi Nakamoto
# Distributed under the MIT/X11 software license, see the accompanying
# file license.txt or http://www.opensource.org/licenses/mit-license.php.
USE_UPNP:=
DEFS=-DNOPCH
DEFS += $(addprefix -I,$(CURDIR) $(BOOST_INCLUDE_PATH) $(BDB_INCLUDE_PATH) $(OPENSSL_INCLUDE_PATH))
LIBS = $(addprefix -L,$(BOOST_LIB_PATH) $(BDB_LIB_PATH) $(OPENSSL_LIB_PATH))
DEPSDIR=/home/kjj/Bitcoin/Deps
INCLUDEPATHS= -I"$(DEPSDIR)/include"
LIBPATHS= -L"$(DEPSDIR)/lib"
BOOST_LIB_SUFFIX=.a
BDB_LIB_SUFFIX=.a
CRYPTO_LIB_SUFFIX=.a
LMODE2 = static
LMODE = static
# for boost 1.37, add -mt to the boost libraries
LIBS += \
-Wl,-Bstatic \
-mtl $(DEPSDIR)/lib/libboost_system$(BOOST_LIB_SUFFIX) \
-mtl $(DEPSDIR)/lib/libboost_filesystem$(BOOST_LIB_SUFFIX) \
-mtl $(DEPSDIR)/lib/libboost_program_options$(BOOST_LIB_SUFFIX) \
-mtl $(DEPSDIR)/lib/libboost_thread$(BOOST_LIB_SUFFIX) \
$(DEPSDIR)/lib/libdb_cxx$(BDB_LIB_SUFFIX) \
-mtl $(DEPSDIR)/lib/libssl.a \
-mtl $(DEPSDIR)/lib/libcrypto$(CRYPTO_LIB_SUFFIX) \
-lgcc
ifndef USE_UPNP
override USE_UPNP = -
endif
ifneq (${USE_UPNP}, -)
LIBS += -l miniupnpc
DEFS += -DUSE_UPNP=$(USE_UPNP)
endif
ifneq (${USE_SSL}, 0)
DEFS += -DUSE_SSL
endif
LIBS+= \
-Wl,-B$(LMODE2) \
-l z \
-l dl \
-l pthread
# Hardening
# Make some classes of vulnerabilities unexploitable in case one is discovered.
#
# This is a workaround for Ubuntu bug #691722, the default -fstack-protector causes
# -fstack-protector-all to be ignored unless -fno-stack-protector is used first.
# see: https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/691722
HARDENING=-fno-stack-protector
# Stack Canaries
# Put numbers at the beginning of each stack frame and check that they are the same.
# If a stack buffer if overflowed, it writes over the canary number and then on return
# when that number is checked, it won't be the same and the program will exit with
# a "Stack smashing detected" error instead of being exploited.
HARDENING+=-fstack-protector-all -Wstack-protector
# Make some important things such as the global offset table read only as soon as
# the dynamic linker is finished building it. This will prevent overwriting of addresses
# which would later be jumped to.
HARDENING+=-Wl,-z,relro -Wl,-z,now
# Build position independent code to take advantage of Address Space Layout Randomization
# offered by some kernels.
# see doc/build-unix.txt for more information.
ifdef PIE
HARDENING+=-fPIE -pie
endif
# -D_FORTIFY_SOURCE=2 does some checking for potentially exploitable code patterns in
# the source such overflowing a statically defined buffer.
HARDENING+=-D_FORTIFY_SOURCE=2
#
DEBUGFLAGS=-g
CXXFLAGS=-O2
xCXXFLAGS=-pthread -Wextra -Wno-sign-compare -Wno-char-subscripts -Wno-invalid-offsetof -Wformat-security \
$(DEBUGFLAGS) $(DEFS) $(HARDENING) $(CXXFLAGS) $(INCLUDEPATHS) -static
OBJS= \
obj/checkpoints.o \
obj/netbase.o \
obj/crypter.o \
obj/key.o \
obj/db.o \
obj/init.o \
obj/irc.o \
obj/keystore.o \
obj/main.o \
obj/net.o \
obj/protocol.o \
obj/bitcoinrpc.o \
obj/rpcdump.o \
obj/script.o \
obj/util.o \
obj/wallet.o
all: bitcoind
# auto-generated dependencies:
-include obj/*.P
-include obj-test/*.P
obj/%.o: %.cpp
$(CXX) -c $(xCXXFLAGS) -MMD -o $@ $<
@cp $(@:%.o=%.d) $(@:%.o=%.P); \
sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \
-e '/^$$/ d' -e 's/$$/ :/' < $(@:%.o=%.d) >> $(@:%.o=%.P); \
rm -f $(@:%.o=%.d)
bitcoind: $(OBJS:obj/%=obj/%)
$(CXX) $(xCXXFLAGS) -o $@ $^ $(LDFLAGS) $(LIBS)
TESTOBJS := $(patsubst test/%.cpp,obj-test/%.o,$(wildcard test/*.cpp))
obj-test/%.o: test/%.cpp
$(CXX) -c $(TESTDEFS) $(xCXXFLAGS) -MMD -o $@ $<
@cp $(@:%.o=%.d) $(@:%.o=%.P); \
sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \
-e '/^$$/ d' -e 's/$$/ :/' < $(@:%.o=%.d) >> $(@:%.o=%.P); \
rm -f $(@:%.o=%.d)
test_bitcoin: $(TESTOBJS) $(filter-out obj/init.o,$(OBJS:obj/%=obj/%))
$(CXX) $(xCXXFLAGS) -o $@ $(LIBPATHS) $^ -Wl,-B$(LMODE) -lboost_unit_test_framework $(LDFLAGS) $(LIBS)
clean:
-rm -f bitcoind test_bitcoin
-rm -f obj/*.o
-rm -f obj-test/*.o
-rm -f obj/*.P
-rm -f obj-test/*.P
|
|
|
|
Really? I just nuked my directory to start over, and did: tar xzvf ../../openssl-1.0.0g.tar.gz
cd openssl-1.0.0g/
./Configure no-shared --prefix=~/Bitcoin/Deps --openssldir=~/Bitcoin/Deps/openssl linux-x86_64
make depend
make
with no errors. What was the output of your uname -a ? |
|
|
|
If you want the other links, they are: Boost 1.49.0, or go here and pick the latest version. openSSL-1.0.0g, or go here and pick a different release. No idea if the betas are any good. For BDB, go here and click the blue Download link. Or, skip the splash pages and download 5.1.19 directly. I didn't include them before because I figured it was easy enough for other people to copy the links out of that PDF and navigate to the current versions. Oh, and I noticed one other thing that I did differently from the guide. I'll edit the post to include it. And just for fun, here is a my centos box running bitcoind, busily downloading the blockchain... [kjj@crs00 src]$ cat /etc/redhat-release
CentOS release 5.7 (Final)
[kjj@crs00 src]$ ./bitcoind getinfo
{
"version" : 60000,
"protocolversion" : 60000,
"balance" : 0.00000000,
"blocks" : 138239,
"connections" : 8,
"proxy" : "",
"difficulty" : 1690895.80305239,
"testnet" : false,
"keypoololdest" : 1330099058,
"keypoolsize" : 101,
"paytxfee" : 0.00000000,
"errors" : ""
}
[kjj@crs00 src]$
|
|
|
|
Used version 1.49.0 of Boost
Used version 1.0.0g of openssl
How do you get boost 1.49.0 to compile? The latest version that comes packaged for CentOS is 1.33.1 Same for openssl, the latest packaged version is 0.9.8e The 3.22 recipe goes through great many hoops, including download links to long gone tarballs of legacy versions of those pesky libraries. It's self-contained and requires nothing more than a CentOS install DVD, and a 3.22 git mirror. One can follow the instructions and actually build 3.22 (for x86, and with tiny fixes also for x64). However, requiring boost 1.49.0 without saying how to make it is not going to help. I know because I once tried to build a recent bitcoin, and failed (after 2 days of dependency hell). I followed the instructions in the guide that I linked exactly, with the exceptions noted. |
|
|
|
I just followed the instructions in the Steurer guide with the following exceptions: Used version 1.49.0 of Boost, adjust the ./bjam line for --prefix=../../DepsUsed version 1.0.0g of openssl, add no-shared to the ./Configuration line and run make depend before makeUsed the master tarball of bitcoin instead of git clone Different makefile, using this patch fix the DEPSDIR= line to match your path: --- makefile.unix 2012-02-23 13:33:30.000000000 -0500
+++ makefile.new 2012-02-24 10:57:14.000000000 -0500
@@ -2,34 +2,34 @@
# Distributed under the MIT/X11 software license, see the accompanying
# file license.txt or http://www.opensource.org/licenses/mit-license.php.
-USE_UPNP:=0
+USE_UPNP:=
DEFS=-DNOPCH
DEFS += $(addprefix -I,$(CURDIR) $(BOOST_INCLUDE_PATH) $(BDB_INCLUDE_PATH) $(OPENSSL_INCLUDE_PATH))
LIBS = $(addprefix -L,$(BOOST_LIB_PATH) $(BDB_LIB_PATH) $(OPENSSL_LIB_PATH))
-LMODE = dynamic
-LMODE2 = dynamic
-ifdef STATIC
- LMODE = static
- ifeq (${STATIC}, all)
- LMODE2 = static
- endif
-else
- TESTDEFS += -DBOOST_TEST_DYN_LINK
-endif
+DEPSDIR=/home/kjj/Bitcoin/Deps
+INCLUDEPATHS= -I"$(DEPSDIR)/include"
+LIBPATHS= -L"$(DEPSDIR)/lib"
+BOOST_LIB_SUFFIX=.a
+BDB_LIB_SUFFIX=.a
+CRYPTO_LIB_SUFFIX=.a
+
+LMODE2 = static
+LMODE = static
# for boost 1.37, add -mt to the boost libraries
LIBS += \
- -Wl,-B$(LMODE) \
- -l boost_system$(BOOST_LIB_SUFFIX) \
- -l boost_filesystem$(BOOST_LIB_SUFFIX) \
- -l boost_program_options$(BOOST_LIB_SUFFIX) \
- -l boost_thread$(BOOST_LIB_SUFFIX) \
- -l db_cxx$(BDB_LIB_SUFFIX) \
- -l ssl \
- -l crypto
+ -Wl,-Bstatic \
+ -mtl $(DEPSDIR)/lib/libboost_system$(BOOST_LIB_SUFFIX) \
+ -mtl $(DEPSDIR)/lib/libboost_filesystem$(BOOST_LIB_SUFFIX) \
+ -mtl $(DEPSDIR)/lib/libboost_program_options$(BOOST_LIB_SUFFIX) \
+ -mtl $(DEPSDIR)/lib/libboost_thread$(BOOST_LIB_SUFFIX) \
+ $(DEPSDIR)/lib/libdb_cxx$(BDB_LIB_SUFFIX) \
+ -mtl $(DEPSDIR)/lib/libssl.a \
+ -mtl $(DEPSDIR)/lib/libcrypto$(CRYPTO_LIB_SUFFIX) \
+ -lgcc
ifndef USE_UPNP
override USE_UPNP = -
@@ -86,7 +86,7 @@
DEBUGFLAGS=-g
CXXFLAGS=-O2
xCXXFLAGS=-pthread -Wextra -Wno-sign-compare -Wno-char-subscripts -Wno-invalid-offsetof -Wformat-security \
- $(DEBUGFLAGS) $(DEFS) $(HARDENING) $(CXXFLAGS)
+ $(DEBUGFLAGS) $(DEFS) $(HARDENING) $(CXXFLAGS) $(INCLUDEPATHS) -static
OBJS= \
obj/checkpoints.o \
And then just make -f makefile.new bitcoind. This is an ugly hack and I really don't know what I'm doing. Please save the bounty until someone better gives the proper solution. |
|
|
|
So in conclusion I would like to see someone explain to me how does signing transactions from multiple devices actually work, step by step? If this hasn't been thought out in advance, you have to be kidding me.
Step 1, I tell my client to send 5 coins to address XYZ. Step 2, my client creates that transaction, signs it with the key it has, then sends it to my wallet service. Step 3, my wallet service looks up my policy preferences, and since the transaction is more than 2 BTC but less than 10 BTC (my policy) it sends a text message to my phone asking me to look up and reply with code Q7. Step 4, I pull my wallet service card out of my (physical) wallet, go down to row Q and over to column 7, read d013e7 and punch it into my phone. Step 5, my wallet service verifies my reply, then signs the transaction that I had sent it earlier using the key it has. Step 6, my wallet service now sends my double-signed 2-of-2 key transaction out to the bitcoin network. Step 7, the bitcoin network checks that the two signatures on this transaction match the P2SH signature that was provided earlier, and the BTC shows up in the vendor's wallet. |
|
|
|
Waiting 6 confirmations to get refunded might suck. Especially if its the fault of the cashier.
Lol wut I only carry a few BTC that are easily accessible from my phone. The rest are on a locked down computer or paper storage. Say I send 10 BTC to a shirt store to buy some shirts. It turns out I bought the wrong size shirt and so go to return it. They don't have the size I want and so I ask for a refund. With cash, they can just give me cash back and I can go to another store and immediately buy something. With bitcoin, if they credit my phone's wallet with the refund, I can't spend those coins at the store next door until I wait for 6 confirmations. Depending on how many coins I have in my phone's wallet, this could be a problem. Make sense? EDIT: This has nothing to do with BIP 16/17 This is the wrong model. The problem you mention is even worse today. Even if you wait the full 6 confirmations, it will still be hours or days faster than waiting for the store and your bank to process a refund to your credit card. Also, good luck getting cash refunds. Most places mail you a check when refunding a cash transaction when the amount is over some tiny limit. |
|
|
|
I don't understand how a 2 phase commit will improve security when one of the phases will only practically be controlled by the attaker?
So say you go to the store and buy a snickers. Today you verify amount of BTC and destination address then send the money. The store sees the payment (one destination address per register) and lets you exit the store.
With these BIPS the only change is that the guy behind the register has to press an ACCEPT button right?
Am I understanding this correctly?
I don't think you are understanding this correctly. Someone has to hit two accept buttons to spend those coins. This keeps your cashiers from spending the funds without the boss' approval. It seems rare that you'd need a cashier to have access, just pay give them watching only access. Multi-sig is for when multiple bosses need to sign off and other cases like that. what about for refunds? i wouldn't say that's rare. Cashiers would have access to a small wallet for refunds, with the ability to ask a manager for larger refunds. A refund doesn't need to be the return of the same coins, just the same amount. |
|
|
|
|
The probability is effectively zero. Even if the entire mass of the solar system was converted to computing devices and run for a very long time.
|
|
|
|
I started with linuxcoin and my headless mining scripts, and I've added p2pool and some new tricks. I'm calling it p2pcoin for lack of a better name. * Network provisioning - checks DNS for a URL to fetch the config file - many config options can be specified in the file or fetched from URLs * BFGminer pool list is localhost, then up to 10 PEER[0-9]= lines, then BACKUP_POOL=, then TEMP_POOL= * uses "-S all" in bfgminer to find PGA/ASIC devices and "-S opencl:auto" to find Radeons * full bitcoind node * full namecoind node * full p2pool node * can use rsync to fetch both block chains * can use persistence, but works much better using RAM drives (needs ~24 GB of RAM or flash or both if you want to run bitcoind/p2pool) * works great from PXE * works as a dumb miner if it can't run bitcoind It still has a bunch of ugly hacks and quirks, but works quite well. It attempts to handle local errors the best it can, and has a heartbeat function to report stats every minute. I use the heartbeat stats to monitor each box and trigger a network power strip to reboot boxes that are seriously stuck. Note: The high share speed of p2pool might wear out your flash drive. If this bothers you, don't use persistence, or just boot from CD or PXE. Usage example (my mining farm):I have one box with 32 GB RAM, and several boxes with much less. All use PXE to boot, none have persistent storage. All boxes fire up bfgminer as soon as they are booted. The big box uses rsync to fetch a copy of the block chain from a server on my network, then reindexes it and eventually p2pool starts. The smaller boxes detect that they are unable to run bitcoind, and just run as dumb miners. While the p2pool box is starting up, all bfgminer instances (including on the p2pool box) fail down their list to an external pool. Once p2pool is ready, they all switch back to the local pool.
Current - Version 0.7.0: p2pcoin-0.7.0.iso.torrent - 2013-12-18 - Updated bitcoind to 0.8.6, updated bfgminer to 3.8.1, updated p2pool to 13.4.
Version 0.0: p2pcoin-0.0.iso.torrent - 2012-02-26 - initial early testing release Version 0.1: p2pcoin-0.1.iso.torrent - 2012-02-28 - p2pool updated to 0.9.1 - still early testing Version 0.2: p2pcoin-0.2.iso.torrent - 2012-03-09 - p2pool updated to 0.9.2, bitcoind updated to 0.6.0rc2 - fixed logrotate problem Version 0.3: p2pcoin-0.3.iso.torrent - 2012-03-30 - p2pool updated to 0.10.3, bitcoind updated to 0.6.0final Version 0.3.1: p2pcoin-0.3.1.iso.torrent - 2012-04-23 - fixed CD boot problem Version 0.4: p2pcoin-0.4.iso.torrent - 2012-05-03 - updated p2pool to 0.11.1 Version 0.4.1: p2pcoin-0.4.1.iso.torrent - 2012-05-23 - changed RAMdisk settings, upgraded to p2pool 0.11.2 Version 0.6: p2pcoin-0.6.0.iso.torrent - 2013-01-26 - Tons of changes. Now using BFGminer Current - Version 0.6.4: p2pcoin-0.6.4.iso.torrent - 2013-07-07 - Updated bitcoind to 0.8.3, updated bfgminer to 3.1.1, updated p2pool to 13.0. |
|
|
|
I'm getting this using p2pool 0.9 (1bdeed1) and bitcoind 0.6rc1:
Constantly or just occasionally? Maybe you were on a Bitcoin block fork.. It stopped after a while, but it popped up every dozen seconds or so for several minutes while it was happening. But, if bitcoind and p2pool had different ideas about which block they should be building on, that is a pretty big problem, is it not? |
|
|
|
I'm getting this using p2pool 0.9 (1bdeed1) and bitcoind 0.6rc1: 2012-02-23 01:01:45.821401 New work for worker! Difficulty: 0.999985 Share difficulty: 515.666135 Total block value: 50.048000 BTC including 82 transactions
2012-02-23 01:01:45.825691
2012-02-23 01:01:45.825773 Error when requesting noncached value:
2012-02-23 01:01:45.825843 > Traceback (most recent call last):
2012-02-23 01:01:45.825909 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 388, in errback
2012-02-23 01:01:45.825979 > self._startRunCallbacks(fail)
2012-02-23 01:01:45.826044 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 455, in _startRunCallbacks
2012-02-23 01:01:45.826107 > self._runCallbacks()
2012-02-23 01:01:45.826164 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 542, in _runCallbacks
2012-02-23 01:01:45.826227 > current.result = callback(current.result, *args, **kw)
2012-02-23 01:01:45.826286 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 1076, in gotResult
2012-02-23 01:01:45.826347 > _inlineCallbacks(r, g, deferred)
2012-02-23 01:01:45.826406 > --- <exception caught here> ---
2012-02-23 01:01:45.826465 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 1018, in _inlineCallbacks
2012-02-23 01:01:45.826527 > result = result.throwExceptionIntoGenerator(g)
2012-02-23 01:01:45.826586 > File "/usr/lib/python2.6/dist-packages/twisted/python/failure.py", line 350, in throwExceptionIntoGenerator
2012-02-23 01:01:45.826648 > return g.throw(self.type, self.value, self.tb)
2012-02-23 01:01:45.826706 > File "/opt/p2pool/p2pool/main.py", line 178, in <lambda>
2012-02-23 01:01:45.826768 > height_cacher = deferral.DeferredCacher(defer.inlineCallbacks(lambda block_hash: defer.returnValue((yield bitcoind.rpc_getblock('%x' % (block_hash,)))['blockcount'])))
2012-02-23 01:01:45.826829 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 1018, in _inlineCallbacks
2012-02-23 01:01:45.826891 > result = result.throwExceptionIntoGenerator(g)
2012-02-23 01:01:45.826950 > File "/usr/lib/python2.6/dist-packages/twisted/python/failure.py", line 350, in throwExceptionIntoGenerator
2012-02-23 01:01:45.827010 > return g.throw(self.type, self.value, self.tb)
2012-02-23 01:01:45.827069 > File "/opt/p2pool/p2pool/util/jsonrpc.py", line 67, in callRemote
2012-02-23 01:01:45.827128 > raise Error(**resp['error'])
2012-02-23 01:01:45.827203 > p2pool.util.jsonrpc.Error: -5 Block not found
2012-02-23 01:01:45.827252
2012-02-23 01:01:47.954886 P2Pool: 17388 shares in chain (10647 verified/17392 total) Peers: 10 (0 incoming)
|
|
|
|
|
Show Posts
