Funny and yet informative. I enjoyed this a lot. EDIT: Just to warn everyone. There are furries. |
|
|
|
MC Frontalot - Secrets from the Future You can’t hide secrets from the future with math.
You can try, but I bet that in the future they laugh
at the half-assed schemes and algorithms amassed
to enforce cryptographs in the past.
|
|
|
|
|
I'm setting up an electrum server right now. I plan on also running it with a tor hidden service just for fun.
Built a VM with 4GB of RAM and 4 cores of an Intel Xeon X5355 @ 2.66GHz. We'll see how long abe takes to run. 6 minutes got it to about "block_tx 822 840"
So far there have been lots of steps, but ovidiusoft's guide has helped a lot. It doesn't mention anything about dependencies, but those will vary from system to system so thats okay.
|
|
|
|
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
I disagree. I think planning ahead always leads to better software even if the software development may be slower to start. Better to find a problem in your proposal and rewrite that than to discover a problem in your code and redo a ton of work there IMO Proposals are especially important when multiple people are working on a project as it makes it easier to work on different parts of the project at once. You're advocating the ancient waterfall method which is basically out of fashion since the last decade. genjix:~$ python
Python 2.7.2+ (default, Oct 4 2011, 20:03:08)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
You are emphasizing the first bolded point while I am emphasizing the second. I'm not trying to say, "don't start ANY code until you have the proposal 100% complete and vetted by every major dev." I'm saying that we should have a basic roadmap worked out about what we are coding so that we actually know where are going. And I most definitely stand behind my second point. Proposals are especially important when multiple people are working on a project as it makes it easier to work on different parts of the project at once.
How are multiple people supposed to work on something when no one knows were we are trying to go? EDIT: reread your post. I had missed the "code up an implementation" and thought you wanted to code with no roadmap. |
|
|
|
A 6950 nets you 0.444921875 Gallons of maple syrup a month,
or 1.79370079 pairs of socks a month
Oh lol. Thats almost sig-able |
|
|
|
The thing is not to get too caught up writing long proposals and documents. Think a little bit, code up an implementation, get rolling and refine your requirements as they become obvious. It's easier to ask for forgiveness than to ask for permission.
I disagree. I think planning ahead always leads to better software even if the software development may be slower to start. Better to find a problem in your proposal and rewrite that than to discover a problem in your code and redo a ton of work there IMO Proposals are especially important when multiple people are working on a project as it makes it easier to work on different parts of the project at once. |
|
|
|
Stupid question alert! I'm not good with Linux. At all. How do I go about updating bitcoin to 0.5.1 in this installation? Thanks  If you aren't good with linux. Wait until rb1205 comes out with a new IMG for you to use. That, or start learning  |
|
|
|
|
I just got a kindle. Loading strongcoin.com works although the browser is slow.
|
|
|
|
Disclaimer: I'm a Tor newbie and networking stuff isn't my strong suit, you probably know more about it than I do.
But: I fixed a Tor-related bug for version 0.6 a few days ago. In particular, I moved all of the "turn this on or turn this off if running over Tor" to one spot (in the init.cpp file) and reworked the code so that you can override all of those decisions via command-line or bitcoin.conf switches (e.g. specify -nolisten=0 to set nolisten to false so you DO listen even if running a port 9050 proxy).
Great. I'll be sure to test 0.6 with a proxy set and a tor hidden service sometime soon. |
|
|
|
|
I've added all of the tor fallback nodes to my torrc with mapaddress and I only connect to 1. I'm pretty sure that my hidden service is the only one still online.
|
|
|
|
|
Whenever I see walls of text like this, I expect it to end with "my mom got scared, and said, 'You're movin' with your auntie and uncle in Bel-Air.'"
EDIT: I don't mean to say that I'm not sorry about your house.
|
|
|
|
|
We should have a network wide drill. See how many sites handle the error messages. I bet none.
|
|
|
|
Some people are asking me why I don't just extend Bitcoin protocol. I think both things are solving another problems. Bitcoin P2P network is distributed database, it's storing blockchain and handling transactions. My proposal is more about services on top of this database and I don't think they can be provided purely thru p2p network. Also, I don't think that bitcoin p2p network should care about such "services" like distributing USD/BTC price or similar.
I fully agree with you. I think building services on top of bitcoin is much smarter than changing the bitcoin protocol. |
|
|
|
[2011-12-27 14:19:26] Started cgminer 2.1.0
[2011-12-27 14:19:42] Pool 32 slow/down or URL or credentials invalid
[2011-12-27 14:19:42] Long-polling activated for http://us.eclipsemc.com:9009/LP
[2011-12-27 14:19:50] Accepted 00000000.65d7e293.179988b8 GPU 4 thread 4 pool 0
...
As noted yesterday I'm consistently seeing a pool-problem message at startup. My request to have the problem pool identified was granted -- thank you! Alas, now I don't know what the ID means: 32? I have three pools specified in my config. At least 32 is a power of two, which is always comforting. Can you post your cgminer config? |
|
|
|
|
Following.
I am very interested in Electrum/thin clients and have the bandwidth/hardware to run a supernode so am willing to test.
|
|
|
|
2.0.9 was a development version number only, and yes the minor version upgrade (as opposed to micro version) signifies the feature upgrade to the RPC API.
If you pulled from git and are still getting version 2.0.9 it's because you didn't do ./autogen.sh
You are right, I forgot autogen. cgminer version 2.1.0 - Started: [2011-12-27 21:48:54]
--------------------------------------------------------------------------------
(5s):1062.4 (avg):1024.2 Mh/s | Q:13 A:10 R:0 HW:0 E:77% U:16.64/m
TQ: 4 ST: 4 SS: 0 DW: 0 NB: 1 LW: 0 GF: 0 RF: 0
Connected to http://goat1.zapto.org:8337 with LP as user redemerald
Block: 0000038dfc371bb0c6265496d428503a... Started: [21:48:37]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 72.0C 4223RPM | 382.2/416.4Mh/s | A:3 R:0 HW:0 U:4.99/m I:8
GPU 1: 68.5C | 379.2/404.3Mh/s | A:5 R:0 HW:0 U:8.32/m I:7
GPU 2: 53.5C 3265RPM | 321.8/339.1Mh/s | A:3 R:0 HW:0 U:4.99/m I:8
--------------------------------------------------------------------------------
When I quit, I get a segmentation fault. It seems to run fine though. |
|
|
|
|
It should be fine to start and stop the process. Just like mining, previous hashes have no effect on later hashes. Even if you manually set the seed, then you still don't get the same hashes. Your calculations for time to solve will be less accurate, but the probability to find the key is the same no matter how many times you have already tried.
EDIT: See the link from deepceleron below
|
|
|
|
I just want to see the IPs that bitcoin is talking to.
Look up the `netstat` command. You can use a (platform-dependent) switch to see which connections are associated with which processes. Good idea. I'll play around with that. I did get my tor relay working last night, though! It did have to do with bitcoin being to dumb to use the remote DNS. I've updated the wiki to explain how to properly do it. |
|
|
|
|
Show Posts
