|
Can you be more specific about where your build fails? Is it in the new code to support the -port / -rpcport options (which I should have put on a different git branch) ?
|
|
|
|
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. It's pretty common to turn maps into objects, so you can use syntax like: foo.tx_id ... instead of foo['tx_id']. Especially if you're doing something like passing the data into a templating system (which may ONLY understand the object.field syntax). And foo.class just doesn't work out nicely. |
|
|
|
I just updated my git "svn" branch with r116-119, and also merged it against 'master'. The git network diagram showing what I done did is kinda pretty. |
|
|
|
|
The good news is the TEST network is doing its job-- the problem patched by the 0.3.6 release (invalid transactions accepted as valid) was implemented and demonstrated on the TEST network.
The bad news is that means the TEST network block chain split yesterday. If you are, or were, running a release prior to 0.3.6 on the TEST network, you've got bad blocks in your blkindex.dat and blk0001.dat files.
So, you need to:
1. Shut down bitcoin or bitcoind
2. Remove the blkindex.dat and blk0001.dat (in ~/.bitcoinTEST or ~/Library/Application Support/BitcoinTEST or %APPDATA%\BitcoinTEST) files.
3. Be sure you're upgraded to 0.3.6
4. Run bitcoin/bitcoind, and you'll download the "good" block chain.
Any blocks you generated after the bad blocks are invalid, so if you were busily generating blocks on the TEST network in the last couple of days... sorry, that play money is gone.
Transactions that you made may or may not make it to the new block chain, depending on whether or not they originated from invalid coins (any coins generated after the bad blocks are invalid).
|
|
|
|
|
Speaking of the network...
... is there any really robust, generic, low-latency, open source p2p network "middleware" out there?
I think using protocol buffers as the serialization format is a good idea, but I don't think just switching to protocol buffers "buys" enough to be worth the effort (at least not now, when transaction volume is low).
I'd like to see some experimenting with running bitcoin on top of a different networking layer (and use protocol buffers, too). Is there a p2p network that is designed to be extremely highly reliable and difficult to infiltrate or attack with malicious nodes?
|
|
|
|
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. Or, maybe better, get rid of that field and just report credits as positive numbers and debits as negative. And add a separate "generated" field (boolean true or false). 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));
|
|
|
|
$ ./bitcoind -datadir=/home/theymos/bitcoin -conf=/home/theymos/bitcoin/bitcoin.conf && ./bitcoind getinfo error: You must set rpcpassword=<password> in the configuration file: That second ./bitcoind getinfo has to be: ./bitcoind -datadir=/home/theymos/bitcoin -conf=/home/theymos/bitcoin/bitcoin.conf getinfo ... otherwise it will use the default config file and datadir. |
|
|
|
If the market want credits, they will get it. Beside, bitcoins is already decentralized. What more decentralization do you want?
What the hell are you asking?
He/she/they want an easier way for The Crowd to control The Policy-- right now, if you know enough C++ to modify and compile your own version of Bitcoin and can convince enough other people to use your version, then you can change Policy. Allowing everybody to tweak Policy and having some sort of mechanism that figures out what "everybody" wants to do is an interesting idea. I have no idea how you could actually make it work, and it would open up a whole other can of potential security problems (what if somebody controls a bunch of IP addresses and decides to "vote" for a policy that benefits them? or can you tie the policy changes to proof-of-work somehow? How do you aggregate what "everybody" thinks in a non-spoofable way? etc etc etc)... |
|
|
|
I did a transaction about 2 hours ago and it is staying at 0/unconfirmed, the recipient has no credit showing or even an unconfirmed line... The coins seems to disapeared in the void...
Should I wait is this just a transaction that is going to take exceptionally long?
Are you still downloading the block chain? If you don't already have all 70,000+ blocks in the block chain, then you transaction won't show up as confirmed until you catch up. |
|
|
|
Was that the only thing I broke in the OSX build?! Does it actually work after just that one change?
I built a TEST-network bitcoind with the SVN r115 changes merged in, and yes, after that one change it's been happily generating coins all afternoon. I don't use the stock makefile.osx, though-- I setup the dependency directory structure a little differently (for no really good reason). |
|
|
|
|
If you include a double-spent transaction in a block you generate, then that block will be rejected and you don't get your 50BTC reward.
|
|
|
|
I get: /var/folders/n7/n7Do3Krz2RWPeE+1YxvhUU+++TM/-Tmp-//cc8PgHsQ.s:879:suffix or operands invalid for `call'
... compiling cryptopp/sha.cpp (latest SVN source) on my Mac (gcc version 4.2.1). I fixed it by adding -DCRYPTOPP_DISABLE_ASM to my makefile; perhaps somebody with more experience compiling C++ on a Mac can figure out a better fix. |
|
|
|
|
Does it work if you specify the full path? e.g. -datadir=/home/psyvenrix/datadir2 ?
|
|
|
|
the border?
1 hours 1 day? 1 week?
Before the last two difficulty adjustments it took my (4-year-old) mac laptop two weeks to generate any bitcoin. So after the adjustments, I estimate it could take it 1-2 months to generate any. |
|
|
|
I've been working on adding -port= / -rpcport= command line / config file options to bitcoin. The idea is to let you run multiple copies of bitcoind on one machine; I need this because I'm planning on having at least two Bitcoin-related web services (the Bitcoin Faucet and a service to be named later), I want them to have completely separate wallets, but I don't want to rent multiple servers to host them. Usage looks like this: $ ./bitcoind getbalance # The TEST network Faucet bitcoind
40616.66159265000
$ ./bitcoind -datadir=/home/bitcoin/.bitcoinTEST2 getbalance
1000.000000000000
$ cat /home/bitcoin/.bitcoinTEST2/bitcoin.conf
rpcpassword=.....
port=18666
rpcport=18665
Satoshi pointed out that allowing bitcoin/bitcoind to run on a non-standard port could be dangerous, because if misconfigured two bitcoins might both open and write to the same database. To prevent that, the <datadir>/db.log file is used as a lock so only one bitcoin can access the same datadir at a time (uses boost::interprocess::file_lock, which is purported to be cross-platform and well-behaved, even if bitcoin crashes). Issues that came up as I was doing this: I left a call to wxSingleInstanceChecker in the Windows GUI code, so no multiple-gui-bitcoins-listening-on-different-ports on Windows. I don't do Windows... I didn't bother making the error handling graceful if you point two bitcoins at the same datadir (you get a runtime exception "Cannot lock db.log, is bitcoin already running?"). Patches are at http://pastebin.com/2e4hfXSS; I've only tested on Linux so far, anybody willing to try this on Windows? |
|
|
|
Are you going to be working on a full client yourself?  I've been tempted... but no, I'm more interested in doing web-based Bitcoin apps, and extending the existing C++ implementation's JSON-RPC API is a whole lot less work than re-implementing the whole shebang. |
|
|
|
I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind ... inserts a newline every 64 characters Great catch! Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function: diff --git a/rpc.cpp b/rpc.cpp
index 72bdc50..703b757 100644
--- a/rpc.cpp
+++ b/rpc.cpp
@@ -765,13 +765,14 @@ string EncodeBase64(string s)
BUF_MEM *bptr;
b64 = BIO_new(BIO_f_base64());
+ BIO_set_flags(b64, BIO_FLAGS_BASE64_NO_NL);
bmem = BIO_new(BIO_s_mem());
b64 = BIO_push(b64, bmem);
BIO_write(b64, s.c_str(), s.size());
BIO_flush(b64);
BIO_get_mem_ptr(b64, &bptr);
- string result(bptr->data, bptr->length-1);
+ string result(bptr->data, bptr->length);
BIO_free_all(b64);
return result;
|
|
|
|
|
Well, at least do it on the TEST network FIRST!
If you manage to break the TEST network, it's a pretty good bet that you'll be able to break the production network. If it doesn't break the TEST network, then I'd say go ahead and run against the production network to look for "scaling up" problems.
|
|
|
|
Answering my own questions: Project using CMakeI looked at 'weechat'; they're migrating from gnu autotools to cmake (still support both, but recommend cmake). So another +1 for cmake. |
|
|
|
|
Is there something simpler than CMake that would work?
cmake-2.8.2.tar.gz - 5.1MB
cmake-2.8.2-Darwin-universal.dmg - 27.2 MB
Adding Yet Another Multi-Megabyte Dependency to build bitcoind seems like a backwards step to me.
What's the most popular build solution for other small-ish, successful open source projects?
|
|
|
|
|
Show Posts
