p2pool's main problem is being penalized for including transactions.
P2pool miners are protecting the network against >50% attacks. That is a HUGE benefit for the bitcoin network. Although the concept sounds good, since p2pool is only around 300-400GH/s - it really isn't protecting anything ... and if p2pool miners do as you suggest below, the larger pools, that include more transactions, are indeed better for BTC ... Most p2pool users don't have the powerful servers and gigabit internet connections, so they should not include every possible 0-fee or 0.0005 BTC/kB transaction. It's not a huge problem if we leave that to the centralized pools.
And I thought forrest made it so that the transactions are really quickly between peers anyways, so are miners really still being penalized?
|
|
|
Super excited for this. Any estimates for when you will accept orders? Maybe 4-6 weeks?
|
|
|
don't make me post goatse please? That is almost as old dammit.
Only if you animate it...
|
|
|
What movie is that from? ^
Children of Men
|
|
|
Looks like someone already necro'd this thread so I won't have to. I stumbled across this thread while looking for something faster than pywallet to convert hexkeys to WIF privkeys and addresses... haven't quite gotten it running yet as it appears to depend on vim, which I don't usually have installed (vim provides xxd) just got it running after installing vim. It might be worth noting in the OP that it needs vim (and openssl, but I already had that) to run. Why would this depend on vim? I don't see vim called anywhere in the script.
|
|
|
About memory leaking, this is a ubuntu 64bit after a little more than 48 hours of running latest p2pool PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5409 user 20 0 1371m 1.2g 3552 S 8.3 30.9 168:18.05 python
and I have 7 peers with 4 incoming ones. spiccioli. Here is a fedora 16, 32 bit, using pypy after three days, more or less 14844 user 20 0 1427m 1.3g 14m S 8.3 23.8 428:34.52 pypy
spiccioli. Gentoo 64 bit, python 2.7.3 after 5 days: bitcoin 9030 5.8 11.5 973680 705960 pts/12 Ssl+ Jan02 439:01 /usr/bin/python2.7 run_p2pool.py --disable-upnp --max-conns 6 [...]
I left the options that didn't leak any authentication info, I use merged mining on namecoin. It uses more RAM than it used to (some earlier version didn't need much more than 300M). I'm merge mining namecoin with 0981bdfb4e3fc266463be104c8e5441720173cb8 on Ubuntu 12.04.1 LTS 64-bit with python 2.7.3. However, I'm not actively mining on my node. Node uptime: 2.771 days Peers: 6 out, 21 in
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29401 coiner 20 0 635m 366m 4012 S 15 9.3 321:10.29 python
I asked this on IRC, but didn't get much response. I just have a small GPU rig and so I stopped mining on p2pool. What benefits are there to p2pool if I keep my node online? It has relatively fast hard drives and very fast and stable internet. I'm guessing it would make a DOS attack against p2pool harder. Would one node that isn't mining make a difference in an attack? It might also help with block progation and could reduce orphans. Any way to quantify how much?
|
|
|
Is your hidden service down?
I just put one up at "k3m4jg4irk7duq2q.onion" and was trying to use yours to test. It's running on a small ec2 instance.
|
|
|
I don't understand why this is so exciting. What's the difference between using android and ubuntu if you use proprietary software anyway. Simply buy an OpenMoko, install debian and use free software only. That's the real deal and possible since years.
Did you not actually read the article? You only have to get through the first paragraph to see what makes this interesting... unlike other smartphone operating systems, it will work as a full desktop OS when connected to a monitor, keyboard, and mouse.
Also, developed in private != proprietary
|
|
|
Apparently they could not be bothered with putting the key needed on a key server that is what the error is telling you.
Red Emerald is actually making an unpaid effort to help us install Armory in an easier way. You really are quite hostile to him! Most likely my gpg setup is querying the wrong keyserver. While it would be nice if things worked in the first try, sometimes it takes a few attempts before such a setup script works for everyone. So pointing out the useless way it is happening is hostile. I despise bad programming practices that make it harder to get actual work done from sloppy coders. If you had clue how key servers work then you might have point they work in round robin fashion ie. once you upload key to one key server all the severs in the group get updated once those scripts run that do the updating. In other words someone is playing at security when they have no clue how to do it that is dangerous in a project such as this where peoples money is at stake. And I am damn well going to point it out regardless of what anyone has to say about it. It is unappreciated people like this, why don't you help him and look at the script instead of just sitting there and laughing like an asshole. People like this are detrimental to all projects. I have no inclination to help any fool who cannot upload a gpg key and in case you did not notice asshole I have no access to that gpg to fix the problem anyways. And it is people like you that are the reason useless practices like this creep into a project always going on about how great it is that the useless practitioner is doing it for free don't point out any problems you uncouth swine how dare you... PLONK. Now I see why your ignore link is starting to change color. I'll help it along. The key is on a keyserver. It just isn't in his keychain or the keyserver he queried. I don't automatically add etotheipi's key to your keychain because the git verify-tag command does it automatically. I've queried a bunch of keyservers for this key and every one has worked but pgp.keyserver.com. You have to manually upload and verify your key with them. The key is definitely on keyserver.ubuntu.com gpg --recv-keys --keyserver keyserver.ubuntu.com 98832223
|
|
|
Dear Red Emerald, Thanks a lot for making this tap. It really makes it a lot easier - except that this time I run into a snag: $ brew upgrade ==> Upgrading 3 outdated packages, with result: armory-qt 0.86.3-beta, netpbm 10.60.05, sqlite 3.7.15 ==> Upgrading armory-qt ==> Cloning https://github.com/etotheipi/BitcoinArmory.git Updating /Library/Caches/Homebrew/armory-qt--git ==> Checking out tag v0.86.3-beta ==> Patching patching file ArmoryQt.command ==> git verify-tag v0.86.3-beta error: cannot run gpg: No such file or directory error: could not run gpg.
READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting
Note that I do have gpg installed, and can run it from the command line: $ gpg --version gpg (GnuPG/MacGPG2) 2.0.17 libgcrypt 1.4.6 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2
When brew installs things, I think it uses a modified PATH. Until we figure this out, you can install with the "--skip-verify" flag. $ echo $PATH /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin $ which gpg /usr/local/bin/gpg That thing has real problems if it cannot find /usr/local/bin ... try fixing it with this (as root or with sudo): ln -s /usr/local/bin/gpg /usr/bin/gpg i saw alot of scripts/binarys which call gpg directly with /usr/bin/gpg, so this may be the problem here Well that would probably do it. First they should just try updating the tap though, because it should be fixed without manually linking things. I am pretty sure git is not calling gpg with a fixed path. I'm pretty sure it's just that brew's superenv uses a minimal path to avoid breaking things.
|
|
|
Someone just asked me about how to run Armory over Tor. I realized that not only do I have no idea, but I've heard users claim they have done it, and I never paid attention. Can someone please explain how to do it? I will add the description to the webpage once I see a consensus.
I managed to get armory to connect to bitcoin-QT while on Tor by changing the default listening address in tor to 8333*, then simply running bitcoin-QT and Armory as usual. I believe the command --listenaddress** allows you to change the default listening address to 9050 so it will work with the normal Tor/bitcoin-QT settup, but I never got this to work. *Is this the right default SOCKS address for bitcoin-QT? **I'm not sure this is the right startup command can you confirm/correct this etotheipi? Hope this helps. I typed in a hurry so if detail are missing let me know. Port 8333 is the default listening port for Bitcoin-Qt. I am not familiar with proxies at all, and never really used any custom CLI options with Bitcoin-Qt. So I can't really comment any further on this. But if someone can give me a short list of what needs to be done to get Bitcoin-Qt-already-connected-to-tor, to play nice with Armory, I'll happily post it on my website. Also, Armory does a version check when it first opens, which can be disabled by going to "Help-->Armory Version..." and clicking "Never check for new versions". Someone complained about that. There's also an "online check" to determine if the user has an internet connection -- basically it just checks for google.com. That can be disabled via --skip-online-check on the CLI. I used to run bitcoin through tor as a hidden service. I'll experiment more and write up some nice steps. However, it should be really simple and nothing should really need to be done to armory since it uses bitcoind for all of it's networking anyway. The proper way to get bitcoin to use tor is to add "proxy=localhost:9050" (assuming tor is listening locally on the default port) to bitcoin.conf. No need to mess with tor's listen address. You will also need "listen=1" so it will be able to communicate locally with armory. When I had a tor hidden service running, I also had "discover=1" and "externalip=mylongstringofgibberish.onion" I'm not sure if those options will need tweaking for Armory. Then start armory with "--skip-online-check." It would be nice if there was also a flag for "--skip-version-check" to stop that from leaking.
|
|
|
Weird that it works for me. It's not a "real problem" considering it is documented Superenv removes /usr/local/bin from the PATH as well as all user-PATHs that are not determined to be essential to the build. It does this because other PATHs are full of stuff that breaks builds. We have 15,000 tickets to that testament.
I just made a change to the formula that will hopefully work for you guys. Try it out. Gee so because you document your breakage it is not a problem that is what a ./configure check is for you know that part where it says "Checking whether build environment is sane" or words to that meaning along with checking the versions required for the programs/libs used in building. There is no need to be hostile. Did the update work for you or not?
|
|
|
Weird that it works for me. It's not a "real problem" considering it is documented Superenv removes /usr/local/bin from the PATH as well as all user-PATHs that are not determined to be essential to the build. It does this because other PATHs are full of stuff that breaks builds. We have 15,000 tickets to that testament.
I just made a change to the formula that will hopefully work for you guys. Try it out.
|
|
|
Dear Red Emerald, Thanks a lot for making this tap. It really makes it a lot easier - except that this time I run into a snag: $ brew upgrade ==> Upgrading 3 outdated packages, with result: armory-qt 0.86.3-beta, netpbm 10.60.05, sqlite 3.7.15 ==> Upgrading armory-qt ==> Cloning https://github.com/etotheipi/BitcoinArmory.git Updating /Library/Caches/Homebrew/armory-qt--git ==> Checking out tag v0.86.3-beta ==> Patching patching file ArmoryQt.command ==> git verify-tag v0.86.3-beta error: cannot run gpg: No such file or directory error: could not run gpg.
READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting
Note that I do have gpg installed, and can run it from the command line: $ gpg --version gpg (GnuPG/MacGPG2) 2.0.17 libgcrypt 1.4.6 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2
When brew installs things, I think it uses a modified PATH. Until we figure this out, you can install with the "--skip-verify" "--without-gpg" flag.
|
|
|
Thanks for the thread. I'd seen most of this, but not all of it. The closest so far to a mass market solution, incorporates a display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred. Possibly transactions could be delivered over giant QR codes.
We (people hanging around #bitcoin-dev) also believe this device leaks it ECDSA private keys. Well that sounds bad.
|
|
|
I just checked out the 1.5.8 tag and it works fine if I run it with "./electrum" but when I run the copy installed with "setup.py install" I get an error
It looks like your install was not complete. did it throw an error? It looks like I somehow had 1.5.7 and 1.5.8 installed. I uninstalled 1.5.7 manually and reinstalled 1.5.8 and now its working!
|
|
|
I just checked out the 1.5.8 tag and it works fine if I run it with "./electrum" but when I run the copy installed with "setup.py install" I get an error $ electrum Traceback (most recent call last): File "/Users/bwstitt/.virtualenvs/electrum/bin/electrum", line 210, in <module> set_language(config.get('language')) NameError: name 'set_language' is not defined
|
|
|
|