Everything looks fine right up until actually trying to build bitcoind. bitcoinrpc.cpp: In function âvoid RPCAcceptHandler(boost::shared_ptr<boost::asio::basic_socket_acceptor<Protocol, SocketAcceptorService> >, boost::asio::ssl::context&, bool, AcceptedConnection*, const boost::system::error_code&)â:
bitcoinrpc.cpp:2771: error: reference to âerrorâ is ambiguous
util.h:135: error: candidates are: bool error(const char*, ...)
/home/kjj2/Bitcoin/Deps/include/boost/asio/error.hpp:57: error: namespace boost::asio::error { }
make: *** [obj/bitcoinrpc.o] Error 1
To be honest, I have no idea here. I can't tell if this is because it is expecting a different version of boost, or if there was some syntax change in c++ between the version of gcc-g++ that ships with CentOS and the version that the devs use. Since the docs say any version of boost after 1.37 is fine, but make no mention of the c++ version (at least not that I've noticed), I'm thinking it is probably the second one. I'll grab a copy of bitcoin-master (0.6.99) and attempt to compile on a different box, and the beta 1.50 boost release. Maybe one of those will give me a clue of some sort. |
|
|
|
|
Sorry guys, I was very busy today and didn't have time to look at this. Actually, I still am, but for different reasons. I'll check this out as soon as I can, but that might end up being tomorrow morning instead of tonight.
|
|
|
|
You could always add a new block version number to exist alongside the current block version. There is no need for a hard fork, nor to break everything in one day.
Doing that requires a hard fork, as it means some blocks will be valid to new nodes but not to old. The first block mined in the new system will kick out every old node permanently on a sidechain without new-version blocks. Ahh, duh. My bad, it would require a fork. But not a fork that would break everything. Non-upgradable miners could keep making the blocks that they know how to make, while their control nodes would accept blocks from the network that were at the new version. |
|
|
|
|
You could always add a new block version number to exist alongside the current block version. There is no need for a hard fork, nor to break everything in one day.
|
|
|
|
Because the change looks very useful.
is still happen 2012-06-15 14:38:14.391000 Skipping from block 6b72058de518d5ba2687969e85a49054bed97dbe6d24b824aae to block 59a1df0c90c7fff4adf5e25ebf13b6b1f18b93bd8d73145c79c!
2012-06-15 14:38:15.654000 > ---> LOST CONTACT WITH BITCOIND for 1.0 minutes! Check that it isn't frozen or dead! <---
not as very often as last night, but reject level is too high Did you upgrade to 0.6.2? I've been getting TONS of these since I upgraded my p2pcoin nodes to 0.6.2. I just posted in dev/tech about the CPU usage in that release. Probably going to have to downgrade until it gets sorted out. |
|
|
|
Ever since I upgraded to 0.6.2, all of my CPUs have been pinned at 100% usage. Anyone else having similar problems? Here is a 11 year old Athlon XP 1800+ running 0.6.0: root@inana:~# ps waxuf | grep bitcoin
bitcoind 27316 0.5 20.5 200604 102428 ? SLsl 05:16 0:35 /usr/local/bin/bitcoind -conf=/etc/bitcoin/bitcoin.conf -pid=/etc/bitcoin/pid -daemon -datadir=/etc/bitcoin/ -noirc
And a modern Celeron G440 running 0.6.2: root@linuxcoin:/opt/logs# ps waxuf | grep bitcoind
root 27863 0.0 0.0 7740 836 pts/6 S+ 11:59 0:00 \_ grep bitcoind
root 3566 60.0 1.3 222240 106664 ? SLsl 01:44 369:33 /usr/bin/bitcoind -conf=/etc/bitcoin.conf -pid=/var/run/bitcoind.pid -daemon -datadir=/opt/bitram/
root 3567 0.0 0.0 3924 324 ? Ss 01:44 0:00 startpar -f -- bitcoind
Before the upgrade, the Celerons were quite snappy and responsive. Now, it can take several minutes (really!) to run a simple bitcoind getinfo. And it isn't an I/O problem, the Celerons are totally diskless, running entirely out of RAM, like they have been for the last few months. |
|
|
|
Thank you for your careful and considered estimation of the time it will take to implement a feature in my code, which I am almost certain you have never seen. I will treasure it always.
I understand your code may be complicated and it may take time to implement a change to payout methods, but, again, multisend is a very simple change. In any case, I would argue it is a very important change as well that should be very heavily prioritized. This is not trivial. Winnings are paid with transactions that redeem the bet that won them so that it can safely operate with zero confirmations. |
|
|
|
|
Pretty sure he is saying that our average block time is 10% too long, which is the same as saying that our average luck is ~90%.
|
|
|
|
On the command line, use the importprivkey command.
EDIT: Using this utility? or the bitcoind utility? bitcoind --help doesn't show any options for importing a private key.I'm not 100% prepared to use a 3rd party utility unless/until someone confirms it works with the latest official bitcoind client and an unencrypted wallet. In the standard client. Don't use --help, just use help. --help means you are asking about startup parameters. help means that you are asking about RPC calls / daemon commands. It really is just bitcoind importprivkey <WIF key> but you may need to play with quotes and escapes, depending on your system. The WIF key is the one labelled Privkey: in vanitygen's output, it starts with a 5. |
|
|
|
I am in the same boat.....trying to export private keys for use in blockchain.info wallet which says it will import the json dump file from pywallet.
The pywallet.py --dumpwallet was running and showing all of the data on screen. I could not find any exported .json file in either of the two Bitcoin locations on Windows. Also tried --datadir as well and didn't make a difference.
I'm not sure if this is why I'm having trouble but I did pywallet.py --dumpwallet >C:\myexp.json and it would generate everything in the format that is in the previous post with the output in a file.
When copying this text and pasting into the blockchain.info import screen it says it could not decode data. I am running the 0.6.2 client with the legacy wallet format.
Is it looking for a different format?
Read this thread and all others (that my search turned up), and still can't exactly figure out how to get my vanity addresses loaded into a Wallet. Even a Clean wallet. (Using the latest, patched official client). Basic steps? On the command line, use the importprivkey command. |
|
|
|
I'm now running two p2pools locally, on two different machines. I assume it's okay if both point to the same payout address? Or is that going to confuse the network?
Yup, that is fine. You may want to use different addresses to make it easier to track them, but you don't need to. |
|
|
|
Sorry for the long delay.
I've been running into some trouble.
First off all my successful boots into the program are for the "Default" option in the boot selection screen. I still get "Invalid or corrupt kernel image" for he p2pcoin option.
My first few attempts to let the system catch up to the latest namecoin block resulted in the LXTerminal notifying me that it lost connection to the server. When restarting the program I have to start the updating process over.
I ended up trying the newest 0.4v on another USB stick and this time caught up to the latest namecoin block then it began updating to the latest bitcoin block and it again ended up losing connection to the server.
I don't believe it is any issue with the network connection since throughout this whole process I can browse the internet just fine with Chromium.
Any ideas what may be going wrong?
Edit: I've also tested this on a few different machines with different hardware setups, they all end up with the same issue.
My turn to apologize for the delay. I've been out of town a lot over the last week or so. When it says it loses connection to the server, can you start a new terminal and see if bitcoind is still running? Even better, try 0.4.1. I think you may have been running out of memory. If that was the problem, 0.4.1 should fix it. |
|
|
|
|
0.4.1 is out. It includes the 0.11.2 p2pool release, as well as some improvements when setting up the RAM disks.
If you have persistent storage, you can run with as little as 2 GB RAM (maybe less, but I don't have anything smaller to test with). It will still try to use RAM for running bitcoind if you have at least 4 GB, and for namecoind if you have at least 6 GB.
If you have no persistent storage and are running entirely in RAM, you now need a bare minimum of 4 GB. With less than 4 GB, it will start the temporary miners and just leave them running. With 4 GB, it will start bitcoind and p2pool in RAM and run them. With 6 GB or more, it will also start namecoind for merged mining.
The TEMP_POOL and BACKUP_POOL options will now translate __CARD_ID__ into the Radeon ID # for each card when it starts phoenix, so you can configure different workers for each card, if you want to.
|
|
|
|
|
I got it working. You need a library for EC math and the curve definition for SEC p256k1.
You generate the private key yourself, and converting it to a WIF is pretty simple. To get the public key, you multiply G (the generator from the p256k1 curve) by the private key. From there, creating an address is simple too.
I'm using the LGPL ECC library from Matyas Danter, but it took some effort.
|
|
|
|
If luck is the explanation of the frequency of block discovery, then we are discovering 10% below what is possible on average. The below average discovery rate could indicate resource diversion, which has already been shown publicly to occur. You could say that "Luck" is how to explain away resource diversion.
However, P2Pool is open source - there's no closed server that could be secretly diverting hashes. Please, do audit the source. It's either a bug somewhere (which I've been trying like mad to find) or just really bad luck. Regardless, its still worth it to mine with P2Pool! +1 10% is totally worth it. Don't care if it is a bug, a security problem, bad luck, the phase of Ivpeter, "ghosts", whatever. My post history will show that I started with btc guild in their very early days, and that I have nothing but good things to say about E. My default distribution of p2pcoin even uses btc guild for backup. But p2pool is just plain healthier for bitcoin, in the long run. And I care more about bitcoin today and tomorrow than I care about the balance in my wallet. |
|
|
|
Don't take this the wrong way, but you did get this "minute detail about one of the simpler aspects" wrong.
Sorry, but no, I didn't get anything wrong. I failed to communicate an idea clearly, which I would have spent more effort avoiding if it referred to anything important. It seems like we are unlikely to come to an agreement on the importance of the subsidy calculation. I maintain that it is very important, and that it should be exact and simple, barring a very good reason to be otherwise. "Right shift by 1 bit" is not the same operation as "divide by two and round down". They obtain the same result if done properly, but have different meta costs, as you helped me demonstrate.
I don't understand. Bit-shift may take less CPU time but it's much more difficult conceptually. The actual operation being done is division by 2 and rounding down, bit-shift is the specific code used to do it. As someone that knows a little bit about CPUs and digital logic, I can promise you that the right shift operation is not done by divide-and-round, it is done in dedicated hardware called a shifter that literally shifts bits. It might be harder for laymen to understand, but programmers (and CPUs) understand shift very literally. P.S. Read the bold part again. Warning bells should be going off as you do.
Not really. If I were able to predict what the market would do I'd be rich. I just want it to have the tools to find what's most efficient for it, and that's easier to demonstrate. It is relatively simple to show that 5 seconds between blocks is too short, and that 3600 seconds between blocks is too long. It is much harder to show that 590 or 610 seconds is better than 600, or that 300 or 900 are better than 600. As you say, it is hard to predict what this system will look like once it gets rolling. Will we be trading one non-optimal block average for a different non-optimal average? Will we be making a system that cycles or floats through a range of values, each just as non-optimal as the others? How can we tell a "good" state from a "bad" state? It's all about the incentive structure. If we can find a system that allows the people for whom the value actually matters to vote with their feet, we should come up with something good. Usually I make these points in threads about moving the decimal point, but they really apply to all of the magic numbers. Why 10 minutes? Why 2 weeks? Why 210,000 blocks? The answer is always the same, because they are "good enough" and it is really hard to show that any different numbers would be any better.
I suspect that the same applies here. It seems to me that it is just as hard to show that a dynamic system is any better for this job, and it doesn't just have to be any better, it has to be better enough to pay for the extra complexity costs.
Some magic numbers are more important than others. 21M total bitcoins is unimportant, 100M units per bitcoin is unimportant. 2 weeks is somewhat important. 4 years and 10 minutes are quite important. We can't change 4 years for Bitcoin itself, but maybe we can change 10 minutes. I agree completely that it is hard to deduce that one value is better than another, but I don't think it's as hard to show that a certain system has the incentives to find an optimal value properly aligned. Also, even if the dynamic system can't be trusted to be robust, the proposal gives a framework for changing the static block time, if there is ever a consensus that it should be changed. I think that this is the part that needs the most work. Miners will seek to maximize things based on whatever incentive scheme we come up with. We need to show that there is a problem (or at least a sub-optimal condition) and that this change fixes (or at least improves) it. I agree with you that 600 seconds forever is very unlikely to be optimal. But is dynamic actually any better? If we make it dynamic, and set up a system that adjusts based on the desires of miners, and miners adjust things to their liking, is that evidence that the new value is better? Or is it just evidence that the miners are gaming the incentive? And how do we measure better-ness anyway? |
|
|
|
However, if this thread is talking about multiple people eventually seeing the same key, then it makes sense for one user to keep the key around around, monitoring the network for when it receives more funds and sweeping it right away. In fact, if this is done, I'll be setting up a daemon to do just that... Might make the whole thing kind of useless. But maybe I don't understand the application.
Just because a key is intended for a single use doesn't mean that it will only be used one time. If someone gives me a key, I'll want to sweep it immediately because I don't trust it. But I'll also want to watch it forever and attempt to sweep anything that ever gets sent to it in the future, because I might get lucky. But I don't want to treat it like a normal key that accumulates transactions because I don't trust it. And of all the one-time-use keys that are ever distributed to all the people that ever receive them. How often do you expect such a key to be magically refilled? Who is refilling it? Do people like throwing money away? What purpose could possibly be served by sending money to a completely-insecure key after it's been used once? In reality, I'd have to spend time to complicate my interface to add an "untrusted keys" feature, and it would be absolutely useless. If you really want to do this anyway, just create a new wallet, label it "INSECURE" and put such keys in there. Then I don't have to add anything to my interface. P.S. -- I've pondered some kind of auto-sweep setting for certain addresses, but that doesn't work with encrypted wallets, and even for unencrypted wallets, I've never been comfortable with moving money in any of the users' wallets when they aren't looking, no matter how benevolent my intentions are. I totally agree about the single use keys. No one is going to refill them. But that doesn't mean that I want to abandon them. No need to do anything with the UI. Just remember keys imported for sweeping instead of deleting them, and check them again from time to time, or as you do with regular keys (which I presume is as blocks come in). Very low priority feature. But it actually looks pretty simple to do. Add a flag to whatever you are using to store imported keys now. If someone picks the sweep option on import, store it with that flag set. When you are checking the imported keys for new transactions, if that flag is set, call out to the sweep code. |
|
|
|
However, if this thread is talking about multiple people eventually seeing the same key, then it makes sense for one user to keep the key around around, monitoring the network for when it receives more funds and sweeping it right away. In fact, if this is done, I'll be setting up a daemon to do just that... Might make the whole thing kind of useless. But maybe I don't understand the application.
Just because a key is intended for a single use doesn't mean that it will only be used one time. If someone gives me a key, I'll want to sweep it immediately because I don't trust it. But I'll also want to watch it forever and attempt to sweep anything that ever gets sent to it in the future, because I might get lucky. But I don't want to treat it like a normal key that accumulates transactions because I don't trust it. |
|
|
|
I thought I had made my point pretty well. You are proposing to replace something that is really simple, always exact, and impossible to mess up with something that has none of those properties. People will get it wrong.
The current block reward calculation isn't any more exact than what I propose - when the block reward is halved, the amount of satoshis is rounded down. It's hard for you to make a case about simplicity taking as an example a minute detail about one of the simpler aspects. If multiplying two numbers gives us troubles, I worry. Don't take this the wrong way, but you did get this "minute detail about one of the simpler aspects" wrong. This is an extreme example, one that I often choose because it is so trivial and so simple, and still so easy to get wrong. (See my posts in various other threads with proposals to change up the subsidy calculation.) "Right shift by 1 bit" is not the same operation as "divide by two and round down". They obtain the same result if done properly, but have different meta costs, as you helped me demonstrate. That extra cost should not be paid (now and for eternity) without good reason. The bitcoin software is chock full of things far more complicated than this, so clearly we can get this detail right too. But should we? Do you get what I'm trying to say? P.S. Read the bold part again. Warning bells should be going off as you do.
Not really. If I were able to predict what the market would do I'd be rich. I just want it to have the tools to find what's most efficient for it, and that's easier to demonstrate. It is relatively simple to show that 5 seconds between blocks is too short, and that 3600 seconds between blocks is too long. It is much harder to show that 590 or 610 seconds is better than 600, or that 300 or 900 are better than 600. As you say, it is hard to predict what this system will look like once it gets rolling. Will we be trading one non-optimal block average for a different non-optimal average? Will we be making a system that cycles or floats through a range of values, each just as non-optimal as the others? How can we tell a "good" state from a "bad" state? Usually I make these points in threads about moving the decimal point, but they really apply to all of the magic numbers. Why 10 minutes? Why 2 weeks? Why 210,000 blocks? The answer is always the same, because they are "good enough" and it is really hard to show that any different numbers would be any better. I suspect that the same applies here. It seems to me that it is just as hard to show that a dynamic system is any better for this job, and it doesn't just have to be any better, it has to be better enough to pay for the extra complexity costs. All that said, unless you want to discuss these things further, I'm willing to bow out here and let you get this thread back on track so that you can finish presenting your idea. I really would like to see the rest of it. |
|
|
|
Oh, but did you notice that you changed your scheme already? From "round to nearest" to "round down". One of those was probably just a silly mistake, the sort that happens to everyone from time to time. Simplicity has a value that is hard to quantify.
Are we really arguing semantics now? When I said "round to nearest" I meant "round to the nearest integer smaller than the value or equal to it", and I thought it was clear that I'm referring to normal integer division (which rounds down). I'm not as precise in my language in conversation as in formal proposals. And, with any other rounding method, there's still very little to game. I said it's "immaterial" which implies I couldn't care less how it's rounded, or how people would interpret how I say it's rounded. Energies are better saved for important things. I thought I had made my point pretty well. You are proposing to replace something that is really simple, always exact, and impossible to mess up with something that has none of those properties. People will get it wrong. I'm not saying that anyone should reject the proposal simply because of this, but it should give you pause. Also, I'm pretty sure that your idea will create total chaos. Not less forks, but more. Lots more. Like on nearly every block. Not at first, necessarily, but as the subsidy shrinks relative to the transaction fees for sure.
Did I say it will create less forks? I predict that the equilibrium found will be less than 10 minutes, which means more forks. I doubt it will be "on nearly every block". As I explained, if it comes to that, miners will choose a larger weight which decreases their invalid rate. Actually, miners will choose the weight based on whether they got the last block or not, and whether they are getting paid kickbacks to support/override blocks from the previous miner. For most miners, I think the best payoff would be prevDifficulty+1, except when they are working on extending their own block, in which case it would be the minimum, or close to it. The exact game theory optimum would depend the acceptable range. As I said, honest miners will build on the longest (most difficult) branch they know. This is a Nash equilibrium - a miner will want to build on the longest branch, as that improves the chances that their own block will be accepted. Increasing the weight decreases the probability that their block will be rejected in a conflict. You sure about that? No one will ever want to ignore an easy block and try to replace it with their own hard block? I didn't talk yet about how to handle transaction fees, so you may want to defer judgement until then. Hint: You won't be able to get the entire fee of all floating transactions by creating a very light block.
Oh? Option 1. You pay "easy" blocks less and put the balance into a fund used to pay extra for "hard" blocks. Equilibrium at 10 minutes, which is what you wanted to avoid. Option 2. You pay "easy" blocks less, and the remainder carries into the next block. Equilibrium at X minutes, which is no more optimal than 10 was. Option 3. You pay "easy" blocks less, and the remainder is lost. Equilibrium at 10 minutes. Option 4. You pay "easy" blocks less, and "hard" blocks more, creating money out of thin air. Equilibrium at whatever the weight cap is. Did I miss any? Options 1 and 2 aren't that far off. But seriously, hypothesizing what the equilibrium will be is hard enough when the system is fully specified, trying to deduce it based on guesses on what I want to propose is just silly. I would appreciate the benefit of the doubt that what I want to propose is not totally idiotic and broken. Don't take it personally. Lots of people propose changes that fix things that aren't problems, or that don't fix an actual problem, or that create too many new problems. I have no idea if your proposal fits one of those three categories, or if it actually fixes something that is actually a problem and doesn't create a whole new mess. I find out by poking at the edges. P.S. Read the bold part again. Warning bells should be going off as you do. |
|
|
|
|
Show Posts
