I feel very unlucky. My system has been cranking out 2600 khash/sec for more than 16 days so far, and still not a single block generated. I am not going to buy a lottery ticket any time soon.
I have a feeling that GPU (OpenCL) users will rapidly crowd out CPU users, due to the apparent large advantage of OpenCL bitcoin generation on modern GPUs. |
|
|
|
It seems like a lot of people out there are using git to follow the bitcoin SVN repo, and some are having trouble with line endings. Here is the method of creating a local git repository, containing nothing but satoshi's upstream SVN commits: $ git svn clone --stdlayout https://bitcoin.svn.sourceforge.net/svnroot/bitcoin
When satoshi updates his SVN, here is the method for updating your local repository: $ git svn fetch && git pull . refs/remotes/trunk
It is advisable to maintain a vanilla repository or branch, and do your work in a separate repo, such as $ git clone bitcoin bitcoin.jg-hacks
or create a side branch, $ cd bitcoin
$ git checkout -b jg-hacks master
|
|
|
|
hmm...I wasn't able to apply the patch (I'm a noobie). Here's the command I ran from bitcoin-0.3.6/src # patch < XN1JDb53.txt
Output:
1 out of 1 hunk ignored
(Stripping trailing CRs from patch.)
patching file main.cpp
Hunk #1 FAILED at 2555.
Hunk #2 FAILED at 2701.
2 out of 2 hunks FAILED
(Stripping trailing CRs from patch.)
patching file makefile.unix
Hunk #1 FAILED at 45.
Hunk #2 FAILED at 58.
It definitely does not apply to the SVN trunk. Maybe tcatm could post the main.cpp itself? |
|
|
|
I get this when trying to run bitcoin:
[michael@fed13 64]$ ./bitcoin
./bitcoin: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
Fedora 13 uses this:
/lib64/libcrypto.so.1.0.0a
How can I get around this?
I tried a symlink and running ldd and ldconfig to no avail.
Thanks
No its a breaking DSO major version change. The problem with Fedora is that it cuts backward compatibility ASAP, where as for RHEL/CentOS there would be compat-openssl providing the libraries you need. That is irrelevant to building. bitcoin requires ECDSA, which Fedora will not include due to patent issues. A custom openssl build is a requirement on Fedora, in order to build bitcoin. |
|
|
|
It would be very easy to latch onto that for watching for received payments. There is no reliable way to do it that way and make sure nothing can slip through the cracks. Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say "use this! use this! don't use listtransactions!", I don't think we should implement listtransactions.
Can you be more specific about "no reliable way"? The existing facility getreceivedby* is provably unreliable. It combines transactions into summarized totals. When you go to the bank ATM and perform two deposits, the second immediately following the first, you do not see "ATM deposit $80" on your bank statement, you see two transactions with different transaction IDs for "ATM deposit $40". I am missing something here? listtransaction seems more reliable than getreceivedby* summaries. |
|
|
|
If Satoshi use git it would be good! In git convenient to work with digital signatures, and all authors will not have to think about it further.
Strongly agreed. git is decentralized, unlike SVN. You don't have to hit the server each time you want a file or revision history. git is quite like bitcoin in fact: sha1-hashed commits reference past sha1-hashed commits, creating a chain of trust that is trivial to validate, and difficult to hack. |
|
|
|
Couple of quick suggestions:
Using the key name "class" will cause problems for, at least, JavaScript, and probably other languages where "class" is a reserved word. "type" or "variety" or some other synonym will cause fewer problems later.
Can you be more specific? All mainstream programming language seem sensibly insensitive to abitrary string contents, JS included. String content can certainly include language-reserved keywords and parsing tokens. Since each entry refers to a transaction, I'd suggest adding a "tx_id" SHA256 hex-encoded transaction id. Then listtransactions would play nicely with the refundtransaction JSON-RPC extension (and maybe a future gettransactiondetails that let you get transaction parents, which block the transaction was in, and so on). Code to get that would look something like: uint256 tx_hash = transaction.GetHash();
string tx_id = tx_hash.GetHex();
mapJSONResponse.push_back(Pair("tx_id", tx_id));
Added, thanks for the suggestion. |
|
|
|
Now that the JSON-RPC server is secured by a username and password (although not encrypted), I would really like the option of being able to bind bitcoind to another IP and/or port. For example, I have a handful of nodes that all have a public interface and a local interface. I would like to be able to bind bitcoind to an IP on my internal interface so that I can monitor and manage the node from one server.
Really, it should bind to *, and then filter out requests from addresses other than those on a filter-list. |
|
|
|
|
Has anyone yet created a 100% vanilla mirror of bitcoin SVN, using git?
Looking for one that does not have any mods from vanilla bitcoin, and will never have any mods deviating from vanilla bitcoin.
Thanks.
|
|
|
|
|
FYI, it is pointless to make a packet smaller than 60 bytes -- the minimum size of an Ethernet packet. Packets are padded up to 60 bytes, if they are smaller.
|
|
|
|
I know I've seen this topic a half-dozen times (can't compile), but after spending hours hunting down source and compiling every piece of software listed in the build-unix.txt, correcting path errors in the build files, etc. I still can't get the program compiled, LOL. The error it hangs at is: /usr/bin/ld: cannot find -lboost_system
collect2: ld returned 1 exit status
make: *** [bitcoin] Error 1
A bit tough to elaborate on, since I don't see your Linux OS version. For some OS's, like Fedora here, you need to link with the multi-threaded boost libs instead. This implies adding a "-mt" suffix, eg. -lboost_system-mt rather than -lboost_system, for example. Here is the complete, makefile-free, working solution I use to build bitcoind on Fedora: g++ -O3 -ffast-math -march=native -Wno-invalid-offsetof -Wformat -pthread \
-I"/usr/local/openssl-0.9.8/include" \
-o bitcoind \
rpc.cpp main.cpp util.cpp script.cpp db.cpp net.cpp irc.cpp \
init.cpp cryptopp/sha.cpp cryptopp/cpu.cpp \
-L"/usr/local/openssl-0.9.8/lib" \
-l boost_system-mt -l boost_filesystem-mt -l boost_program_options-mt \
-l boost_thread-mt -l db_cxx -l crypto -l gthread-2.0
(openssl 0.9.8 is installed in /usr/local/openssl-0.9.8, everything else is a system lib) |
|
|
|
What if you had as many wallets as you had bitcoins so that there is only 1 bitcoin in each ?At the moment there is 1 wallet file that would be relatively easy to find on someone's system.Having only 1 unencrypted file that holds your wealth is a vulnerability.Having 1000 files each needing a different pgp key to open would be a nice security feature.
Sounds like a maintenance and management headache. Nobody will want to remember 1000 different passwords, or manage 1000 different keys all over the place, so that just moves the problem from one location (wallet) to another (key management and automation). |
|
|
|
If you create a new address each time you transact you will eventually end up with thousands of addresses in your client.The question is how can you easily search for one particular transaction amongst thousands?
It would be nice to be able to add a memo to each transaction, something both sender and receiver could view. |
|
|
|
Is a client device possible with your server/desktop sitting at home which you could vpn into?
Sure. That's reinventing the client terminal, a dumb hardware device that communicates with a backend payment system. |
|
|
|
Several RPC commands have multi-line help descriptions, but they do not appear to be shown anywhere. The following patch implements a parameter that provides access to these extended descriptions. Patch: http://pastebin.ca/1911586Raw: http://pastebin.ca/raw/1911586Here is example output for the new "help listreceivedbyaddress" sub-command: [jgarzik@bd ~]$ /garz/repo/bitcoin/bitcoind -datadir=/garz/bitcoin/data help listreceivedbyaddress
listreceivedbyaddress [minconf=1] [includeempty=false]
[minconf] is the minimum number of confirmations before payments are included.
[includeempty] whether to include addresses that haven't received any payments.
Returns an array of objects containing:
"address" : receiving address
"label" : the label of the receiving address
"amount" : total amount received by the address
"confirmations" : number of confirmations of the most recent transaction included
|
|
|
|
Version 6 of listtransactions: http://pastebin.ca/1911570Raw patch: http://pastebin.ca/raw/1911570listtransactions implementation should be complete at this point. The following command syntax is used: listtransactions [count=10] [minconf=1] [includegenerated=true] As lachesis suggested, count=0 will dump all transactions. FAQ: Q1) How does 'listtransactions' behave if tail of the block chain changes, eg. 0 confirmations -> 1 confirmation -> 0 confirmations? A1) 'listtransactions' behaves the same way 'listreceivedbyaddress' behaves... the output changes accordingly. |
|
|
|
Yeah, some sort of virtual machine like qemu/KVM is really the best way to go, for older distro support. Just to clear up any (potential) misconception, from the use of the phrase "for older distro support". Just because you compiled your application with an older distro doesn't mean it doesn't work on a newer distro many libraries are backwardly compatible in that way. When they do change major DSO version (incompatible or breaking changes) some distributions still provide the ability to install the older compat libraries. Its easier for a new distro to find older compat libraries than it is for an older distro to use a newer GLIBC. Most of what you say is true, but, bitcoin tends to be built against very specific versions of its dependent libs. Due to that, one tends to build bitcoin against custom compiled libs, regardless of underlying OS version. That practice makes glibc the primary compatibility worry. |
|
|
|
|
Show Posts
