qa.json

[
	{
		"id": 1,
		"type": "gpt-4",
		"date": "2008-10-31 18:10:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html",
		"q": "What are the main properties of Bitcoin?",
		"a": "Double-spending is prevented with a peer-to-peer network. No mint or other trusted parties. Participants can be anonymous. New coins are made from Hashcash style proof-of-work. The proof-of-work for new coin generation also powers the network to prevent double-spending."
	},
	{
		"id": 2,
		"type": "gpt-4",
		"date": "2008-10-31 18:10:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html",
		"q": "Why aren't digital signatures enough for a payment network?",
		"a": "Digital signatures provide part of the solution, but the main benefits are lost if a trusted party is still required to prevent double-spending."
	},
	{
		"id": 3,
		"type": "gpt-4",
		"date": "2008-10-31 18:10:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html",
		"q": "What function does the network perform in terms of transactions?",
		"a": "The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work."
	},
	{
		"id": 4,
		"type": "gpt-4",
		"date": "2008-10-31 18:10:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html",
		"q": "How does the control of hashing power affect the security of the network?",
		"a": "As long as honest nodes control the most CPU power on the network, they can generate the longest chain and outpace any attackers."
	},
	{
		"id": 5,
		"type": "gpt-4",
		"date": "2008-10-31 18:10:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html",
		"q": "How does message broadcasting work in this system?",
		"a": "Messages are broadcasted on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone."
	},
	{
		"id": 6,
		"type": "favorite",
		"date": "2008-11-03 01:37:43",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html",
		"q": "We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size.\n\nFor transferable proof of work tokens to have value, they must have monetary value. To have monetary value, they must be transferred within a very large network - for example a file trading network akin to bittorrent.\n\nTo detect and reject a double spending event in a timely manner, one must have most past transactions of the coins in the transaction, which, naively implemented, requires each peer to have most past transactions, or most past transactions that occurred recently. If hundreds of millions of people are doing transactions, that is a lot of bandwidth - each must know all, or a substantial part thereof.",
		"a": "Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.\n\nThe bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.\n\nIf the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal."
	},
	{
		"id": 7,
		"type": "favorite",
		"date": "2008-11-03 16:23:49",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014818.html",
		"q": "But they don't. Bad guys routinely control zombie farms of 100,000 machines or more. People I know who run a blacklist of spam sending zombies tell me they often see a million new zombies a day.\n\nThis is the same reason that hashcash can't work on today's Internet -- the good guys have vastly less computational firepower than the bad guys.",
		"a": "Thanks for bringing up that point.\n\nI didn't really make that statement as strong as I could have. The requirement is that the good guys collectively have more CPU power than any single attacker.\n\nThere would be many smaller zombie farms that are not big enough to overpower the network, and they could still make money by generating bitcoins. The smaller farms are then the \"honest nodes\". (I need a better term than \"honest\") The more smaller farms resort to generating bitcoins, the higher the bar gets to overpower the network, making larger farms also too small to overpower it so that they may as well generate bitcoins too. According to the \"long tail\" theory, the small, medium and merely large farms put together should add up to a lot more than the biggest zombie farm.\n\nEven if a bad guy does overpower the network, it's not like he's instantly rich. All he can accomplish is to take back money he himself spent, like bouncing a check. To exploit it, he would have to buy something from a merchant, wait till it ships, then overpower the network and try to take his money back. I don't think he could make as much money trying to pull a carding scheme like that as he could by generating bitcoins. With a zombie farm that big, he could generate more bitcoins than everyone else combined.\n\nThe Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead."
	},
	{
		"id": 8,
		"type": "favorite",
		"date": "2008-11-06 20:15:40",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014823.html",
		"q": "[Lengthy exposition of vulnerability of a systm to use-of-force monopolies ellided.]\n\nYou will not find a solution to political problems in cryptography.",
		"a": "Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.\n\nGovernments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own."
	},
	{
		"id": 9,
		"type": "favorite",
		"date": "2008-11-08 18:54:38",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014831.html",
		"q": "the \"currency\" is inflationary at about 35% as that's how much faster computers get annually ... the inflation rate of 35% is almost guaranteed by the technology",
		"a": "Increasing hardware speed is handled: \"To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases.\" As computers get faster and the total computing power applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future.\n\nThe fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase.\n\nCoins have to get initially distributed somehow, and a constant rate seems like the best formula."
	},
	{
		"id": 10,
		"type": "favorite",
		"date": "2008-11-09 01:58:48",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html",
		"q": "it is mentioned that if a broadcast transaction does not reach all nodes, it is OK, as it will get into the block chain before long. How does this happen - what if the node that creates the \"next\" block (the first node to find the hashcash collision) did not hear about the transaction, and then a few more blocks get added also by nodes that did not hear about that transaction? Do all the nodes that did hear it keep that transaction around, hoping to incorporate it into a block once they get lucky enough to be the one which finds the next collision?",
		"a": "Right, nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it."
	},
	{
		"id": 11,
		"type": "favorite",
		"date": "2008-11-09 01:58:48",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html",
		"q": "Or for example, what if a node is keeping two or more chains around as it waits to see which grows fastest, and a block comes in for chain A which would include a double-spend of a coin that is in chain B? Is that checked for or not? (This might happen if someone double-spent and two different sets of nodes heard about the two different transactions with the same coin.)",
		"a": "That does not need to be checked for. The transaction in whichever branch ends up getting ahead becomes the valid one, the other is invalid. If someone tries to double spend like that, one and only one spend will always become valid, the others invalid.\n\nReceivers of transactions will normally need to hold transactions for perhaps an hour or more to allow time for this kind of possibility to be resolved. They can still re-spend the coins immediately, but they should wait before taking an action such as shipping goods."
	},
	{
		"id": 12,
		"type": "favorite",
		"date": "2008-11-09 01:58:48",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html",
		"q": "I also don't understand exactly how double-spending, or cancelling transactions, is accomplished by a superior attacker who is able to muster more computing power than all the honest participants. I see that he can create new blocks and add them to create the longest chain, but how can he erase or add old transactions in the chain? As the attacker sends out his new blocks, aren't there consistency checks which honest nodes can perform, to make sure that nothing got erased? More explanation of this attack would be helpful, in order to judge the gains to an attacker from this, versus simply using his computing power to mint new coins honestly.",
		"a": "The attacker isn't adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he's doing that. He's rewriting history. Once his branch is longer, it becomes the new valid one.\n\nThis touches on a key point. Even though everyone present may see the shenanigans going on, there's no way to take advantage of that fact.\n\nIt is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can't have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU power proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what."
	},
	{
		"id": 13,
		"type": "favorite",
		"date": "2008-11-09 01:58:48",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html",
		"q": "As far as the spending transactions, what checks does the recipient of a coin have to perform? Does she need to go back through the coin's entire history of transfers, and make sure that every transaction on the list is indeed linked into the \"timestamp\" block chain? Or can she just do the latest one?",
		"a": "The recipient just needs to verify it back to a depth that is sufficiently far back in the block chain, which will often only require a depth of 2 transactions. All transactions before that can be discarded."
	},
	{
		"id": 14,
		"type": "favorite",
		"date": "2008-11-09 01:58:48",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html",
		"q": "Do the timestamp nodes check transactions, making sure that the previous transaction on a coin is in the chain, thereby enforcing the rule that all transactions in the chain represent valid coins?",
		"a": "Right, exactly. When a node receives a block, it checks the signatures of every transaction in it against previous transactions in blocks. Blocks can only contain transactions that depend on valid transactions in previous blocks or the same block. Transaction C could depend on transaction B in the same block and B depends on transaction A in an earlier block."
	},
	{
		"id": 15,
		"type": "favorite",
		"date": "2008-11-09 01:58:48",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html",
		"q": "Sorry about all the questions, but as I said this does seem to be a very promising and original idea, and I am looking forward to seeing how the concept is further developed. It would be helpful to see a more process oriented description of the idea, with concrete details of the data structures for the various objects (coins, blocks, transactions), the data which is included in messages, and algorithmic descriptions of the procedures for handling the various events which would occur in this system. You mentioned that you are working on an implementation, but I think a more formal, text description of the system would be a helpful next step.",
		"a": "I appreciate your questions. I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec. You're already right about most of your assumptions where you filled in the blanks."
	},
	{
		"id": 16,
		"type": "favorite",
		"date": "2008-11-09 03:09:49",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014833.html",
		"q": "The core concept is that lots of entities keep complete and consistent information as to who owns which bitcoins.\n\nBut maintaining consistency is tricky. It is not clear to me what happens when someone reports one transaction to one maintainer, and someone else transports another transaction to another maintainer. The transaction cannot be known to be valid until it has been incorporated into a globally shared view of all past transactions, and no one can know that a globally shared view of all past transactions is globally shared until after some time has passed, and after many new transactions have arrived.\n\nDid you explain how to do this, and it just passed over my head, or were you confident it could be done, and a bit vague as to the details?",
		"a": "The proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone.\n\nA transaction will quickly propagate throughout the network, so if two versions of the same transaction were reported at close to the same time, the one with the head start would have a big advantage in reaching many more nodes first. Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort.\n\nIf the transactions did come at exactly the same time and there was an even split, it's a toss up based on which gets into a proof-of-work first, and that decides which is valid.\n\nWhen a node finds a proof-of-work, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it's now invalid according to the accepted chain.\n\nThe proof-of-work chain is itself self-evident proof that it came from the globally shared view. Only the majority of the network together has enough CPU power to generate such a difficult chain of proof-of-work. Any user, upon receiving the proof-of-work chain, can see what the majority of the network has approved. Once a transaction is hashed into a link that's a few links back in the chain, it is firmly etched into the global history."
	},
	{
		"id": 17,
		"type": "favorite",
		"date": "2008-11-09 16:31:26",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014838.html",
		"q": "OK, suppose one node incorporates a bunch of transactions in its proof of work, all of them honest legitimate single spends and another node incorporates a different bunch of transactions in its proof of work, all of them equally honest legitimate single spends, and both proofs are generated at about the same time.\n\nWhat happens then?",
		"a": "They both broadcast their blocks. All nodes receive them and keep both, but only work on the one they received first. We'll suppose exactly half received one first, half the other.\n\nIn a short time, all the transactions will finish propagating so that everyone has the full set. The nodes working on each side will be trying to add the transactions that are missing from their side. When the next proof-of-work is found, whichever previous block that node was working on, that branch becomes longer and the tie is broken. Whichever side it is, the new block will contain the other half of the transactions, so in either case, the branch will contain all transactions. Even in the unlikely event that a split happened twice in a row, both sides of the second split would contain the full set of transactions anyway.\n\nIt's not a problem if transactions have to wait one or a few extra cycles to get into a block."
	},
	{
		"id": 18,
		"type": "favorite",
		"date": "2008-11-10 02:14:30",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014842.html",
		"q": "Furthermore, it cannot be made to work, as in the proposed system the work of tracking who owns what coins is paid for by seigniorage, which requires inflation.",
		"a": "If you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee's side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block."
	},
	{
		"id": 19,
		"type": "favorite",
		"date": "2008-11-10 22:18:20",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014843.html",
		"q": "So what happened to the coin that lost the race?\n\n... it is a bit harsh if the guy who came second is likely to lose his coin.",
		"a": "When there are multiple double-spent versions of the same transaction, one and only one will become valid.\n\nThe receiver of a payment must wait an hour or so before believing that it's valid. The network will resolve any possible double-spend races by then.\n\nThe guy who received the double-spend that became invalid never thought he had it in the first place. His software would have shown the transaction go from \"unconfirmed\" to \"invalid\". If necessary, the UI can be made to hide transactions until they're sufficiently deep in the block chain."
	},
	{
		"id": 20,
		"type": "favorite",
		"date": "2008-11-10 22:18:20",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014843.html",
		"q": "Further, your description of events implies restrictions on timing and coin generation - that the entire network generates coins slowly compared to the time required for news of a new coin to flood the network",
		"a": "Sorry if I didn't make that clear. The target time between blocks will probably be 10 minutes.\n\nEvery block includes its creation time. If the time is off by more than 36 hours, other nodes won't work on it. If the timespan over the last 6*24*30 blocks is less than 15 days, blocks are being generated too fast and the proof-of-work difficulty doubles. Everyone does the same calculation with the same chain data, so they all get the same result at the same link in the chain."
	},
	{
		"id": 21,
		"type": "favorite",
		"date": "2008-11-10 22:18:20",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014843.html",
		"q": "We want spenders to have certainty that their transaction is valid at the time it takes a spend to flood the network, not at the time it takes for branch races to be resolved.",
		"a": "Instantant non-repudiability is not a feature, but it's still much faster than existing systems. Paper cheques can bounce up to a week or two later. Credit card transactions can be contested up to 60 to 180 days later. Bitcoin transactions can be sufficiently irreversible in an hour or two."
	},
	{
		"id": 22,
		"type": "favorite",
		"date": "2008-11-10 22:18:20",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014843.html",
		"q": "If one node is ignoring all spends that it does not care about, it suffers no adverse consequences.",
		"a": "With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive."
	},
	{
		"id": 23,
		"type": "favorite",
		"date": "2008-11-13 22:56:55",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014849.html",
		"q": "It is not sufficient that everyone knows X. We also need everyone to know that everyone knows X, and that everyone knows that everyone knows that everyone knows X - which, as in the Byzantine Generals problem, is the classic hard problem of distributed data processing.",
		"a": "The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context.\n\nA number of Byzantine Generals each have a computer and want to attack the King's wi-fi by brute forcing the password, which they've learned is a certain number of characters in length. Once they stimulate the network to generate a packet, they must crack the password within a limited time to break in and erase the logs, otherwise they will be discovered and get in trouble. They only have enough CPU power to crack it fast enough if a majority of them attack at the same time.\n\nThey don't particularly care when the attack will be, just that they all agree. It has been decided that anyone who feels like it will announce a time, and whatever time is heard first will be the official attack time. The problem is that the network is not instantaneous, and if two generals announce different attack times at close to the same time, some may hear one first and others hear the other first.\n\nThey use a proof-of-work chain to solve the problem. Once each general receives whatever attack time he hears first, he sets his computer to solve an extremely difficult proof-of-work problem that includes the attack time in its hash. The proof-of-work is so difficult, it's expected to take 10 minutes of them all working at once before one of them finds a solution. Once one of the generals finds a proof-of-work, he broadcasts it to the network, and everyone changes their current proof-of-work computation to include that proof-of-work in the hash they're working on. If anyone was working on a different attack time, they switch to this one, because its proof-of-work chain is now longer.\n\nAfter two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU power per hour was expended on it and see that it must have required the majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proof-of-work is proof that they worked on it. If the CPU power exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time.\n\nThe proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved."
	},
	{
		"id": 24,
		"type": "favorite",
		"date": "2008-11-14 18:55:35",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014853.html",
		"q": "I think it is necessary that nodes keep a separate pending-transaction list associated with each candidate chain.\n\n... One might also ask ... how many candidate chains must a given node keep track of at one time, on average?",
		"a": "Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch. When a new block arrives for the best branch, ConnectBlock removes the block's transactions from the pending-tx pool. If a different branch becomes longer, it calls DisconnectBlock on the main branch down to the fork, returning the block transactions to the pending-tx pool, and calls ConnectBlock on the new branch, sopping back up any transactions that were in both branches. It's expected that reorgs like this would be rare and shallow.\n\nWith this optimisation, candidate branches are not really any burden. They just sit on the disk and don't require attention unless they ever become the main chain."
	},
	{
		"id": 25,
		"type": "favorite",
		"date": "2008-11-14 18:55:35",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014853.html",
		"q": "Or as James raised earlier, if the network broadcast is reliable but depends on a potentially slow flooding algorithm, how does that impact performance?",
		"a": "Broadcasts will probably be almost completely reliable. TCP transmissions are rarely ever dropped these days, and the broadcast protocol has a retry mechanism to get the data from other nodes after a while. If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.\n\nI'm planning to run an automated test with computers randomly sending payments to each other and randomly dropping packets."
	},
	{
		"id": 26,
		"type": "favorite",
		"date": "2008-11-14 18:55:35",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014853.html",
		"q": "3. The bitcoin system turns out to be socially useful and valuable, so that node operators feel that they are making a beneficial contribution to the world by their efforts (similar to the various \"@Home\" compute projects where people volunteer their compute resources for good causes).\n\nIn this case it seems to me that simple altruism can suffice to keep the network running properly.",
		"a": "It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though."
	},
	{
		"id": 27,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "When a coin is spent, the buyer and seller digitally sign a (blinded) transaction record.",
		"a": "Only the buyer signs, and there's no blinding."
	},
	{
		"id": 28,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "If someone double spends, then the transaction record can be unblinded revealing the identity of the cheater.",
		"a": "Identities are not used, and there's no reliance on recourse. It's all prevention."
	},
	{
		"id": 29,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "This is done via a fairly standard cut-and-choose algorithm where the buyer responds to several challenges with secret shares",
		"a": "No challenges or secret shares. A basic transaction is just what you see in the figure in section 2. A signature (of the buyer) satisfying the public key of the previous transaction, and a new public key (of the seller) that must be satisfied to spend it the next time."
	},
	{
		"id": 30,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "They may also receive chains as long as the one they're trying to extend while they work, in which the last few \"links\" are links that are *not* in common with the chain on which they're working.\n\nThese they ignore.",
		"a": "Right, if it's equal in length, ties are broken by keeping the earliest one received."
	},
	{
		"id": 31,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "If it contains a double spend, then they create a \"transaction\" which is a proof of double spending, add it to their pool A, broadcast it, and continue work.",
		"a": "There's no need for reporting of \"proof of double spending\" like that. If the same chain contains both spends, then the block is invalid and rejected.\n\nSame if a block didn't have enough proof-of-work. That block is invalid and rejected. There's no need to circulate a report about it. Every node could see that and reject it before relaying it.\n\nIf there are two competing chains, each containing a different version of the same transaction, with one trying to give money to one person and the other trying to give the same money to someone else, resolving which of the spends is valid is what the whole proof-of-work chain is about.\n\nWe're not \"on the lookout\" for double spends to sound the alarm and catch the cheater. We merely adjudicate which one of the spends is valid. Receivers of transactions must wait a few blocks to make sure that resolution has had time to complete. Would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that within a few blocks, one of the spends becomes valid and the others become invalid. Any later double-spends are immediately rejected once there's already a spend in the main chain.\n\nEven if an earlier spend wasn't in the chain yet, if it was already in all the nodes' pools, then the second spend would be turned away by all those nodes that already have the first spend."
	},
	{
		"id": 32,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "If the new chain is accepted, then they give up on adding their current link, dump all the transactions from pool L back into pool A (along with transactions they've received or created since starting work), eliminate from pool A those transaction records which are already part of a link in the new chain, and start work again trying to extend the new chain.",
		"a": "Right. They also refresh whenever a new transaction comes in, so L pretty much contains everything in A all the time."
	},
	{
		"id": 33,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "CPU-intensive digital signature algorithm to sign the chain including the new block L.",
		"a": "It's a Hashcash style SHA-256 proof-of-work (partial pre-image of zero), not a signature."
	},
	{
		"id": 34,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "Is there a mechanism to make sure that the \"chain\" does not consist solely of links added by just the 3 or 4 fastest nodes? 'Cause a broadcast transaction record could easily miss those 3 or 4 nodes and if it does, and those nodes continue to dominate the chain, the transaction might never get added.",
		"a": "If you're thinking of it as a CPU-intensive digital signing, then you may be thinking of a race to finish a long operation first and the fastest always winning.\n\nThe proof-of-work is a Hashcash style SHA-256 collision finding. It's a memoryless process where you do millions of hashes a second, with a small chance of finding one each time. The 3 or 4 fastest nodes' dominance would only be proportional to their share of the total CPU power. Anyone's chance of finding a solution at any time is proportional to their CPU power.\n\nThere will be transaction fees, so nodes will have an incentive to receive and include all the transactions they can. Nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling."
	},
	{
		"id": 35,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "Also, the work requirement for adding a link to the chain should vary (again exponentially) with the number of links added to that chain in the previous week, causing the rate of coin generation (and therefore inflation) to be strictly controlled.",
		"a": "Right."
	},
	{
		"id": 36,
		"type": "favorite",
		"date": "2008-11-15 04:43:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html",
		"q": "You need coin aggregation for this to scale. There needs to be a \"provable\" transaction where someone retires ten single coins and creates a new coin with denomination ten, etc.",
		"a": "Every transaction is one of these. Section 9, Combining and Splitting Value."
	},
	{
		"id": 37,
		"type": "favorite",
		"date": "2008-11-15 18:02:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014860.html",
		"q": "One way to do this would be to have the person recieving the coin generate an asymmetric key pair, and then have half of it published with the transaction. In order to spend the coin later, s/he must demonstrate posession of the other half of the asymmetric key pair, probably by using it to sign the key provided by the new seller.",
		"a": "Right, it's ECC digital signatures. A new key pair is used for every transaction.\n\nIt's not pseudonymous in the sense of nyms identifying people, but it is at least a little pseudonymous in that the next action on a coin can be identified as being from the owner of that coin."
	},
	{
		"id": 38,
		"type": "favorite",
		"date": "2008-11-15 18:02:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014860.html",
		"q": "Mmmm. I don't know if I'm comfortable with that. You're saying there's no effort to identify and exclude nodes that don't cooperate? I suspect this will lead to trouble and possible DOS attacks.",
		"a": "There is no reliance on identifying anyone. As you've said, it's futile and can be trivially defeated with sock puppets.\n\nThe credential that establishes someone as real is the ability to supply CPU power."
	},
	{
		"id": 39,
		"type": "favorite",
		"date": "2008-11-15 18:02:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014860.html",
		"q": "Until.... until what? How does anybody know when a transaction has become irrevocable? Is \"a few\" blocks three? Thirty? A hundred? Does it depend on the number of nodes? Is it logarithmic or linear in number of nodes?",
		"a": "Section 11 calculates the worst case under attack. Typically, 5 or 10 blocks is enough for that. If you're selling something that doesn't merit a network-scale attack to steal it, in practice you could cut it closer."
	},
	{
		"id": 40,
		"type": "favorite",
		"date": "2008-11-15 18:02:00",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014860.html",
		"q": "But in the absence of identity, there's no downside to them if spends become invalid, if they've already received the goods they double-spent for (access to website, download, whatever). The merchants are left holding the bag with \"invalid\" coins, unless they wait that magical \"few blocks\" (and how can they know how many?) before treating the spender as having paid.\n\nThe consumers won't do this if they spend their coin and it takes an hour to clear before they can do what they spent their coin on.\n\nThe merchants won't do it if there's no way to charge back a customer when they find the that their coin is invalid because the customer has doublespent.",
		"a": "This is a version 2 problem that I believe can be solved fairly satisfactorily for most applications.\n\nThe race is to spread your transaction on the network first. Think 6 degrees of freedom -- it spreads exponentially. It would only take something like 2 minutes for a transaction to spread widely enough that a competitor starting late would have little chance of grabbing very many nodes before the first one is overtaking the whole network.\n\nDuring those 2 minutes, the merchant's nodes can be watching for a double-spent transaction. The double-spender would not be able to blast his alternate transaction out to the world without the merchant getting it, so he has to wait before starting.\n\nIf the real transaction reaches 90% and the double-spent tx reaches 10%, the double-spender only gets a 10% chance of not paying, and 90% chance his money gets spent. For almost any type of goods, that's not going to be worth it for the scammer.\n\nInformation based goods like access to website or downloads are non-fencible. Nobody is going to be able to make a living off stealing access to websites or downloads. They can go to the file sharing networks to steal that. Most instant-access products aren't going to have a huge incentive to steal.\n\nIf a merchant actually has a problem with theft, they can make the customer wait 2 minutes, or wait for something in e-mail, which many already do. If they really want to optimize, and it's a large download, they could cancel the download in the middle if the transaction comes back double-spent. If it's website access, typically it wouldn't be a big deal to let the customer have access for 5 minutes and then cut off access if it's rejected. Many such sites have a free trial anyway."
	},
	{
		"id": 41,
		"type": "favorite",
		"date": "2008-11-17 17:24:43",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014863.html",
		"q": "This requires that we know, that is to say an honest well behaved peer whose communications and data storage is working well knows, what the current best branch is -",
		"a": "I mean a node only needs the pending-tx pool for the best branch it has. The branch that it currently thinks is the best branch.\n\nThat's the branch it'll be trying to make a block out of, which is all it needs the pool for."
	},
	{
		"id": 42,
		"type": "favorite",
		"date": "2008-11-17 17:24:43",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014863.html",
		"q": "Rather than assuming that each message arrives at least once, we have to make a mechanism such that the information arrives even though conveyed by messages that frequently fail to arrive.",
		"a": "I think I've got the peer networking broadcast mechanism covered.\n\nEach node sends its neighbours an inventory list of hashes of the new blocks and transactions it has. The neighbours request the items they don't have yet. If the item never comes through after a timeout, they request it from another neighbour that had it. Since all or most of the neighbours should eventually have each item, even if the coms get fumbled up with one, they can get it from any of the others, trying one at a time.\n\nThe inventory-request-data scheme introduces a little latency, but it ultimately helps speed more by keeping extra data blocks off the transmit queues and conserving bandwidth."
	},
	{
		"id": 43,
		"type": "favorite",
		"date": "2008-11-17 17:24:43",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2008-November/014863.html",
		"q": "You have an outline and proposal for such a design, which is a big step forward, but the devil is in the little details.",
		"a": "I believe I've worked through all those little details over the last year and a half while coding it, and there were a lot of them.\n\nThe functional details are not covered in the paper, but the sourcecode is coming soon. I sent you the main files.\n\n(available by request at the moment, full release soon)"
	},
	{
		"id": 44,
		"type": "favorite",
		"date": "2009-01-16 16:03:14",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2009-January/015014.html",
		"q": "Yea, that was the primary feature that caught my eye. The real trick will be to get people to actually value the BitCoins so that they become currency.",
		"a": "I would be surprised if 10 years from now we're not using electronic currency in some way, now that we know a way to do it that won't inevitably get dumbed down when the trusted third party gets cold feet.\n\nIt could get started in a narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Initially it can be used in proof-of-work applications for services that could almost be free but not quite.\n\nIt can already be used for pay-to-send e-mail. The send dialog is resizeable and you can enter as long of a message as you like.\n\nIt's sent directly when it connects. The recipient doubleclicks on the transaction to see the full message. If someone famous is getting more e-mail than they can read, but would still like to have a way for fans to contact them, they could set up Bitcoin and give out the IP address on their website. \"Send X bitcoins to my priority hotline at this IP and I'll read the message personally.\" Subscription sites that need some extra proof-of-work for their free trial so it doesn't cannibalize subscriptions could charge bitcoins for the trial.\n\nIt might make sense just to get some in case it catches on. If enough people think the same way, that becomes a self fulfilling prophecy. Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine."
	},
	{
		"id": 45,
		"type": "favorite",
		"date": "2009-01-25 15:47:10",
		"src": "http://www.metzdowd.com/pipermail/cryptography/2009-January/015041.html",
		"q": "If POW tokens do become useful, and especially if they become money, machines will no longer sit idle. Users will expect their computers to be earning them money (assuming the reward is greater than the cost to operate). A computer whose earnings are being stolen by a botnet will be more noticeable to its owner than is the case today, hence we might expect that in that world, users will work harder to maintain their computers and clean them of botnet infestations.",
		"a": "there would be a profit motive for people to set up massive quantities of fake e-mail accounts to harvest POW tokens from spam. They'd essentially be reverse-spamming the spammers with automated mailboxes that collect their POW and don't read the message. The ratio of fake mailboxes to real people could become too high for spam to be cost effective.\n\nThe process has the potential to establish the POW token's value in the first place, since spammers that don't have a botnet could buy tokens from harvesters. While the buying back would temporarily let more spam through, it would only hasten the self-defeating cycle leading to too many harvesters exploiting the spammers.\n\nInterestingly, one of the e-gold systems already has a form of spam called \"dusting\". Spammers send a tiny amount of gold dust in order to put a spam message in the transaction's comment field.\n\nIf the system let users configure the minimum payment they're willing to receive, or at least the minimum that can have a message with it, users could set how much they're willing to get paid to receive spam."
	},
	{
		"id": 46,
		"date": "2009-01-25 16:45:25",
		"src": "https://sourceforge.net/p/bitcoin/mailman/message/21424626/",
		"q": "I have had a couple of problems running bitcoin: is this an appropriate list for reporting them (with about 70kb of attachments)?",
		"a": "What's the problem you're having? If you send me your debug.log file directly (best not to send attachments to the list), I can take a look at what's happening.\n\nbitcoin-help at vistomail dot com"
	},
	{
		"id": 47,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "What is the main issue with conventional currency or money?",
		"a": "The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency. The history of fiat currencies is full of breaches of that trust"
	},
	{
		"id": 48,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "What is the issue with banks holding our money and managing electronic transfers?",
		"a": "Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve"
	},
	{
		"id": 49,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "What do we risk when trusting banks with our money and privacy?",
		"a": "We have to trust them with our privacy, trust them not to let identity thieves drain our accounts"
	},
	{
		"id": 50,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "What problem do the overhead costs of banks cause?",
		"a": "Their massive overhead costs make micropayments impossible"
	},
	{
		"id": 51,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "What advantage does encryption provide in relation to descentralization and privacy?",
		"a": "Before strong encryption, Users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private. Privacy could always be overridden by the admin based on his judgment call ... Then strong encryption became available to the masses, and trust was no longer required"
	},
	{
		"id": 52,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "What is the key feature of Bitcoin as money that makes it different from conventional currency systems?",
		"a": "It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust"
	},
	{
		"id": 53,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "How is Bitcoin different from conventional currencies and payment networks?",
		"a": "With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless"
	},
	{
		"id": 54,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "What is a major disadvantage of the traditional model of preventing double-spending?",
		"a": "The usual solution is for a trusted company with a central database to check for double-spending, but that just gets back to the trust model. In its central position, the company can override the users"
	},
	{
		"id": 55,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "How does Bitcoin address the problem of double-spending?",
		"a": "The network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle. For details on how it works, see the design paper at http://www.bitcoin.org/bitcoin.pdf"
	},
	{
		"id": 56,
		"type": "gpt-4",
		"date": "2009-02-11 22:27:00",
		"src": "http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source",
		"q": "What does the Bitcoin system achieve by operating the way it does?",
		"a": "The result is a distributed system with no single point of failure. Users hold the crypto keys to their own money and transact directly with each other, with the help of the P2P network to check for double-spending"
	},
	{
		"id": 57,
		"date": "2009-02-15 16:42:00",
		"src": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9493",
		"q": "Dante, in an email, has mentioned a UK project called Open Coin. It seems to go in a similar direction.\nCould there be synergies with bitcoin?\nhttp://opencoin.org/",
		"a": "Could be. They're talking about the old Chaumian central mint stuff, but maybe only because that was the only thing available. Maybe they would be interested in going in a new direction.\nA lot of people automatically dismiss e-currency as a lost cause because of all the companies that failed since the 1990's. I hope it's obvious it was only the centrally controlled nature of those systems that doomed them. I think this is the first time we're trying a decentralized, non-trust-based system."
	},
	{
		"id": 58,
		"date": "2009-02-18 20:50:00",
		"src": "http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9562",
		"q": "I have two questions, Satoshi.\nthe first one ties in with Joerg's doubts about the trusted supply of tokens/coins.\nAs far as I understand, there will be a limit of the total amount of tokens that can be created, and a changing gradient of difficulty in making the tokens, where the elaboration gets more and more difficult with time. Is that correct?\nIt is important that there be a limit in the amount of tokens/coins. But it is also important that this limit be adjustable to take account of how many people adopt the system. If the number of users changes with time, it will also be necessary to change the total amount of coins.\nIs there a formula to decide on what should be the total amount of tokens, and if so, what is the formula?\nIf there is no formula, who gets to make that decision and based on what criteria will it be made?\nI will keep my second question for later. One thing at a time...",
		"a": "It is a global distributed database, with additions to the database by consent of the majority, based on a set of rules they follow:\n- Whenever someone finds proof-of-work to generate a block, they get some new coins\n- The proof-of-work difficulty is adjusted every two weeks to target an average of 6 blocks per hour (for the whole network)\n- The coins given per block is cut in half every 4 years\nYou could say coins are issued by the majority. They are issued in a limited, predetermined amount.\nAs an example, if there are 1000 nodes, and 6 get coins each hour, it would likely take a week before you get anything.\nTo Sepp's question, indeed there is nobody to act as central bank or federal reserve to adjust the money supply as the population of users grows. That would have required a trusted party to determine the value, because I don't know a way for software to know the real world value of things. If there was some clever way, or if we wanted to trust someone to actively manage the money supply to peg it to something, the rules could have been programmed for that.\nIn this sense, it's more typical of a precious metal. Instead of the supply changing to keep the value the same, the supply is predetermined and the value changes. As the number of users grows, the value per coin increases. It has the potential for a positive feedback loop; as users increase, the value goes up, which could attract more users to take advantage of the increasing value."
	},
	{
		"id": 59,
		"date": "2009-02-22 17:47:52",
		"src": "https://sourceforge.net/p/bitcoin/mailman/message/21646307/",
		"q": "What's next?",
		"a": "The next thing for v0.1.6 is to take advantage of multiple processors to generate blocks. Currently it only starts one thread. If you have a multi-core processor like a Core Duo or Quad this will double or quadruple your production.\n\nLater I want to add interfaces to make it really easy to integrate into websites from any server side language."
	},
	{
		"id": 60,
		"type": "ignore",
		"date": "2009-03-04 16:59:12",
		"src": "https://sourceforge.net/p/bitcoin/mailman/message/21740046/",
		"q": "That sounds good. I'd also like to be able to run multiple coin/block generators on multiple machines, all behind a single NAT address. I haven't tried this yet so I don't know if it works on the current software.",
		"a": "The current version will work fine. They'll each connect over the Internet, while incoming connections only come to the host that port 8333 is routed to.\n\nAs an optimisation, I'll make a switch \"-connect=1.2.3.4\" to make it only connect to a specific address. You could make your extra nodes connect to your primary, and only the primary connects over the Internet. It doesn't really matter for now, since the network would have to get huge before the bandwidth is anything more than trivial."
	},
	{
		"id": 61,
		"type": "ignore",
		"date": "2009-03-04 16:59:12",
		"src": "https://sourceforge.net/p/bitcoin/mailman/message/21740046/",
		"q": "BTW I don't remember if we talked about this, but the other day some people were mentioning secure timestamping. You want to be able to prove that a certain document existed at a certain time in the past.\n\nSeems to me that bitcoin's stack of blocks would be perfect for this.",
		"a": "Indeed, Bitcoin is a distributed secure timestamp server for transactions. A few lines of code could create a transaction with an extra hash in it of anything that needs to be timestamped.\n\nI should add a command to timestamp a file that way."
	},
	{
		"id": 62,
		"type": "ignore",
		"date": "2009-03-04 16:59:12",
		"src": "https://sourceforge.net/p/bitcoin/mailman/message/21740046/",
		"q": "Right, and I'd like to see more of a library interface that could be called from programming or scripting languages, on the client side as well.",
		"a": "Exactly."
	},
	{
		"id": 63,
		"type": "ignore",
		"date": "2009-10-23 23:57:51",
		"src": "https://sourceforge.net/p/bitcoin/mailman/message/23824064/",
		"q": "Do you Windows users experience occasional Bitcoin crashes? Lately Bitcoin running in wine-1.0.1 has been crashing frequently. I was just wondering whether this is a Wine issue or a Bitcoin issue.",
		"a": "I haven't had any reports of crashes in v0.1.5. It's been rock solid for me on Windows. I think it must be Wine related. If you get another crash in Wine and it prints anything on the terminal, e-mail me and I may be able to figure out what happened, maybe something I can work around. Martti and I have been working on a new version to release soon and it would be nice to get any Wine fixes in there."
	},
	{
		"id": 64,
		"type": "ignore",
		"date": "2009-10-23 23:57:51",
		"src": "https://sourceforge.net/p/bitcoin/mailman/message/23824064/",
		"q": "The following four lines print from the terminal when I start Bitcoin.\n\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot fixme:toolhelp:Heap32ListFirst : stub",
		"a": "Those don't look like anything to worry about. Probably functions unimplemented by Wine that are harmlessly stubbed out."
	},
	{
		"id": 65,
		"type": "ignore",
		"date": "2009-10-23 23:57:51",
		"src": "https://sourceforge.net/p/bitcoin/mailman/message/23824064/",
		"q": "I previously wasn't starting Bitcoin from the terminal, so I don't know what gets printed out when it crashes, but I'll reply with the results the next time it crashes.\n\nWhile Bitcoin first downloads previously completed blocks, the file debug.log grows grows to 17.4 MB and then stops growing. I imagine it will continue to grow as more bitcoins are completed.",
		"a": "You can delete debug.log occasionally if you don't want to take the disk space. It's just status messages that help with debugging.\n\nbitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing some maintenance."
	},
	{
		"id": 66,
		"date": "2009-11-22 18:34:21",
		"src": "https://bitcointalk.org/index.php?topic=6.msg31#msg31",
		"q": "the network connection is used when you broadcast the information about the proof-of-work block you've created (that which entitles you to the new coin). Generating coins successfully requires constant connectivity, so that you can start working on the next block when someone gets the current block before you.\nWhich stages require network connectivity, significant local CPU usage and or significant remote CPU usage? Do any of these stages have names?",
		"a": "1) During generation (when the status bar says \"Generating\" and you're using CPU to find a proof-of-work), you must constantly keep in contact with the network to receive the latest block. If your block does not link to the latest block, it may not be accepted.\nIt's important to have network connectivity while you're trying to generate a coin (block) and at the moment it is successfully generated.\n2) When you successfully generate a block, it is immediately broadcast to the network. Other nodes must receive it and link to it for it to be accepted as the new latest block.\nThink of it as a cooperative effort to make a chain. When you add a link, you must first find the current end of the chain. If you were to locate the last link, then go off for an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several links since then and they're not going to want to use your link that now branches off the middle.\nAfter a block is created, the maturation time of 120 blocks is to make absolutely sure the block is part of the main chain before it can be spent. Your node isn't doing anything with the block during that time, just waiting for other blocks to be added after yours. You don't have to be online during that time."
	},
	{
		"id": 67,
		"date": "2009-11-22 18:35:15",
		"src": "https://bitcointalk.org/index.php?topic=7.msg32#msg32",
		"q": "Are there any plans to make this service anonymous?\ne.g; Being able to route BitCoin through Tor.",
		"a": "There will be a proxy setting in version 0.2 so you can connect through TOR. I've done a careful scrub to make sure it doesn't use DNS or do anything that would leak your IP while in proxy mode."
	},
	{
		"id": 68,
		"date": "2009-11-25 18:17:23",
		"src": "https://bitcointalk.org/index.php?topic=8.msg34#msg34",
		"q": "Can nodes on the network tell from which and or to which bitcoin address coins are being sent? Do blocks contain a history of where bitcoins have been transfered to and from?",
		"a": "Bitcoins are sent to and from bitcoin addresses, which are essentially random numbers with no identifying information.\nWhen you send to an IP address, the transaction is still written to a bitcoin address. The IP address is only used to connect to the recipient's computer to request a fresh bitcoin address, give the transaction directly to the recipient and get a confirmation.\nBlocks contain a history of the bitcoin addresses that a coin has been transferred to. If the identities of the people using the bitcoin addresses are not known and each address is used only once, then this information only reveals that some unknown person transferred some amount to someone else.\nThe possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use. If you post your bitcoin address on the web, then you're associating that address and any transactions with it with the name you posted under. If you posted under a handle that you haven't associated with your real identity, then you're still pseudonymous.\nFor greater privacy, it's best to use bitcoin addresses only once. You can change addresses as often as you want using Options->Change Your Address. Transfers by IP address automatically use a new bitcoin address each time."
	},
	{
		"id": 69,
		"date": "2009-11-25 18:17:23",
		"src": "https://bitcointalk.org/index.php?topic=8.msg34#msg34",
		"q": "Can nodes tell which bitcoin addresses belong to which IP addresses?",
		"a": "No."
	},
	{
		"id": 70,
		"date": "2009-11-25 18:17:23",
		"src": "https://bitcointalk.org/index.php?topic=8.msg34#msg34",
		"q": "Is there a command line option to enable the sock proxy the first time that bitcoin starts?",
		"a": "In the next release (version 0.2), the command line to run it through a proxy from the first time is:\nbitcoin -proxy=127.0.0.1:9050\nThe problem for TOR is that the IRC server which Bitcoin uses to initially discover other nodes bans the TOR exit nodes, as all IRC servers do. If you've already connected once before then you're already seeded, but for the first time, you'd need to provide the address of a node as such:\nbitcoin -proxy=127.0.0.1:9050 -addnode=<someipaddress>\nIf someone running a node with a static IP address that can accept incoming connections could post their IP to use for -addnode, that would be great."
	},
	{
		"id": 71,
		"date": "2009-11-25 18:17:23",
		"src": "https://bitcointalk.org/index.php?topic=8.msg34#msg34",
		"q": "What happens if you send bitcoins to an IP address that has multiple clients connected through network address translation (NAT)?",
		"a": "Whichever one you've set your NAT to forward port 8333 to will receive it. If your router can change the port number when it forwards, you could allow more than one client to receive. For instance, if port 8334 forwards to a computer's port 8333, then senders could send to \"x.x.x.x:8334\"\nIf your NAT can't translate port numbers, there currently isn't a command line option to change the incoming port that bitcoin binds to, but I'll look into it."
	},
	{
		"id": 72,
		"type": "ignore",
		"date": "2009-11-27 17:27:09",
		"src": "https://bitcointalk.org/index.php?topic=9.msg37#msg37",
		"q": "Can we get instructions or modifications to compile and install BitCoin on Linux? A command line version would be great.",
		"a": "The Linux version is on its way. Martti's Linux port was merged into the main code branch and New Liberty Standard has been testing it. It'll be in the next release, version 0.2.\nCommand line is on the to-do list after 0.2."
	},
	{
		"id": 73,
		"type": "ignore",
		"date": "2009-12-09 18:45:10",
		"src": "https://bitcointalk.org/index.php?topic=12.msg41#msg41",
		"q": "Hey,\nFirst off I must say that this is an amazing concept. I have been dreaming of a P2P money system for a LONG time.\nYou have my complete kudos and respect.\nI have a few suggestions:\n- When the bitcoin software establishes a connection with a peer (client TCP socket) have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.\n- Use some sort of encryption during the handshake (sort of goes with the statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about people in non-free (as in freedom) countries such as China/Iran.\n- Some sort of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments) outbound. Status could be returned via the https receipt interface.\n- Static port/Random port. Have a setting to randomly assign the port that it runs on. (also be able to set it statically for very restrictive firewalls).\n- UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu.\n- Ability to compile a headless (console only) install for *NIX systems. Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket would be ok).",
		"a": "Helpful suggestions, thanks."
	},
	{
		"id": 74,
		"type": "ignore",
		"date": "2009-12-09 18:45:10",
		"src": "https://bitcointalk.org/index.php?topic=12.msg41#msg41",
		"q": "- When the bitcoin software establishes a connection with a peer (client TCP socket) have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.",
		"a": "That's a good idea. The side accepting the connection just needs to withhold from sending anything until it receives a valid handshake. Any portscan would only get a dead connection that doesn't volunteer to identify itself."
	},
	{
		"id": 75,
		"type": "ignore",
		"date": "2009-12-09 18:45:10",
		"src": "https://bitcointalk.org/index.php?topic=12.msg41#msg41",
		"q": "- Use some sort of encryption during the handshake (sort of goes with the statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about people in non-free (as in freedom) countries such as China/Iran.",
		"a": "I have thought about eventually SSLing all the connections. I assume anything short of SSL would be pointless against DPI. Maybe a better more immediate solution is to connect through TOR, which will be possible with 0.2."
	},
	{
		"id": 76,
		"type": "ignore",
		"date": "2009-12-09 18:45:10",
		"src": "https://bitcointalk.org/index.php?topic=12.msg41#msg41",
		"q": "- Some sort of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments) outbound. Status could be returned via the https receipt interface.",
		"a": "That's one of the main things on the agenda after 0.2."
	},
	{
		"id": 77,
		"type": "ignore",
		"date": "2009-12-09 18:45:10",
		"src": "https://bitcointalk.org/index.php?topic=12.msg41#msg41",
		"q": "- Static port/Random port. Have a setting to randomly assign the port that it runs on. (also be able to set it statically for very restrictive firewalls).",
		"a": "Yeah, the other stealth stuff would be kinda pointless if it's always the same port number."
	},
	{
		"id": 78,
		"type": "ignore",
		"date": "2009-12-09 18:45:10",
		"src": "https://bitcointalk.org/index.php?topic=12.msg41#msg41",
		"q": "- UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu.",
		"a": "I'm looking forward to trying UPnP. Do most P2P clients typically have UPnP enabled by default?"
	},
	{
		"id": 79,
		"type": "ignore",
		"date": "2009-12-09 18:45:10",
		"src": "https://bitcointalk.org/index.php?topic=12.msg41#msg41",
		"q": "- Ability to compile a headless (console only) install for *NIX systems. Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket would be ok).",
		"a": "I'm still thinking about how best to structure the management interface. Maybe command line commands to communicate with the background daemon to query transactions received and initiate sending transfers. That would be more automation friendly. Or what about an http interface on some port other than 80 to manage it with a browser?"
	},
	{
		"id": 80,
		"type": "ignore",
		"date": "2009-12-10 19:31:49",
		"src": "https://bitcointalk.org/index.php?topic=12.msg45#msg45",
		"q": "Front ends can also be ran on clients with very low cpu power such as mobile phones.",
		"a": "That's a good approach for mobile. Programmatic API used by PHP (any language) to present a web UI covers remote admin, mobile and any other client that can't be online all the time with a static IP. It would be like webmail. It would be easier for new users to get started if they only need to create an account on a website, not install software."
	},
	{
		"id": 81,
		"type": "ignore",
		"date": "2009-12-10 19:31:49",
		"src": "https://bitcointalk.org/index.php?topic=12.msg45#msg45",
		"q": "The app could be pre-seeded before downloading. Pre-seeding would also cure the TOR+IRC problem. I know that people will want to run this system over I2P+TOR.",
		"a": "Yeah, we can phase out IRC when there are enough static nodes to preprogram a seed list. Once you get seeded, you don't need IRC."
	},
	{
		"id": 82,
		"type": "ignore",
		"date": "2009-12-10 19:31:49",
		"src": "https://bitcointalk.org/index.php?topic=12.msg45#msg45",
		"q": "Also you could pre-seed the blocks so they won't have to be downloaded upon initial run. (Downloading 28,000 blocks on a slower ADSL takes forever I couldn't imagine how long it would take when there are millions of blocks -- a lifetime).",
		"a": "There were some issues in 0.1.5 where the initial block download could get bogged down. 0.2 has code to make sure it goes smoothly. It ought to take less than an hour, I think. I need to hurry up and get 0.2 out the door.\nThe blocks increase linearly, it'll be decades before it's millions. In theory, the block download time should top out 8 months from now when Moore's Law will be growing faster than the block chain."
	},
	{
		"id": 83,
		"type": "ignore",
		"date": "2009-12-10 19:31:49",
		"src": "https://bitcointalk.org/index.php?topic=12.msg45#msg45",
		"q": "Can you give me CVS access or something? (If not, can I send you patches?) I'd like to help out.",
		"a": "It's SVN on sourceforge. PM or e-mail me your sourceforge account and I'll give you access."
	},
	{
		"id": 84,
		"type": "ignore",
		"date": "2009-12-10 19:31:49",
		"src": "https://bitcointalk.org/index.php?topic=12.msg45#msg45",
		"q": "I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.",
		"a": "That's great because that's where I have less expertise. For instance, I haven't researched the best way to do the \"Start Bitcoin on system startup\" feature on Linux. On Windows, the option adds/removes an icon in the Startup folder."
	},
	{
		"id": 85,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "Hi, yesterday I stumbled upon this great payment option.\nI read my way through many sites but now I have some questions that couldn't get answered.\n1. Is Bitcoin really anonymous? I mean totally and completely? Is my ISP able to detect, that I have sent or received a Bitcoin payment? Maybe he is even able to see that I am running Bitcoin right now?\n2. If I understood this correctly, my payment partners are not able to see who I am. Does this mean, they can not see my real IP adress? Only the Bitcoin-adress? Even if they monitors their network connections and stuff?\n3. If there is a way for my ISP to tell that I am running Bitcoin or for my payment partners to find out my IP, would it be more safe to tunnel the network traffic through a VPN (payed with Paysafecard for example)? Could this be dangerous, because the VPN provider will be able to capture my payment?",
		"a": "1-3: For that level of anonymity you need to connect through TOR, which will be possible with version 0.2, which is only a few weeks away. I'll post TOR instructions at that time.\n"
	},
	{
		"id": 86,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "What files need to be backed up for not losing my \"money\"? Only the wallet.dat or the whole Bitcoin AppData directory ?",
		"a": "Version 0.1.5: backup the whole %appdata%\\Bitcoin directory.\nVersion 0.2: you can backup just wallet.dat."
	},
	{
		"id": 87,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "Isn't it possible to multiply a wallet and use it on different machines? This way you would double your money without doing anything for it.\nAre there security measures for this case?",
		"a": "Nope. The whole design is all about preventing that from working."
	},
	{
		"id": 88,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "When someone loses his wallet, will there be a way to recreate the lost coins in the system ? Else the 21 million maximum will not be correct.\n(I mean not to recover the lost coins for one person, but if all the 21mio coins were created, and someone loses his wallet with 1mio coins, will the the others be able to create these 1mio coins now or are they totally lost for the bitcoin network?)",
		"a": "Those coins can never be recovered, and the total circulation is less. Since the effective circulation is reduced, all the remaining coins are worth slightly more. It's the opposite of when a government prints money and the value of existing money goes down."
	},
	{
		"id": 89,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "I have read that there currently are about 130k blocks out there. At my pc it only shows me about 24k. Is there something wrong or is this a normal behaviour ?",
		"a": "It's currently 29,296 blocks. The circulation is the number of blocks times 50, so the current circulation is 1,464,800 bc.\nIf you only have 24k blocks, it must not have finished the initial block download. Exit bitcoin and start it again. Version 0.2 is better/faster at the initial block download."
	},
	{
		"id": 90,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "I`m afraid I didn't understand everything about the bitcoin creation. How many coins are created by a machine in 24h in average?",
		"a": "Typically a few hundred right now. It's easy now but it'll get harder as the network grows."
	},
	{
		"id": 91,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "I know that port 8333 should be forwarded to the bitcoin-running machine. Now I ask myself if this goes for the TCP or the UDP.\nAnd is this port required for generating coins? Or only for payment transactions?",
		"a": "Good question, it's TCP. The website needs to be updated to say TCP port 8333.\nThe port forwarding is so other nodes can connect to you, so it helps you stay connected because you are able to be connected with more nodes. You also need it to receive payments by IP address."
	},
	{
		"id": 92,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "I've seen that the source code for bitcoin is open for everybody. Can this be an actual danger? If the code is manipulated people can create more bitcoins than others, can't they? This would be a massive leak of security.",
		"a": "No, the other nodes won't accept that.\nBeing open source means anyone can independently review the code. If it was closed source, nobody could verify the security. I think it's essential for a program of this nature to be open source."
	},
	{
		"id": 93,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "I've seen a formula to calculate the coins that will be created in a certain amount of time. It had something to do with the maximum cpu speed and the availabe. Can't find it anymore, so I`m asking you to explain me the coin creating. Do slow machines produce as much coins as high-end ones?",
		"a": "Slower machines produce fewer coins. It's proportional to CPU speed."
	},
	{
		"id": 94,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "Are there any other exchanging systems or potential payment partners except for new liberty standard?",
		"a": "There are more coming."
	},
	{
		"id": 95,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "What happens when my system crashes? Is the wallet saved automatically or only when bitcoin gets closed manually? (Maybe even real-time saving when a coint is created or payment is made?)",
		"a": "It uses a transactional database called Berkeley DB. It will not lose data in a system crash. Transactions are written to the database immediately when they're received."
	},
	{
		"id": 96,
		"date": "2009-12-10 20:49:02",
		"src": "https://bitcointalk.org/index.php?topic=13.msg46#msg46",
		"q": "Is there a way to see how many bitcoins have been generated this far? And how old is Bitcoin already?\nI know .... Many many questions but I am really interested in your service and want to know everything before I start using it more frequently.",
		"a": "For now, you can just multiply the total blocks by 50. The Bitcoin network has been running for almost a year now. The design and coding started in 2007."
	},
	{
		"id": 97,
		"date": "2009-12-11 17:58:57",
		"src": "https://bitcointalk.org/index.php?topic=13.msg49#msg49",
		"q": "Wow, thanks alot for these detailed answers.\nBut today another question came to my mind.\nLets say we know, that our neighbar uses Bitcoin, and we also know that he will receive a payment soon (maybe because he owns an internet shop and accepts bitcoin as payment option).\nAlso, we know that he uses WLAN and his network is unsecured or weak protected. Same goes for router configuration.\nWe now could log into his router configuration, change the ip adresses for the forwarded port 8333 to our system ip.\nNow every payment would be received by our bitcoin client.\nIs this actually going to work ?\nI know this is highly criminal and the scenario is .. well, lets call it \"uncommon\", but in theory it should work, right ?\n(Not that I have an interest in harming people, but I know that criminal people will try many ways to get some money.)\nBTW: same should work when you are on a LAN party with unprotected router config.\nOr are these scenarios totally impossible because no matter which ip adress uses the port, the payment will go to the bitcoin or ip adress that was defined from the payer ?",
		"a": "That's true, with the send-to-IP option, you are sending to whoever answers that IP. Sending to a bitcoin address doesn't have that problem.\nThe plan is to implement an IP + bitcoin address option that would have the benefits of both. It would still use a different address for each transaction, but the receiver would sign the one-time-use address with the given bitcoin address to prove it belongs to the intended receiver."
	},
	{
		"id": 98,
		"type": "ignore",
		"date": "2009-12-11 19:27:55",
		"src": "https://bitcointalk.org/index.php?topic=12.msg50#msg50",
		"q": "Okay, let me get registered on SF and get you my username. I haven't used SF in years so I'll have to familiarize myself. Will this give me access to the current branch you fellows are currently working on? (0.2)\nI have been trying to think of the options that will be needed for the backend process. I wonder which would be better: a long set of command line switches or a configuration file. Hmm...\nI have a lot of servers spread across the globe. If we can get to the point where we have a working backend process that will run on FreeBSD I can run always-on seeds.\nI really think that having the download package contain a daily seed snapshot will improve the bootstrapping. I have seen instances on new test installs here where the application will sit with 0 connections / 1 block. Upon inspecting the debug.log I find that the IRC server (freenode, I believe) claims I am already connected and refuses to let me seed the application. (Just an example).\nI think that a simple network monitor plugin for Nagios would be helpful as well. Something that can emulate a connecting client, and retrieve a valid status code from the backend process. I have a lot of ideas.\nIn any event, I would like to help. I have a lot of time and a project like this one is very exciting.\nThanks for letting me be a part of it.",
		"a": "Right, the SVN has the almost-release-candidate 0.2 source, which can also be built and run on Linux. It hasn't been tested on FreeBSD."
	},
	{
		"id": 99,
		"type": "ignore",
		"date": "2009-12-11 19:27:55",
		"src": "https://bitcointalk.org/index.php?topic=12.msg50#msg50",
		"q": "If we can get to the point where we have a working backend process that will run on FreeBSD I can run always-on seeds.",
		"a": "That would be a big help. TOR users wouldn't have to worry about how to get seeded, and we wouldn't depend on IRC.\nIt can be run in a few simple modes without access to the UI if you don't mind a minimized window on the desktop. (0.1.5 doesn't have -min so it would be an open window)\nTo only run a seed:\nbitcoin -min -gen=0\nYou could sort of monitor it by looking at debug.log. To stop it, kill the process, the database won't mind.\nTo generate:\nbitcoin -min -gen\nTo get the generated bitcoins, you'd have to copy wallet.dat (with version 0.2) to a machine with a UI, swap in the wallet.dat, run bitcoin and transfer the coins to your main account. (With version 0.1.5 you'd have to copy the whole \"%appdata%/Bitcoin\" directory.) There is one caveat about copying wallet.dat: if you happened to kill the program at the exact moment that it generated a coin or received a payment, wallet.dat might not work by itself and you'd have to copy the whole directory."
	},
	{
		"id": 100,
		"type": "ignore",
		"date": "2009-12-11 19:27:55",
		"src": "https://bitcointalk.org/index.php?topic=12.msg50#msg50",
		"q": "I really think that having the download package contain a daily seed snapshot will improve the bootstrapping. I have seen instances on new test installs here where the application will sit with 0 connections / 1 block. Upon inspecting the debug.log I find that the IRC server (freenode, I believe) claims I am already connected and refuses to let me seed the application. (Just an example).",
		"a": "I see, that would happen with multiple nodes using the same NAT or VPN or some ISP that funnels everyone through a few proxy servers. I just committed a fix to SVN for this. If it gets \"433\" name already in use (it was error 433, right?), it'll retry with a non-address random username."
	},
	{
		"id": 101,
		"type": "ignore",
		"date": "2009-12-11 19:27:55",
		"src": "https://bitcointalk.org/index.php?topic=12.msg50#msg50",
		"q": "In any event, I would like to help. I have a lot of time and a project like this one is very exciting.",
		"a": "That's great, any help is really appreciated!"
	},
	{
		"id": 102,
		"date": "2009-12-12 17:52:44",
		"src": "https://bitcointalk.org/index.php?topic=12.msg54#msg54",
		"q": "Suggestion :\nSince the coins are generated faster on fast machines, many people will want to use their GPU power to do this, too.\nSo, my suggestion is to implement a GPU-computing support using ATI Stream and Nvidia CUDA.",
		"a": "The average total coins generated across the network per day stays the same. Faster machines just get a larger share than slower machines. If everyone bought faster machines, they wouldn't get more coins than before.\nWe should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network. It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility. It's nice how anyone with just a CPU can compete fairly equally right now."
	},
	{
		"id": 103,
		"type": "ignore",
		"date": "2009-12-12 18:17:10",
		"src": "https://bitcointalk.org/index.php?topic=12.msg55#msg55",
		"q": "I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST! I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?) and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next.",
		"a": "Mac support would be nice. wxWidgets really pays off for cross platform.\nPlease don't try PPC. PPC is big-endian and Bitcoin is little-endian, there would be endless endian bugs making it harder for me to debug the network if there's a potentially byte-swapping node out there. PPC is on its way out anyway.\nConsidered autoconf. Autoconf is a necessity for large projects with a quagmire makefile, but I think we're small enough that it's more optimal without it. I'd rather keep the makefile simple as long as possible."
	},
	{
		"id": 104,
		"type": "ignore",
		"date": "2009-12-12 18:17:10",
		"src": "https://bitcointalk.org/index.php?topic=12.msg55#msg55",
		"q": "I think that breaking bitcoin into two apps is ideal. A wxwidgets front end (since it is mostly all there) and a backend that binds to a control TCP socket. I have been reading over the source to see how hard it would be to break it apart and I think it should be fairly simple. Of course an API would have to be developed.",
		"a": "My head hurts just thinking about that. Funnelling all the UI backend through a TCP connection would make everything twice as hard. There's too much bandwidth between the UI and the internal data structures in order to keep the listview control updated, because of the way the listview control works.\nI'd rather have command line control, that would get us remote admin and batch automation."
	},
	{
		"id": 105,
		"type": "ignore",
		"date": "2009-12-13 16:51:25",
		"src": "https://bitcointalk.org/index.php?topic=12.msg62#msg62",
		"q": "One quick question about \"natural deflation\" (as I call it). I have noticed that it is possible to spend to old addresses that no longer work. In essence the coins can not be claimed. Wouldn't there be a natural deflation effect because of this? I mean if the coins max out at 21,000,000 wouldn't the number of coins slowly work backwards due to payment errors?",
		"a": "There would be a command line switch at runtime to tell it to run without UI. All it needs to do is not create the main window. A simplistic way would be to disable \"pframeMain->Show\" and \"ptaskbaricon->Show\" in ui.cpp. The network threads don't care that the UI isn't there. The only other UI is a message box in CheckDiskSpace if it runs out of disk space.\nThen a separate command line utility to communicate with it to do things. Not sure what it should be named.\n\"natural deflation\"... I like that name for it. Yes, there will be natural deflation due to payment mistakes and lost data. Coin creation will eventually get slow enough that it is exceeded by natural deflation and we'll have net deflation."
	},
	{
		"id": 106,
		"type": "ignore",
		"date": "2009-12-14 17:15:56",
		"src": "https://bitcointalk.org/index.php?topic=12.msg67#msg67",
		"q": "Can anyone shed some light here?\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I\"/usr/include\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/include\" -I\"/usr/local/boost_1_41_0\" -I\"/sw/include/db4\" -I\"/usr/local/ssl/include\" -I\"/usr/local/lib/wx/include/mac-ansi-release-2.8\" -o headers.h.gch headers.h\n...\nui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'\n/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)",
		"a": "It looks like the implicit conversion from std::string to wxString isn't working. That's used everywhere, the conversion needs to work.\nwxString is complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile. You can get that problem on Windows if the \"unicode\" (meaning wchar) build is used, so that wxString is wchar and std::string is char.\nIt's probably some wxWidgets compile defines or build configuration. What \"configure\" options did you use?\nI'm not sure __WXMAC__ is the right define. It may be the Mac Classic support that's complicating wxString, and we only want OSX. Try __WXOSX__ (or see below)\nhttp://docs.wxwidgets.org/stable/wx_cppconst.html\n\"There are two wxWidgets ports to Mac OS. One of them, wxMac, exists in two versions: Classic and Carbon. The Classic version is the only one to work on Mac OS version 8. The Carbon version may be built either as CFM or Mach-O (binary format, like ELF) and the former may run under OS 9 while the latter only runs under OS X. Finally, there is a new Cocoa port which can only be used under OS X. To summarize:\n* If you want to test for all Mac platforms, classic and OS X, you should test both __WXMAC__ and __WXCOCOA__.\n* If you want to test for any GUI Mac port under OS X, use __WXOSX__.\n* If you want to test for any port under Mac OS X, including, for example, wxGTK and also wxBase, use __DARWIN__\""
	},
	{
		"id": 107,
		"type": "ignore",
		"date": "2009-12-15 20:37:32",
		"src": "https://bitcointalk.org/index.php?topic=12.msg70#msg70",
		"q": "It is also throwing the same std::string issue on the latest version of Ubuntu Linux.",
		"a": "Then it must be something you're doing differently with building or configuring wxWidgets.\nWhat options did you use on the wxWidgets \"configure\" script? The options I used are in build-unix.txt."
	},
	{
		"id": 108,
		"type": "ignore",
		"date": "2009-12-15 20:37:32",
		"src": "https://bitcointalk.org/index.php?topic=12.msg70#msg70",
		"q": "One question: how do I enable the debug.log? I have tried stopping bitcoin and touching ~/.bitcoin/debug.log and starting bitcoin again. It never seems to write to the file. Am I missing something?",
		"a": "Never heard of that happening. Is there anything in debug.log? If you touched the file, that sounds like something is there. Does the program have write access to the file?"
	},
	{
		"id": 109,
		"type": "ignore",
		"date": "2009-12-17 18:38:06",
		"src": "https://bitcointalk.org/index.php?topic=12.msg77#msg77",
		"q": "To build on FreeBSD:\nInstall all of the required software from /usr/ports and then compile using the makefile.fbsd\n\"It just works\".",
		"a": "That's good, is it running fine on FreeBSD?\nI committed the changes to headers.h. For consistency, I used __BSD__. The complete list of defines is at http://docs.wxwidgets.org/stable/wx_cppconst.html\n#ifdef __BSD__\n#include <netinet/in.h>\n#endif\nmalloc.h is only needed on windows, I'll move that into the __WXMSW__ section before it causes any more trouble."
	},
	{
		"id": 110,
		"type": "ignore",
		"date": "2009-12-18 17:37:48",
		"src": "https://bitcointalk.org/index.php?topic=12.msg79#msg79",
		"q": "Hi. I would like to second the headless/non-GUI mode for /*nix/i systems. It would be useful to be able to start the Bitcoin software from an initscript or one's ~/.bashrc (or equivalent) file and let it run in the background, silently cranking away.\nAlso, what would the feasibility of changing the location of the wallet.dat file be for the Win32 client? I ask this because I was playing around with the .zipped Windows Bitcoin client yesterday, and it struck me that it would make a good portable application. I was toying with the idea of decompressing it into a TrueCrypt volume on a USB drive so that it could, say, be taken on the road, run for a few hours, and then shut down just before the volume was unmounted, but it created the wallet.dat file in the C:\\Documents and Settingsame\\Application Data\\Bitcoin directory. In effect, using a portable version of Bitcoin to eventually grow a portable wallet.",
		"a": "What you can currently do is set \"Minimize to the tray\" in options, then run it as \"bitcoin -min\" so it starts minimized. The only visible part will be a small (20x20) icon on the tray, which can be doubleclicked if you want to access the UI. Note: there's a bug with tray icons sometimes disappearing on 64-bit Karmic Koala, not sure if it's from 64-bit or Karmic, it was fine on 32-bit Jaunty.\nWe didn't have time to implement the \"Start Bitcoin on system startup\" feature on Linux in time for 0.2 so it's greyed out. I figured Linux people wouldn't mind doing that manually anyway. I guess they need to know about the -min switch to do it right.\nYou can locate the data directory where you want with the \"-datadir=<directory>\" switch. I know someone is already doing that to put it on a TrueCrypt USB drive."
	},
	{
		"id": 111,
		"type": "ignore",
		"date": "2010-01-05 20:00:46",
		"src": "https://bitcointalk.org/index.php?topic=17.msg85#msg85",
		"q": "Other nodes aren't going to know which IP you're sending to, your client just connects directly to it. Both IP's are fine as long as the connection routes to the right computer. Anyway, I'd use the inner address inside a network for simplicity.",
		"a": "The transfer is immediate if you send by IP address. If you send by bitcoin address and the recipient isn't online at the time, it might take 30 minutes or more to see it.\nAlso, the recipient needs to be synced up with the block chain before it'll see the received transaction. That means the status bar at the bottom needs to say at least 33000 blocks, like \"x connections 33200 blocks x transactions\"."
	},
	{
		"id": 112,
		"type": "ignore",
		"date": "2010-01-05 20:00:46",
		"src": "https://bitcointalk.org/index.php?topic=17.msg85#msg85",
		"q": "The number of blocks of a transaction is the amount of new blocks that have been generated by the whole network after the transaction. Each new block in the chain means new coins to its creator. One \"generated\" -transaction in your transaction list means that you have generated one block. You're not the first one to find the concept of a \"block\" a bit confusing on the first sight.",
		"a": "Would it be clearer if the status said \"x confirmations\", like:\n2/unconfirmed\n3/unconfirmed\n4/unconfirmed\n5/unconfirmed\n6 confirmations\n7 confirmations\n8 confirmations\nEach block essentially means another node has confirmed that it agrees with all transactions up to that point."
	},
	{
		"id": 113,
		"type": "ignore",
		"date": "2010-01-14 20:17:20",
		"src": "https://bitcointalk.org/index.php?topic=18.msg97#msg97",
		"q": "Can bitcoin be compiled to run on 64 bit systems yet? -m64 seems to break the compile.\n(Not trying to nag or anything).\nOn a side node: I have noticed that the network is about 3x larger than normal now. I see more nodes!",
		"a": "I haven't tried compiling 64-bit yet. 64-bit wouldn't make it any faster, since it uses 64-bit numbers in only a few places and SHA-256 is a 32-bit algorithm, but it may be convenient for those running a 64-bit OS. If I get a chance I'll try -m64 and see what the problem is.\nYou can run the 32-bit version on 64-bit Linux by installing ia32-libs. (sudo apt-get install ia32-libs) If we made a Debian package, it could automatically pull that in as a dependency."
	},
	{
		"id": 114,
		"date": "2010-01-20 20:07:15",
		"src": "https://bitcointalk.org/index.php?topic=21.msg112#msg112",
		"q": "What exactly does the number of connections do for me? Do I generate more coins with more connections, or is it equivalent no matter what?\nIt seems that from time to time, Tor gets tied up and can go for a few hours with 3 or 4 connections. Then, when I restart bitcoin or restart Tor to refresh my connections, I can get 7,8, or even more (9 currently).\nI haven't really been able to tell if coins generate slower or not with less connections, but I was curious if it does correlate. If not, how exactly will having more connections help me out compared to less?",
		"a": "Coins generate at the same speed with any number of connections >= 1.\nMore connections just add redundancy. If you only had one connection, what if that node is slow or busy, or only connected to you? Having several connections increases the certainty that you're well connected to the network. That hasn't been a problem in practice, the network is very thoroughly connected. If you have 2 or 3 connections, you're fine."
	},
	{
		"id": 115,
		"date": "2010-01-20 22:05:28",
		"src": "https://bitcointalk.org/index.php?topic=22.msg113#msg113",
		"q": "Hello,\nI have had another idea.\nIt would be very cool to be able to have TOR and I2P seeds. For example: I could run BT within TOR-land on a .onion address. A client could connect their BT to TOR and have it seed from a .onion address and use it as a connected peer. (Likewise for I2P: someone could run a .i2p service that is -- well -- BC).\nI might setup a couple of nodes in this fashion and post the tunnels on this forum. I already run a lot of I2P and TOR nodes so adding BC to the mix is quite trivial.\nI support the idea of making BC compatible with TOR and I2P to increase the privacy of the system. I mean: why re-invent the wheel? There are thousands of mix network nodes just sitting there that can be used to enhance BC.\nCheers!",
		"a": "I've been thinking about that for a while. I want to add the backend support for .onion addresses and connecting to them, then go from there.\nThere aren't many .onion addresses in use for anything because the user has to go through a number of steps to create one. Configure TOR to generate a .onion address, restart TOR, configure it with the generated address. Perhaps this is intentional to keep TOR so it can't be integrated into file sharing programs in any sufficiently automated way."
	},
	{
		"id": 116,
		"type": "ignore",
		"date": "2010-01-27 21:52:27",
		"src": "https://bitcointalk.org/index.php?topic=27.msg156#msg156",
		"q": "Lately when I've been trying to send coins, the following popups twice, then the application terminates.\nEXCEPTION: St13runtime_error\nSendMoney() : wtxNew.AcceptTransaction() failed\nc:\\Documents and Settingsame\bitcoin-0.2.0\bitcoin.exe in\nCMyApp::OnExceptionInMainLoop()\nWhen i restart bitcoin.exe, the transaction is showing as 0/unconfirmed. The status do not change even when the total block count increases.\nI'm running two instances of bitcoin in my home LAN, one at my desktop computer, and one in a virtual machine on my laptop, with the switch -connect=192.168.0.2 (ip of desktop computer).\nThis occurs when I send to my own bitcoin address, to my other computers bitcoin address and to an other bitcoin address not currently active anywhere. I'm not sending by ip.\nI've been moving wallets and index-files back and forth, could this have something to do with this?",
		"a": "That is what happens if you copy wallet files around. If you copy your wallet file to a second computer, then they both think the money in the wallet is theirs. If one spends any of it, the other doesn't know those coins are already spent and would try to spend them again, and that's the error you would hit.\nNow that it's clear this is a key error message, it ought to be something more like \"the money appears to be already spent... this could happen if you used a copy of your wallet file on another computer.\"\nYou can move or backup your wallet file, but it needs to have only one \"lineage\" and only used in one place at a time. Any time you transfer money out of it, then you must no longer use any previous copies.\nThis brings up a good point. In the case of restoring a backup that may be from before you spent some coins, we need to add functionality to resync it to discover which coins have already been spent. This would not be hard to do, it just hasn't been implemented yet. I'll add it to the list. This would make it mostly repair the situation instead of giving that error message."
	},
	{
		"id": 117,
		"date": "2010-01-28 01:01:48",
		"src": "https://bitcointalk.org/index.php?topic=25.msg159#msg159",
		"q": "I think it was some technical limitation. Satoshi could tell more about this?",
		"a": "Yes, it's a technical limitation. Sending by bitcoin address enters the transaction into the network and the recipient discovers it from the network. You don't connect directly with them and they don't have to be online at the time.\nI very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message. As much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen.\nUnfortunately, ECDSA can only sign signatures, it can't encrypt messages, and we need the small size of ECDSA. RSA can encrypt messages, but it's many times bigger than ECDSA."
	},
	{
		"id": 118,
		"type": "ignore",
		"date": "2010-01-28 01:08:33",
		"src": "https://bitcointalk.org/index.php?topic=28.msg160#msg160",
		"q": "Yes it will.\nImportance is relative. You can use the number of blocks to calculate some statistics. Also, if you press ctrl+[numpad+], you will see the serial number and hash of the blocks. (At least on windows).",
		"a": "Where it says \"# blocks\" in the status column I'm changing it to say \"# confirmations\". That might be clearer.\nIf you doubleclick on the transaction you get a little more information."
	},
	{
		"id": 119,
		"date": "2010-01-28 23:08:02",
		"src": "https://bitcointalk.org/index.php?topic=27.msg170#msg170",
		"q": "Yes, I thought it had something to do with that.\nIt would be nice if there was a wallet tool for merging wallet files, removing unused bitcoin addresses and as you say resyncing. (I tried to just re-download all the blocks, but as you know the transactions stayed anyway.)\nWhat about resyncing in the future when the Merkle-tree is pruned?",
		"a": "The resync idea would go through your wallet and check it against the block index to find any transactions that your current computer doesn't realize are already spent. That could happen if they were spent on another computer with a copy of the wallet file, or you had to restore the wallet to a backup from before they were spent. Currently, the software just assumes it always knows whether its transactions are spent because it marks them spent in wallet.dat when it spends them.\nA wallet merge tool is possible to implement but much less in demand once resync solves most of the problem. With resync, you could do about the same thing by sending all the money from one wallet to the other. The receiver would resync and discover all its overlapping coins were spent, then receive them in the new transaction."
	},
	{
		"id": 120,
		"type": "ignore",
		"date": "2010-01-28 23:26:09",
		"src": "https://bitcointalk.org/index.php?topic=29.msg172#msg172",
		"q": "Satoshi, when we may expect the new command line-abled version of Bitcoin? Or is it possible to compile Bitcoin 0.2 in a way it can be used by command lines?",
		"a": "That's the right way to do it as riX says. The software can generate a new bitcoin address whenever you need one for each payment. \"Please send X bc to [single-use bitcoin address] to complete your order\" When the server receives that amount to the bitcoin address, that could trigger it to automatically fulfil the order or e-mail the shop owner.\nAdding command line support is a high priority. It's just a matter of getting the time to code it."
	},
	{
		"id": 121,
		"date": "2010-01-29 00:22:13",
		"src": "https://bitcointalk.org/index.php?topic=25.msg173#msg173",
		"q": "Why don't you make them send the email before the transaction? Then you could reply to that email with a new and unique bitcoin address. You don't even need to use email, it would be equally secure, although not that anonymous, to announce the customers email together with the bitcoin address on the frontpage of your site.\nThe method you are using now is equal to someone sending you cash in an envelope anonymously, including a note with the time he posted it, after which you send goods back to the first person calling you stating the time and amount in the envelope. (Including the mailman and anyone who has access to you mailbox).\nSending the email before the transaction is equal to someone calling you, getting a unique box address which to send the money to. When the money arrives to that post box, you send the goods to the customer.",
		"a": "The recommended ways to do a payment for an order:\n1) The merchant has a static IP, the customer sends to it with a comment.\n2) The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address. This will be the standard way for website software to do it.\nRSA vs ECDSA: it's not the size of the executable but the size of the data. I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger. Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part. In that case, everything that's been implemented up to now would be implemented exactly as it has been.\nWe can figure out the best way to do this much later. It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message. The message would have to include a salt so nobody could brute force the hash to reveal a short message."
	},
	{
		"id": 122,
		"type": "ignore",
		"date": "2010-01-29 00:42:49",
		"src": "https://bitcointalk.org/index.php?topic=18.msg174#msg174",
		"q": "I second the request for 64-bit support, even if it wouldn't make the app run faster. I'm no expert, but I can't see any harm in it. On the other hand, it's a good way to embrace the future.",
		"a": "I committed a fix for 64-bit compile and some fixes to support wxWidgets 2.9.0.\nThere was one compile error in serialize.h with min(sizeof()) that I fixed for 64-bit. The rest of the 64-bit compile errors I was getting were in wxWidgets 2.8.9, so I started working on supporting wxWidgets 2.9.0.\nwxWidgets 2.9.0 is UTF-8. We've been using the ANSI version of wxWidgets 2.8.9 in anticipation of wxWidgets UTF-8 support.\nI compiled and ran on 64-bit Ubuntu 9.10 Karmic.\nI think the only bug left is where the status number is mashed up. I'm not sure why, I have to suspect it's a UTF-8 thing, but no idea how that could happen. Haven't looked into it.\nbuild-unix.txt is updated and two makefiles on SVN:\nmakefile.unix.wx2.8\nmakefile.unix.wx2.9\nUnfortunately there's still no debian package for either version of wxWidgets we use. They only have the wchar (\"unicode\") version of wxWidgets 2.8, which is a disaster because wchar wxString doesn't convert to std::string. We use either ANSI wxWidgets 2.8, or wxWidgets 2.9. So you still have to get it and build it yourself."
	},
	{
		"id": 123,
		"type": "ignore",
		"date": "2010-02-03 23:36:54",
		"src": "https://bitcointalk.org/index.php?topic=35.msg220#msg220",
		"q": "I wanted to document an issue I encountered when first installing and using the Bitcoin software.\nDespite a correct installation and port forward settings I noticed that Bitcoin was not generating any coins or 'blocks' despite having 20+ connections for the first 24hrs. The block count just remained at 0. After realizing that Bitcoin was not 'catching up' with the collective network block download or generation I opened up the Task Manager to investigate the issue further.\nI noticed that the bitcoin.exe process seemed to be 'fighting' for CPU usage against MsMpEng.exe (Microsoft Security Essentials). I hadn't noticed any system slowdown due to having a fairly high spec. PC. After adding bitcoin.exe and the appropriate program folder locations to Exclude 'Files and Locations' and 'Exclude Processes' - Bitcoin instantly started generating blocks and the CPU processes returned to normal.\nI did not have any virus alerts or even 'false positive' identifications for Bitcoin. I know that the software is 100% OK. I'm assuming that the 'Live Protection' engine in Microsoft Security Essentials just doesn't 'play well' with some aspect of the CPU hungry cycles used in 'block' generation.\nI have yet to do more testing, however I also encountered the same issue when using Comodo Internet Security (free version).\nThis is obviously going to be an issue for lots of new Bitcoin users who will perhaps be less 'tech savvy'. Has anyone else encountered any similar issues ?",
		"a": "Thanks for that. Which version of Windows?"
	},
	{
		"id": 124,
		"date": "2010-02-04 00:07:07",
		"src": "https://bitcointalk.org/index.php?topic=34.msg222#msg222",
		"q": "Not so ? I have had 2 machines connected (getting 4+ connections on each) and generating Bitcoins on the same static IP address. The port 8333 is of course forwarded for connection through my firewall, which I guess is what you mean. However, connections to other nodes are made without port 8333 being specifically forwarded through my router to a specific machine (sub-net IP), which is of course the best way to max connectivity. I understand Bitcoin only requires 1 other connection for transactions, yes ?\nI think my original question was valid and thanks for clarifying this everyone. NewLibertyStandard I think is correct \"If I remember correctly I think I was told that they would be sent to the first bitcoin application with whom the sender connects.\"\nI dislike communication on forums, it's hard to discuss topics sometimes when all parties mean the same thing and communicate it in a different way !\nI have enough internet connections, routers and PC equipment - So, I'm off to make an 'official' test for myself whilst I RTM",
		"a": "Port forwarding forwards a port to one computer. It tells the router which computer handles connections to that port. So that's the computer receiving.\nIf you didn't set up port forwarding, then incoming connections won't go to any computer, and attempts to send to that IP would just say it couldn't connect to the recipient and nothing is sent. When sending by IP, you still send to a bitcoin address, but your computer connects to that IP, gets a new bitcoin address from it, gives the transaction directly to the them and confirms that it was received and accepted.\nSomeone should post their static IP so people can try out sending by IP and also give that user free money.\nThere's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address.\nIf 4) you send to a recipient who has abandoned or lost their wallet.dat, then the money is lost. A subtle point can be made that since there is then less total money in circulation, everyone's remaining money is worth slightly more, aka \"natural deflation\"."
	},
	{
		"id": 125,
		"type": "ignore",
		"date": "2010-02-04 00:30:50",
		"src": "https://bitcointalk.org/index.php?topic=22.msg223#msg223",
		"q": "OK thanks riX.\nSo, once Bitcoin has connected to at least one node then the -connect option will eliminate the 6667 warnings.\nIs Bitcoin using any kind of 'peer exchange' or DHT because this still does not seem to prevent the constant Tor 'exit' warnings and therefore Tor's requirement to try a new 'exit' node for connection. (which is problematic ! For Tor anyway, not Bitcoin ) This is really what I meant by \"However, Bitcoin must try to connect with all nodes to check its not missing any blocks ?\" I just communicated it incorrectly.\nI2P would seem to be a much easier solution to implement to increase a Bitcoins users anonymity.\nhttp://forum.i2p2.de/viewtopic.php?t=3946&sid=213e3cd998db98c4511675ecbba17af4\nI'm also testing JonDonym http://anonymous-proxy-servers.net/ (only the paid services support socks !) However, they do accept paysafecards which can currently be brought in exchange for Bitcoins.",
		"a": "When using proxy port 9050, it will only make one attempt to connect to IRC, then give up, since it knows it will probably always fail because IRC servers ban all the TOR exit nodes. If you're using another port, it would assume it might be a regular old normal proxy and would keep retrying IRC at longer and longer intervals. You should not use Polipo or Privoxy as those are http filters and caches that would corrupt Bitcoin's messages if they make any changes. Bitcoin might be trying to overcome it by reconnecting. You should use port 9050.\nAs riX says, the \"is giving Tor only an IP address. Apps that do DNS...\" warnings are nothing to worry about. Bitcoin doesn't use DNS at all in proxy mode.\nSince Bitcoin can't get through to IRC through Tor, it doesn't know which nodes are currently online, so it has to try all the recently seen nodes. It tries to conserve connection attempts as much as possible, but also people want it to connect quickly when they start it up and reconnect quickly if disconnected. It uses an algorithm where it tries an IP less and less frequently the longer ago it was successful connected. For example, for a node it saw 24 hours ago, it would wait 5 hours between connection attempts. Once it has at least 2 connections, it won't try anything over a week old, and 5 connections it won't try anything over 24 hours old."
	},
	{
		"id": 126,
		"date": "2010-02-05 19:44:46",
		"src": "https://bitcointalk.org/index.php?topic=34.msg250#msg250",
		"q": "Perhaps there should be a feature against this? For instance, if a transaction isn't accepted by the recipient for a long period of time (a month?), the transaction will be canceled and the coins returned to the one who sent them?",
		"a": "That's not possible. You've handed control of the money over to the recipient's keypair. Only that key can control it.\nIt's similar to if you encrypt a file with AES and a strong password, and you lose the password. The data is lost."
	},
	{
		"id": 127,
		"date": "2010-02-06 21:06:32",
		"src": "https://bitcointalk.org/index.php?topic=7.msg264#msg264",
		"q": "Someone correct me people, but I thought it IS already anonymous! Can the person I'm transferring money to know my IP or something?",
		"a": "When you send to a bitcoin address, you don't connect to the recipient. You send the transaction to the network the same way you relay transactions. There's no distinction between a transaction you originated and one you received from another node that you're relaying in a broadcast. With a very small network though, someone might still figure it out by process of elimination. It'll be better when the network is larger.\nIf you send by IP, the recipient sees you because you connect to their IP. You could use TOR to mask that.\nYou could use TOR if you don't want anyone to know you're even using Bitcoin.\nBitcoin is still very new and has not been independently analysed. If you're serious about privacy, TOR is an advisable precaution."
	},
	{
		"id": 128,
		"date": "2010-02-06 23:25:53",
		"src": "https://bitcointalk.org/index.php?topic=44.msg267#msg267",
		"q": "Removing or extending the 21M limit would be a disaster, it's the finite supply of this digital cash that makes it useful as money.\nAllowing for the currency to be further divided would solve that issue. No one loses the value of any of their currency held(devaluation or debasing), while at the same time being able to break off smaller pieces of a ฿ to trade.\nBesides, the whole point is that there is no (central)control over the supply, this would allow it to be extinguished by governments or abused by a central authority (like today's central banks & governments)\nI am wondering Satoshi, what would be the technical difficulty of implementing ฿ as 0.000(or more zeroes) instead of 0.00?\nThis is not a request since there is no need for it yet, but may wish to acommadate a larger user base in the future.",
		"a": "Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.\nBut don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally. It shows 1.00 but internally it's 1.00000000. If there's massive deflation in the future, the software could show more decimal places.\nIf it gets tiresome working with small numbers, we could change where the display shows the decimal point. Same amount of money, just different convention for where the \",\"'s and \".\"'s go. e.g. moving the decimal place 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00."
	},
	{
		"id": 129,
		"date": "2010-02-08 01:22:29",
		"src": "https://bitcointalk.org/index.php?topic=45.msg278#msg278",
		"q": "Is there a high-res bitcoin logo? Or a vector-image?",
		"a": "No, sorry. I've been meaning to redo it. The largest icon that still looks good is the 20x20 one which is used for the tray icon in GNOME. Any larger than that looks bad. The 16x16 and 20x20 ones have quite a bit of hand tweaking to get the pixels to work out right. If you just scale down a larger image, the pixels end up blurred and awkward in places where the lines in \"BC\" don't land square on a pixel.\nThe best 16x16 with full alpha channel is in src/rc/bitcoin.ico. I don't like the 32x32 version.\nI'm attaching bitcoin20x20.png, the 20x20 version with full transparency."
	},
	{
		"id": 130,
		"type": "ignore",
		"date": "2010-02-08 16:10:37",
		"src": "https://bitcointalk.org/index.php?topic=47.msg283#msg283",
		"q": "I am running Windows 32 (But have AMD64 dual core machine), but could, if required have a version of Linux using virtualisation(I must install this).\nThe most simple way at present is to have different language binaries(e.g. bitcoin_en.exe, bitcoin_zh.exe etc.). Please post when you want this translated, this would mean there could be a dual language release for the next version (Why not a tri-language release, you do speak Japanese no?).",
		"a": "It's much easier to have a single binary and multiple .mo files. It's too much maintenance work to have lots of build variations. Once the software support is implemented, anyone could contribute translations.\nwxWidgets uses the gettext standard. You use the gettext tools or something like poedit to create a .po file by scanning the sourcefiles for strings and editing the translations into the .po file, then compile it into a .mo file. The program loads the .mo file at runtime and reskins all the strings. Additional languages can be added to an existing program by adding .mo files without recompiling the program.\nOn Windows, the .mo files would go in a lang subdirectory in the directory where the EXE is located.\nRight now I'm working on JSON-RPC and command line support, but when I'm finished with that I hope to do this next."
	},
	{
		"id": 131,
		"type": "ignore",
		"date": "2010-02-08 16:37:24",
		"src": "https://bitcointalk.org/index.php?topic=46.msg284#msg284",
		"q": "First request:\nOptional connect to IP dialog.\nBitCoin connects to the network(of peers) by getting one of a number of IP's from IRC at present, once connected to a single peer other connections can be made, so if only 1 IP on the list are available then you can connect to the network & make connections to other IP's(this is my assumption, please correct me if I am wrong).\nThis is somewhat similar to how Tor works, when you first start it up it attempts to connect to a public list of IP's(public bridge nodes). This list being public is accessible to organisations that want to prevent the use of Tor(for example the Chinese or Iranian government). And so as a consequence these IP's are blocked, and you cannot connect from these countries.\nHowever there is the option to connect to the ip of a bridge (if you know one, a friend in a free country running Tor in bridge mode perhaps) and so this circumvents regime blocking attempts and is very robust.\nAdding this feature will allow Bitcoin to function despite regime efforts to prevent it.",
		"a": "There are command line options:\nbitcoin -addnode=1.2.3.4 to tell bitcoin about a node to connect to\nbitcoin -connect=1.2.3.4 connect only to the specified node(s)\nYou can use more than one of these, for instance\nbitcoin -connect=(first to try) -connect=(next to try) ...\nYou can specify non-routable IPs with -connect like 192.168.x.x, so if you had a server farm and you wanted one server to connect to the world and the rest to connect to the one server, you could do that.\nIn particular, -addnode is needed if you're always going to connect through TOR, since the IRC server blocks all the TOR exit nodes. To connect through TOR, you could use:\nbitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216"
	},
	{
		"id": 132,
		"type": "ignore",
		"date": "2010-02-12 02:33:02",
		"src": "https://bitcointalk.org/index.php?topic=49.msg315#msg315",
		"q": "I am having 0 luck attempting to compile w/wxWidgets. Trying to compile wx from source was a no-go (various syntax errors I didn't really delve into), downloaded latest precompiled wx packages for ubuntu karmic, but they do not match up to your static links far as I can tell. I guess what I'm getting at is, rather than try to sort out these issues, I'd really love a .deb <.< I'd like to participate - as an agorist and a fan of cryptoanarchic theory this is sort of a fantasy of mine, but there is frankly no way I will dual boot windows or run this in as insecure an environment as a VM.\nDEB isn't a bad route, you'll hit the vast majority of desktop linux users, most of whom won't be buggered to try compiling in the first place, so I don't think it's entirely unreasonable. Alternatively if you are interested in helping me work out compilation issues I would be happy to provide x86_64 binaries for ubuntu as long as I am compiling them. I haven't done .debs before but I am sure I can figure that out. Let me know",
		"a": "Are you just trying to run the program or do you really need to compile it? There's a 32-bit linux binary that can be run on 64-bit ubuntu if you \"sudo apt-get ia32-libs\".\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download\nI recently updated the SVN for building on 64-bit Karmic with wxWidgets 2.9.0. This was after the 0.2.0 release. The 0.2.0 release did not build on 64-bit yet.\nUnfortunately there currently isn't a -dev deb package of either of the versions of wxWidgets that we can use. On Karmic they only have the UTF-16 version. We need either the ANSI (libwxgtk2.8-ansi-dev) version or the UTF-8 (wxWidgets 2.9.0) version. We're moving towards 2.9.0.\nI know you said you didn't want VM, but as a last resort, last I checked the Windows version runs fine in Wine."
	},
	{
		"id": 133,
		"date": "2010-02-12 03:08:08",
		"src": "https://bitcointalk.org/index.php?topic=48.msg316#msg316",
		"q": "That is odd !?! I've currently only had 50.00 generations myself.",
		"a": "There's a small transaction fee for very large transactions. The node that generates the block that contains the transaction gets the fee.\nIf the same money gets sent again, it won't incur the fee again. If all you have is generated coins in your wallet, if you send them all in one huge transaction, it has to bundle hundreds of 50 bc coins together. After that it's just one line to send the combined unit."
	},
	{
		"id": 134,
		"type": "ignore",
		"date": "2010-02-12 15:57:37",
		"src": "https://bitcointalk.org/index.php?topic=49.msg322#msg322",
		"q": "If you want, I can provide you with a precompiled binary.",
		"a": "Am I missing something? Is there something wrong with the 32-bit linux precompiled binary on bitcoin.org?\nThe bitcoin binary in the distribution static links the wxWidgets library, and its shared links (openssl and GTK) are included in Ubuntu, so it can run without needing to be a .deb to pull down dependencies.\nSince we're upgrading to wxWidgets 2.9.0 for UTF-8, which doesn't have a DEB package yet, we'll continue to need to static link it."
	},
	{
		"id": 135,
		"date": "2010-02-12 17:28:32",
		"src": "https://bitcointalk.org/index.php?topic=7.msg324#msg324",
		"q": "Tor can be dangerous, like exit nodes that log information like passwords and the like.\nSo a major question about the security of Bitcoin when using it with Tor (or any other proxy service) arises:\nSo what exactly does Bitcoin send when it connects to an IP?Is everything encrypted that we send over the line?Can someone 'steal' bitcoins by listening at the end of a proxy (or in Tor's case an \"exit node\")?\nSpeaking of security, we might just want to add a simple version checking procedure in bitcoin that will alert a user if s/he is running an \"insecure version of bitcoin\".",
		"a": "True, sending by IP through Tor trades one problem for another. The Tor exit node can see the text of your message and potentially MITM you.\nBest to only send to bitcoin addresses then. Payments by bitcoin address are broadcast over the network as part of the normal network traffic. All communications with the network are broadcasts of public information."
	},
	{
		"id": 136,
		"type": "ignore",
		"date": "2010-02-13 01:38:37",
		"src": "https://bitcointalk.org/index.php?topic=49.msg326#msg326",
		"q": "Sorry, I should have mentioned more clearly that I am running AMD64. I was trying to compile with 0.2.0, so that would explain a lot of my issues. I *would* like to have a native 64 bit binary, but it sounds like that isn't going to happen right now. I have ia32-lib already, I'll try running what you've supplied, and failing that Wine might be an option. Thanks for the help. I don't remember coming across SVN links on the download page, but once you get up to wxWidgets2.9 I may try again. I could *not* get 2.8.10 to compile for me, I'm sure I probably was overlooking something, but it sounds like 2.9 at least resolves the utf-8/ansi issue",
		"a": "I couldn't get wxWidgets 2.8.9 to compile on Karmic 64-bit either.\nI have been compiling the latest SVN on Karmic 64-bit with wxWidgets 2.9.0, which compiles fine on 64-bit. Read build-unix.txt and use the given ../configure parameters on wxWidgets so you can use the makefile.unix.wx2.9 as supplied. (--enable-debug --disable-shared --enable-monolithic)\n-- fixed\nThe download link on the homepage is to the sourceforge tar.gz archive which contains the 32-bit binary and the 0.2.0 sources, which were not yet buildable on 64-bit at the time.\nThe SVN was first buildable on 64-bit with wx2.9.0 on 28 January 2010.\nHopefully they'll have a wxWidgets 2.9.0 debian package someday."
	},
	{
		"id": 137,
		"date": "2010-02-14 06:28:03",
		"src": "https://bitcointalk.org/index.php?topic=48.msg327#msg327",
		"q": "Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)?",
		"a": "Yes."
	},
	{
		"id": 138,
		"date": "2010-02-14 06:28:03",
		"src": "https://bitcointalk.org/index.php?topic=48.msg327#msg327",
		"q": "why do we even need fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?!",
		"a": "Almost all transactions are free. A transaction is over the maximum size limit if it has to add up more than 500 of the largest payments you've received to make up the amount. A transaction over the size limit can still be sent if a small fee is added.\nThe average transaction, and anything up to 500 times bigger than average, is free.\nIt's only when you're sending a really huge transaction that the transaction fee ever comes into play, and even then it only works out to something like 0.002% of the amount. It's not money sucked out of the system, it just goes to other nodes. If you're sad about paying the fee, you could always turn the tables and run a node yourself and maybe someday rake in a 0.44 fee yourself."
	},
	{
		"id": 139,
		"date": "2010-02-14 15:52:23",
		"src": "https://bitcointalk.org/index.php?topic=48.msg329#msg329",
		"q": "Is the fee enough to always ensure the profitability of running a node, even when BitCoin generation stops being profitable?",
		"a": "Right. Otherwise we couldn't have a finite limit of 21 million coins, because there would always need to be some minimum reward for generating. In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes. I'm sure that in 20 years there will either be very large transaction volume or no volume."
	},
	{
		"id": 140,
		"type": "ignore",
		"date": "2010-02-16 01:34:56",
		"src": "https://bitcointalk.org/index.php?topic=54.msg360#msg360",
		"q": "Hello,\nwell the title says it all. I want to set up multiple bitcoin machines behind NAT.\nFor this it reason would be nice, if one could choose an other port than 8333, which I guess would have other nice side effects. Maybe someone uses this port for something else or maybe it isn't possible to set up port forwarding to this port for one reason or another.\nOr is there an other way one should go?",
		"a": "Right now there isn't a port number setting to do that. It's a feature yet to be implemented. You can only set up your NAT to port-forward to one of the computers. (I said something earlier about NAT port translation, but that wouldn't work, other nodes wouldn't know to connect to that port)\nIf you want, as a small optimization, you could run the rest of your computers as:\nbitcoin -connect=<the IP of the first computer>\nso they get all their network communication from the first computer and don't all connect over the net individually for the same information. This saves bandwidth, although it doesn't use much bandwidth to begin with, so it wouldn't really matter unless you had tons of computers.\nFor redundancy in case the first computer goes down, you could have two that connect out and the rest connect to both of them. The first two are run normally, the rest are run like:\nbitcoin -connect=<IP1> -connect=<IP2>"
	},
	{
		"id": 141,
		"type": "favorite",
		"date": "2010-02-16 17:36:40",
		"src": "https://bitcointalk.org/index.php?topic=43.msg376#msg376",
		"q": "Satoshi, I figured it will take my modern core 2 duo about 20 hours of nonstop work to create ฿50.00! With older PCs it will take forever. People like to feel that they \"own\" something as soon as possible, is there a way to make the generation more divisible? So say, instead of making ฿50 every 20 hours, make ฿5 every 2 hours?",
		"a": "I thought about that but there wasn't a practical way to do smaller increments. The frequency of block generation is balanced between confirming transactions as fast as possible and the latency of the network.\nThe algorithm aims for an average of 6 blocks per hour. If it was 5 bc and 60 per hour, there would be 10 times as many blocks and the initial block download would take 10 times as long. It wouldn't work anyway because that would be only 1 minute average between blocks, too close to the broadcast latency when the network gets larger."
	},
	{
		"id": 142,
		"date": "2010-02-17 17:58:03",
		"src": "https://bitcointalk.org/index.php?topic=43.msg388#msg388",
		"q": ". Perhaps it has to do with my connection's very high latency (2000ms or more on average)",
		"a": "2 seconds of latency in both directions should reduce your generation success by less than 1%."
	},
	{
		"id": 143,
		"date": "2010-02-17 17:58:03",
		"src": "https://bitcointalk.org/index.php?topic=43.msg388#msg388",
		"q": "and/or my high packet loss (sometimes up to 10% loss)?",
		"a": "Probably OK, but I'm not sure. The protocol is designed to resync to the next message, and messages get re-requested from all the other nodes you're connected to until received. If you miss a block, it'll also keep requesting it every time another blocks comes in and it sees there's a gap. Before the original release I did a test dropping 1 out of 4 random messages under heavy load until I could run it overnight without any nodes getting stuck."
	},
	{
		"id": 144,
		"type": "ignore",
		"date": "2010-02-17 19:19:43",
		"src": "https://bitcointalk.org/index.php?topic=47.msg389#msg389",
		"q": "My Dutch translation is almost finished. I will send it to sirius-m this week.",
		"a": "I updated the SVN with changes to support translation. Translatable strings are all enclosed in _(\"\"), and we're using UTF-8 on all platforms.\nWhen the program runs, it looks in the directory of the EXE for the file: locale\\<langcode>\\LC_MESSAGES\bitcoin.mo\n<langcode> is the two letter code of the language your OS is set to, like \"de\" or \"nl\".\nOn Linux, it also looks for:\n/usr/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo\n/usr/local/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo\n(are there other standard places it should look on linux?)\nHere's a quick walkthrough using poedit to make a .po and .mo file:\n- Download the bitcoin sourcecode from SVN\n- In the trunk directory, mkdir locale\\<lang>\\LC_MESSAGES\n- In poedit, File->New catalog->Paths tab\n- Click the \"New item\" dotted rectangle button\n- Put \"../../..\" and MAKE SURE TO PRESS ENTER to add the path\n- Click OK\n- Save the file as \"bitcoin.po\" in the LC_MESSAGES directory you made\n- It should then scan the sourcecode and find about 170 strings\n- If it didn't find anything, check Catalog->Settings->Path tab, make sure the \"../../..\" was added\nWhen you're done translating, commit both bitcoin.po (the editable catalog file) and bitcoin.mo (compiled data used by the program)."
	},
	{
		"id": 145,
		"type": "ignore",
		"date": "2010-02-21 03:43:48",
		"src": "https://bitcointalk.org/index.php?topic=58.msg413#msg413",
		"q": "Is there some hard-coded maximum limit for the amount of connections? I see 45 connections atm. It's been growing nicely in the last months. Just can't get that many coins anymore...",
		"a": "Nodes stop trying to initiate connections once they have 15. If you can accept incoming connections, then you can get well above that from nodes connecting to you, otherwise you max out at 15.\nI don't know if there's any reason to have 15 connections. Maybe it should be 10.\nSince nodes that can only connect out are probably at or near 15 most of the time now, you should level off to an equilibrium. 45 suggests a ratio of 3 out-only nodes to every 1 in-accepting node.\nThe number of connections won't be a good gauge of the size of the network any more. Someone should periodically IRC to the bitcoin channel on chat.freenode.net and count the number of users. That gives you the total count of network nodes (except TOR nodes).\nBlock generation is again running ahead of pace. We're in for another big step up in difficulty at the next adjustment in about 5 days."
	},
	{
		"id": 146,
		"type": "favorite",
		"date": "2010-02-21 05:44:24",
		"src": "https://bitcointalk.org/index.php?topic=57.msg415#msg415",
		"q": "Nothing to sweat people. Nobody ever died of a 'deflationary spiral.' I agree with \"I-am-not-anonymous.\" The market will choose the best bitcoin-like currency. I happen to believe, however, that the rules that Satoshi has founded bitcoin on will be more than adequate for the future of a thriving bitcoin economy.\nEverybody knows exactly how fast the supply of bitcoins will grow: it's set in stone in the rules of the programming and the bitcoin network. While it's true that there is not a currently existing fully-fleshed out market to truly price bitcoins, such markets and exchanges are being developed. As far as future would-be bitcoin generators are concerned, the question is not how much will he \"demand....to compensate for his costs.\" The question he'll be asking himself is \"given current market values and my ability to utilize electricity and CPU resources, is it worth it for me to generate bitcoins?\" If the answer is yes, he participates. If it's no, he stops trying to mine for bitcoins and focuses on trading tangible assets with bitcoins serving as an appropriate intermediary. If he's not sure, he tries his hand at it for a while and then makes a final decision.\nThe number of nodes and associated computational cpu power will be in flux, and that competitive flux will allow for costs to approximate value (not the other way around.) Value being set by the markets and the demand for use of bitcoin as a trade intermediary (a money). In the far future, the competition of transaction costs will play a more important role for the would-be node operator.\nContrary to the paradox of thrift argument you present, collecting bitcoins and saving them with hopes of earning purchasing power through deflation is not a bad thing. It will allow for the pooling of bitcoin capital and make purchases of larger capital investments possible. In the future, there might even be bitcoin banks that lend out saved bitcoins with market-set interest rates, thereby diminishing the effects of hoarding. All this wonderful saving, however, comes at a price: delayed gratification of present desires. From the perspective of the would-be saver, the question will always be denying present desires to purchase real tangible assets now versus the future possibilities of purchasing more later. This time preference naturally varies with people and in different circumstances.\nGiven the fact that bitcoins are by their electronic nature easily divisible, prices will be able to easily adjust to deflationary pressures. If too many are saving, prices will fall and the rate of interest will go down. This encourages demand (lower prices) and decreases the desire to save (less interest).\nXC",
		"a": "Excellent analysis, xc.\nA rational market price for something that is expected to increase in value will already reflect the present value of the expected future increases. In your head, you do a probability estimate balancing the odds that it keeps increasing.\nIn the absence of a market to establish the price, NewLibertyStandard's estimate based on production cost is a good guess and a helpful service (thanks). The price of any commodity tends to gravitate toward the production cost. If the price is below cost, then production slows down. If the price is above cost, profit can be made by generating and selling more. At the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price.\nIn later years, when new coin generation is a small percentage of the existing supply, market price will dictate the cost of production more than the other way around.\nAt the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production."
	},
	{
		"id": 147,
		"date": "2010-02-23 00:49:56",
		"src": "https://bitcointalk.org/index.php?topic=61.msg433#msg433",
		"q": "No problem here. Other clients just happened to generate those blocks before you.",
		"a": "Just a random streak of bad luck. It looks steady to me.\nCompetition doesn't have an effect until the next automatic retarget adjustment, and we haven't reached the next one yet.\nThe adjustments are every 2016 blocks. To calculate our progress towards the next one, divide the block total by 2016. The fractional part is how far we are to the next one.\nMy back-of-the-envelope projection: 42032 blocks/2016 = 20.85 = 85% of the way. About 1.5 days to go until the next one. That'll only be about 10 days since the last one, the target is 14 days, so 14/10 = 1.4 = around 40% difficulty increase."
	},
	{
		"id": 148,
		"type": "ignore",
		"date": "2010-02-23 01:16:28",
		"src": "https://bitcointalk.org/index.php?topic=60.msg434#msg434",
		"q": "When you merged the \"your addresses\" and \"the other addresses\", how can you see the difference between them? Perhaps it is better to build version 0.2.5 myself, but does anyone have a guide to build it on Mac OS X 10.6?",
		"a": "There are now \"Sending\" and \"Receiving\" tabs in the Address Book. Your addresses are referred to as \"receiving addresses\".\nmadhatter was working on building it on Mac. He had errors probably caused by UTF-16 wxWidgets 2.8. Should have better luck now with 2.9.0. wxWidgets 2.9.0 is UTF-8 and wouldn't have that problem.\nI think he had it working on FreeBSD, but he wanted a non-UI version.\nI have the command line and JSON-RPC daemon version working now. Will SVN it in a day or two.\nI disabled gdm on my Ubuntu system so it boots into command line. I hope I will be able to get it enabled again with rcconf."
	},
	{
		"id": 149,
		"type": "ignore",
		"date": "2010-02-23 16:26:09",
		"src": "https://bitcointalk.org/index.php?topic=62.msg443#msg443",
		"q": "If I read the source code correctly, keys are always made in pairs. That means, every address has an associated private key. When you click \"New Address\", you call GenerateKey in main.cpp, which generates a new key pair. So the duplicate address is ultimately a duplicate public key. Which is very unlikely.\nWhile keys still are \"easily generated\", you should have to generate a whole lot of keys before a collision. While I am not certain, it seems that the keys generated have a space of 256 bits, which is a lot more than the 122 bits put in perspective in the wikipedia article on uuids. Remember, 123 bits have half the probability of collision as 122 bit, 124 half of that again etc.",
		"a": "There's a separate public/private keypair for every bitcoin address. You don't have a single private key that unlocks everything. Bitcoin addresses are a 160-bit hash of the public key, everything else in the system is 256-bit.\nIf there was a collision, the collider could spend any money sent to that address. Just money sent to that address, not the whole wallet.\nIf you were to intentionally try to make a collision, it would currently take 2^126 times longer to generate a colliding bitcoin address than to generate a block. You could have got a lot more money by generating blocks.\nThe random seed is very thorough. On Windows, it uses all the performance monitor data that measures every bit of disk performance, network card metrics, cpu time, paging etc. since your computer started. Linux has a built-in entropy collector. Adding to that, every time you move your mouse inside the Bitcoin window you're generating entropy, and entropy is captured from the timing of disk ops."
	},
	{
		"id": 150,
		"date": "2010-02-23 16:53:27",
		"src": "https://bitcointalk.org/index.php?topic=60.msg446#msg446",
		"q": "/etc/init.d/gdm start and it will start gdm!",
		"a": "Ah yes, there we go, back to normal again.\nThe ctrl+alt+F[1-8] thing never worked on this computer. The screen just goes haywire."
	},
	{
		"id": 151,
		"date": "2010-02-23 22:24:00",
		"src": "https://bitcointalk.org/index.php?topic=62.msg453#msg453",
		"q": "Are generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window?",
		"a": "No, each generated transaction uses a new, single-use address.\nNothing uses the address in the main window, it's just there for convenience for you to copy. 0.2.5 has a \"New...\" button next to it to make it easy to change each time you use it."
	},
	{
		"id": 152,
		"date": "2010-02-24 05:57:43",
		"src": "https://bitcointalk.org/index.php?topic=55.msg481#msg481",
		"q": "Yeah, I had totally thought of that too. A magnet link scheme would be awesome.",
		"a": "That would be nice at point-of-sale. The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile."
	},
	{
		"id": 153,
		"type": "ignore",
		"date": "2010-02-24 06:17:23",
		"src": "https://bitcointalk.org/index.php?topic=63.msg482#msg482",
		"q": "Will this requirement be removed sometime? I'd rather not have to deal with GTK.",
		"a": "How much \"dealing with\" does GTK actually require? Is it just a matter of \"sudo apt-get install libgtk2.0-0\" and having some extra libraries sitting around? GTK doesn't have to do anything, just be there for bitcoin to link to when it loads up, have the gtk-init-check call fail because no GUI present, then it's done.\nIt saves us butchering everything with ifdefs and a separate compile and binary to use wxBase just to try to avoid linking GTK."
	},
	{
		"id": 154,
		"date": "2010-02-24 21:53:52",
		"src": "https://bitcointalk.org/index.php?topic=45.msg507#msg507",
		"q": "I am not that picky. Growth of the Bitcoin network and promoting more widespread usage is sufficient reward to me.",
		"a": "If you GPL stuff, I have to avoid using it. Nothing against GPL per-se, but Bitcoin is an MIT license project. Anything GPL please clearly mark it as such."
	},
	{
		"id": 155,
		"type": "ignore",
		"date": "2010-02-24 22:08:55",
		"src": "https://bitcointalk.org/index.php?topic=63.msg509#msg509",
		"q": "This is strange... When I start Bitcoin as a daemon on my 64 bit Linux server, it eats up all the 250MB of remaining RAM, 700MB of swap and eventually crashes. On my 32 bit Ubuntu desktop, it works fine and stays at 15MB of memory usage. The server is running a 64 bit build of Bitcoin. Maybe there's something wrong with the build or something.",
		"a": "When and how fast did memory usage increase? Right away, slowly over a long time, or starting at some later event?\nI have -daemon running on ubuntu 9.10 64-bit and memory usage is steady.\nIt has to be something about the difference on the server besides 64-bit. Maybe some malfunction from the lack of GUI. A memory leak debug tool could give a clue."
	},
	{
		"id": 156,
		"date": "2010-02-24 22:42:24",
		"src": "https://bitcointalk.org/index.php?topic=43.msg510#msg510",
		"q": "My understanding is that every Bitcoin client has the same algorithm (formula) built into it to automatically adjust the difficulty every so many blocks. Not only that, but I think that Bitcoin will not accept blocks generated at a different difficulty, so if a modified Bitcoin client tried to send out more easily generated blocks, all the authentic clients would reject the fake blocks.",
		"a": "The automatic adjustment happened earlier today.\n24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000\n24/02/2010 3.78 +49%\nI updated the first post."
	},
	{
		"id": 157,
		"date": "2010-02-25 01:56:24",
		"src": "https://bitcointalk.org/index.php?topic=64.msg521#msg521",
		"q": "I like them. Do they come in higher resolutions?",
		"a": "Yes, the original is 546x531 pixels.\nIt looks good at larger size too, but since the small icons are what you mostly always see, I wanted to judge it on those first. I'll post larger sizes and full size a little later."
	},
	{
		"id": 158,
		"type": "ignore",
		"date": "2010-02-25 22:54:17",
		"src": "https://bitcointalk.org/index.php?topic=63.msg539#msg539",
		"q": "It started increasing right away. I'll see if valgrind can help me.",
		"a": "OK, I made a build target bitcoind that only links wxBase and does not link GTK. Version 0.2.7 on SVN.\nI split out the init and shutdown stuff from ui.cpp into init.cpp, so now ui.cpp is pure UI. ui.h provides inline stubs if wxUSE_GUI=0. We only have four functions that interface from the node to the UI. In the bitcoind build, we don't link ui.o or uibase.o."
	},
	{
		"id": 159,
		"type": "ignore",
		"date": "2010-02-25 22:54:17",
		"src": "https://bitcointalk.org/index.php?topic=63.msg539#msg539",
		"q": "It started increasing right away. I'll see if valgrind can help me.",
		"a": "Sure feels like it could be something in wxWidgets retrying endlessly because some UI thing failed or something wasn't inited correctly. Our hack to ignore the initialize failure and run anyway means we're in uncharted territory. We're relying on the fact that we hardly use wx in this mode. We do still use a few things like wxGetTranslation and wxMutex.\nAnother way to debug would be to run in gdb, wait until everything is quiet and all threads should be idle, and break it and see which thread is busily doing something and what it's doing.\nI suspect bitcoind will probably work fine, but I hope you can still debug the problem."
	},
	{
		"id": 160,
		"date": "2010-02-25 23:06:29",
		"src": "https://bitcointalk.org/index.php?topic=43.msg540#msg540",
		"q": "We need Satoshi to confirm that because clients accept blocks generated at easier difficulties all the time whenever the PoW's difficulty increases.",
		"a": "The formula is based on the time it takes to generate 2016 blocks. The difficulty is multiplied by 14/(actual days taken). For instance, this time it took 9.4 days, so the calculation was 14/9.4 = 1.49. Previous difficulty 2.53 * 1.49 = 3.78, a 49% increase.\nI don't know what you're talking about accepting easier difficulties."
	},
	{
		"id": 161,
		"type": "ignore",
		"date": "2010-02-26 16:29:21",
		"src": "https://bitcointalk.org/index.php?topic=63.msg555#msg555",
		"q": "I'm getting errors when trying to compile with just wxBase.\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/opt/tdep/include\" -I\"/usr/include\" -DwxUSE_GUI=0 -o obj/nogui/util.o util.cpp\nIn file included from util.cpp:5:\nheaders.h:22:24: error: wx/clipbrd.h: No such file or directory\nIn file included from headers.h:100,\nfrom util.cpp:5:\ndb.h: In member function 'bool CDB::Exists(const K&)':\ndb.h:140: error: 'class Db' has no member named 'exists'\nmake: *** [obj/nogui/util.o] Error 1\nClipbrd.h isn't installed with wxBase. Moving wxWidgets-2.9.0/include/wx/clipbrd.h to my include directory just eliminates those two \"no such file\" lines.",
		"a": "wx/clipbrd.h isn't used, move it inside the #if wxUSE_GUI.\nUpdated headers.h on SVN.\nSorry, I linked to wxbase but I had full wxWidgets on my computer.\nThe db.h:140 class Db no member named \"exisits\" is stranger. pdb->get, pdb->put, pdb->del compiled before that. Do you have version 4.7.25 of Berkeley DB?\nDb::exists()\nhttp://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/frame_main.html\nhttp://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/dbexists.html\nI suppose they might have added exists recently, using get before that."
	},
	{
		"id": 162,
		"date": "2010-02-26 23:17:19",
		"src": "https://bitcointalk.org/index.php?topic=64.msg561#msg561",
		"q": "Excellent. This would be a good resource for those participating in the banner contest. Why unequal dimensions?\nMy only suggestion would be to make the coin's text stand out more. At tiny resolutions outlines tend to be come unworkable, so a better option may be to experiment with contrast. Making the text significantly darker than the rest of the coin would likely increase readability. Alternately, you could make the inner circle color darker, and the text lighter.",
		"a": "Good suggestion. I made the B slightly lighter and the background slightly darker. Very slightly. The foreground is now exactly the same colour as the BC in the old one.\nIt's kind of OK if you can't easily read the B in the 16x16. At that size, you just need to see that it's a coin. It doesn't matter so much what's embossed on it, just that there be some detail there because it wouldn't look like a coin if it was a blank smooth circle.\nIt's slightly wider than tall because the dark perspective under it goes more to the right than down.\nI finished and posted the 32x31 and 48x47 versions in the first message. I like the 48 a lot.\nHow does everyone feel about the B symbol with the two lines through the outside? Can we live with that as our logo?"
	},
	{
		"id": 163,
		"type": "ignore",
		"date": "2010-02-26 23:48:44",
		"src": "https://bitcointalk.org/index.php?topic=63.msg562#msg562",
		"q": "Using DB-4.7.25 fixed that problem.\nI'm now getting this error, though:\ng++ -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/opt/tdep/include\" -o bitcoind -L\"/usr/lib\" -L\"/usr/local/lib\" -L\"/opt/tdep/lib\" obj/nogui/util.o obj/nogui/script.o obj/nogui/db.o obj/nogui/net.o obj/nogui/irc.o obj/nogui/main.o obj/nogui/rpc.o obj/nogui/init.o obj/sha.o -l wx_baseu-2.9 -Wl,-Bstatic -l boost_system -l boost_filesystem -l db_cxx -Wl,-Bdynamic -l crypto -l gthread-2.0\nobj/nogui/init.o: In function `wxArrayString::Item(unsigned int) const':\ninit.cpp:(.text._ZNK13wxArrayString4ItemEj[wxArrayString::Item(unsigned int) const]+0x7): undefined reference to `wxTheAssertHandler'\ninit.cpp:(.text._ZNK13wxArrayString4ItemEj[wxArrayString::Item(unsigned int) const]+0x42): undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'\ncollect2: ld returned 1 exit status\nmake: *** [bitcoind] Error 1",
		"a": "Are you using wxWidgets 2.9.0? I don't recommend using anything other than 2.9.0.\nIt looks like they've got a reference in the wx headers (arrstr.h) to something outside of wxBase.\nRemoving -D__WXDEBUG__ from bitcoin's makefile would probably solve it.\nIf that doesn't work and you just want to get it working, you could edit wxWidgets include/wx/arrstr.h, line 167 and comment out the wxASSERT_MSG."
	},
	{
		"id": 164,
		"date": "2010-02-27 04:28:29",
		"src": "https://bitcointalk.org/index.php?topic=64.msg566#msg566",
		"q": "How about an SVG version? That way we could automatically generate smaller and larger versions as needed.",
		"a": "I don't know how to do SVG, but I did the original very large, over 500 pixels across, so it can be scaled down. I'll give the original when I'm finished.\nI had to custom tweak each icon size so the vertical lines land square on their pixels, otherwise they're ugly blurry and inconsistent. Such is the challenge of making icons. The original will be good for scaling to custom sizes between 48 and 500 but not smaller."
	},
	{
		"id": 165,
		"type": "ignore",
		"date": "2010-02-27 21:22:53",
		"src": "https://bitcointalk.org/index.php?topic=65.msg571#msg571",
		"q": "Looking through the source of 2.8.10 it appears that unicode is possible with that version too.",
		"a": "In the Windows world, \"unicode\" means UTF-16 (wchar).\n2.8 has two build variations, ANSI and UTF-16 (unicode). The UTF-16 version is the \"unicode\" version provided in the Debian package. I believe 2.8 and its UTF-16 build labelled simply \"unicode\" has been the source of build problems described in the forum. We were previously using 2.8 ANSI in anticipation of getting to UTF-8 without going through UTF-16 hell. We cannot compile with UTF-16.\n2.9 has only one version, UTF-8. On Windows, we set the codepage to UTF-8, so on all platforms our code is UTF-8 and wxWidgets interfaces with us in UTF-8. On Linux I assume the codepage is already UTF-8. By standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we need 2.9 for UTF-8 internationalization.\nMake sure you read build-unix.txt and configure wxWidgets using the configure parameters given.\nCurious, why is it incredibly hard to provide wxWidgets 2.9.0? If you mean for users, that's why we static link it.\nIt's unfortunate that we require so many big dependencies, but we need them all. At least on Debian/Ubuntu, all but wxWidgets are available as packages. Eventually they'll provide a 2.9 package."
	},
	{
		"id": 166,
		"date": "2010-03-02 02:33:05",
		"src": "https://bitcointalk.org/index.php?topic=64.msg588#msg588",
		"q": "When you use SVG or another vector-format, you don't have the problems you discribed when scaling the logo. Perhaps I'll give it a go in Illustrator.",
		"a": "We have the standard icon sizes, and the full size scales nicely to anything else.\nI added the full size to the first post."
	},
	{
		"id": 167,
		"date": "2010-03-03 04:28:56",
		"src": "https://bitcointalk.org/index.php?topic=69.msg614#msg614",
		"q": "How encouraging...you've just told the poor fellow that even if he does everything right he could still go to jail--you're making him feel like an ethnic minority!\nIn most cases though, if a lawyer tells you you won't go to jail, you probably will not go to jail. Newlibertstandard uses paypal, which already practices know-your-customer and he is operating in amounts less than $10,000 which is what the money laundering and tax cheat police sniff out for. This means he is unlikely to be doing anything that is wrong OR anything that will attract the attention of Law Enforcement.\nHowever---\nThinking ahead to bitcoin's future--money changing services that operate on a large scale and don't practice know-your customer would indeed be illegal and would thus have to operate within the onionverse, changing bitcoin to money services other than paypal (perhaps offshore based like pecunix).\nAnother idea would be for some future crypto-preneur to set up a Mom and Pop shop called \"Grandpa Joe's envelopes stuffed with cash\" and only accept bitcoin as payment. lol.",
		"a": "When there's enough scale, maybe there can be an exchange site that doesn't do transfers, just matches up buyers and sellers to exchange with each other directly, similar to how e-bay works.\nTo make it safer, the exchange site could act as an escrow for the bitcoin side of the payment. The seller puts the bitcoin payment in escrow, and the buyer sends the conventional payment directly to the seller. The exchange service doesn't handle any real world money.\nThis would be a step better than e-bay. E-bay manages to work fine even though shipped goods can't be recovered if payment falls through."
	},
	{
		"id": 168,
		"type": "ignore",
		"date": "2010-03-05 01:46:25",
		"src": "https://bitcointalk.org/index.php?topic=63.msg633#msg633",
		"q": "This is strange... When I start Bitcoin as a daemon on my 64 bit Linux server, it eats up all the 250MB of remaining RAM, 700MB of swap and eventually crashes. On my 32 bit Ubuntu desktop, it works fine and stays at 15MB of memory usage. The server is running a 64 bit build of Bitcoin. Maybe there's something wrong with the build or something.",
		"a": "sirius-m debugged this, it was 64-bit related.\nThe fix is now available on SVN, file util.cpp."
	},
	{
		"id": 169,
		"type": "ignore",
		"date": "2010-03-15 18:44:12",
		"src": "https://bitcointalk.org/index.php?topic=72.msg717#msg717",
		"q": "Hi, I run bitcoin at a nice level of 20 so as not to interfere with other tasks. Every now and then, however, it seems to auto-adjust itself to nice level 2, or even 0. It this by design? Frankly, such a thing should be illegal for a linux application... it's a bit odd to say the least.",
		"a": "It sets different priorities for each thread. The generate threads run at PRIO_MIN. The other threads rarely take any CPU and run at normal.\n#define THREAD_PRIORITY_LOWEST PRIO_MIN\n#define THREAD_PRIORITY_BELOW_NORMAL 2\n#define THREAD_PRIORITY_NORMAL 0\nThe priorities converted from Windows priorities were probably from a table like this:\n\"The following table shows the mapping between nice values and Win32 priorities. Refer to the Win32 documentation for SetThreadPriority() for more information on Win32 priority issues.\nnice value Win32 Priority\n-20 to -16 THREAD_PRIORITY_HIGHEST\n-15 to -6 THREAD_PRIORITY_ABOVE_NORMAL\n-5 to +4 THREAD_PRIORITY_NORMAL\n+5 to +14 THREAD_PRIORITY_BELOW_NORMAL\n+15 to +19 THREAD_PRIORITY_LOWEST\"\nIf you have better values, suggestions welcome.\nAlso, there was some advice on the web that PRIO_PROCESS is used on Linux because threads are processes. If that's not true, maybe it accounts for unexpectedly setting the priority of the whole app.\n// threads are processes on linux, so PRIO_PROCESS affects just the one thread\nsetpriority(PRIO_PROCESS, getpid(), nPriority);"
	},
	{
		"id": 170,
		"type": "ignore",
		"date": "2010-03-16 19:48:47",
		"src": "https://bitcointalk.org/index.php?topic=84.msg729#msg729",
		"q": "I vote for the I2P method, myself. It works great.",
		"a": "Thanks soultcer for talking with the Freenode staffer. Good to know it's OK at the current size, and now they know who we are. They're supportive of projects like TOR so I hope they would probably be friendly to us. We don't want to overstay our welcome. If we get too big, then by the same token, we're big enough that we don't need IRC anymore and we'll get off.\nWe only needed IRC because nobody had a static IP. In the early days there were some steady supporters, but they all had pool-allocated IPs that change every few days. IRC was only intended as a temporary solution. Bitcoin's built-in addr system is the main solution.\nBitcoin can get the list of IPs from any bitcoin node. In that sense, every node serves as a directory server.\nWhen there are enough static IP nodes to have a good chance that at least one will still be running by the time the current version goes out of use, we can preprogram a seed list.\nHow do you think we should compile the seed list? Would it be OK to create it from the currently connected IPs that have been static for a while?\nBTW, if we want to supplement by deploying separate directory server software, may I suggest IRC? IRC is a good directory server (I've heard it has other uses too), and there are mature IRC server implementations available that anyone can run. Bitcoin's IRC client implementation is already thoroughly tested."
	},
	{
		"id": 171,
		"date": "2010-03-16 20:17:34",
		"src": "https://bitcointalk.org/index.php?topic=83.msg731#msg731",
		"q": "Good idea.\nI'll eventually be setting up a 'one hop', SSL, http, login protected proxy service (similar to the 1st Psiphon project) and accepting bitcoins as payment.\nI'm UK based so it will be good for using BBC iplayer etc. I will be giving bitcoin users priority service, as well as users from 'restricted' countries.\nI doubt I'll have the spare bandwidth for a file hosting service though, maybe.",
		"a": "That's a great idea. There's a thriving business in those services, but I've always thought the standard payment methods are at odds with privacy minded customers.\nWould you consider making your software freely available so anyone could easily set one up? I know for competitive reasons the inclination is to keep it to yourself, but it could get an order of magnitude more use if anyone could give proxy access to their country just by putting the software on a server.\nI wonder if there are other kinds of web application servers where we would only have to tack on the payment mechanism to an already existing system?"
	},
	{
		"id": 172,
		"date": "2010-03-23 15:22:41",
		"src": "https://bitcointalk.org/index.php?topic=88.msg806#msg806",
		"q": "It's not related to our project. Apparently it's some company called Bitcoin Ltd. The page has been saying \"alpha test coming soon\" since the last summer at least.",
		"a": "It's unrelated. There wasn't anything there when I started.\nThe price of .com registrations is lower than it should be, therefore any good name you might think of is always already taken by some domain name speculator. Fortunately, it's standard for open source projects to be .org."
	},
	{
		"id": 173,
		"date": "2010-03-23 17:35:34",
		"src": "https://bitcointalk.org/index.php?topic=87.msg807#msg807",
		"q": "Add this to the 'cons list' for cash:\n- Possibility of RFID imbedded into the bills. They could be read by the machines at your local post office and throw a red flag on the destination address.",
		"a": "LR and Pecunix have many established exchanges to paper currencies by various payment methods, and a number of vendors accept them as payment, so an exchange link between Bitcoin and LR/Pecunix would give us 2nd-hop access to all that. The possibility to cash out through them would help support the value of bitcoins.\nBitcoin has unique properties that would be complementary. LR/Pecunix are easy to spend anonymously, but hard to buy anonymously and not worth the trouble to buy in small amounts. Bitcoin, on the other hand, is easy to get in small amounts anonymously. It would be convenient to buy LR/Pecunix with bitcoins rather than through conventional payment methods.\nMost customers who convert to LR to buy something would probably ask the seller first if they accept Bitcoin, encouraging them to start accepting it."
	},
	{
		"id": 174,
		"type": "ignore",
		"date": "2010-03-24 18:01:57",
		"src": "https://bitcointalk.org/index.php?topic=83.msg809#msg809",
		"q": "Yes. Any built proxy implementation would be open source and automated bitcoin payments would be great.\nI will post the psiphon info. and links because the project has just moved from v1 to v2 and the implementations are very different.\nPsiphon is a free 'circumvention' tool and should remain so. However, I've run a private and personally updated / secured 1.6 version and do accept 'token' donations from some of my users.\n\"Psiphon is a web proxy designed to help Internet users securely bypass the content-filtering systems used to censor the internet. Psiphon was developed by the Citizen Lab at the University of Toronto.\nLicense: GNU General Public License\nSource code: http://psiphon.ca/download/psiphon-src-1.6.tar.gz\nhttp://wikipedia.org/wiki/Psiphon\nhttp://psiphon.ca/\nhttps://launchpad.net/psiphon\nPsiphon is a user-friendly, simple to administer, web-based proxy application. It allows users in regions with unrestricted Internet access to provide access to denied content to their friends, family, and associates in regions with restricted access.\nPlease contact the project leader if you're interested in helping us take Psiphon forward.\nNOTE: The Psiphon 1.x and 2.x series are essentially different products with different architectures. Psiphon 1.x is a light-weight web proxy designed to run on a home PC (MS Windows-based) with no central management component. With Psiphon 1.x, a user asks a friend to run a proxy and can then access blocked sites via his or her friend's Internet connection. The Psiphon 1.x source code is available here: https://code.launchpad.net/~psiphon-inc/psiphon/psiphon-1.6.\nThe new project is Psiphon 2.x, a centrally managed web proxy system deployed by Psiphon Inc. to provide censorship circumvention services.\"\nGreat source code here in reference to designing and building our own separate bitcoin style implementation. I'd grab the 1.6.tar.gz for your reference satoshi, before it becomes to 'historical'. It's also not that easy to compile the 1.6 version on Linux anymore.\nThe 1.6 Win32 version has now been removed from the original project website. I actually run my existing proxy service on a windows box, with additional security. I have the msi and documentation if anyone can't find it elsewhere or would like it for reference etc. I keep it up-to-date and secure from the following sources;\nSSL - http://www.slproweb.com/products/Win32OpenSSL.html\nVisual C++ 2008 Redistributables for msvcpXX.dll and msvcrXX.dll\nhttp://www.sqlite.org/download.html\nPrecompiled Binaries For Windows for sqlite3.dll\nJava and some flash support is always an issue though !\nI would be happy to work on and share contributions for a 'bitcoin' proxy software, but have limited time and developer experience myself. Maybe you should contact the psiphon developers for a separate v1.6 style implementation yourself satoshi ?\nI understand that the Tor project is also looking for a payment / incentive system for it's server operators.\nBitcoinFX",
		"a": "Title changed.\nIt helps that we have someone with actual experience running a proxy service. Do you think Psiphon is the best one currently? (sometimes the one you run was the best when you started but you found better ones later)"
	},
	{
		"id": 175,
		"date": "2010-05-16 21:01:44",
		"src": "https://bitcointalk.org/index.php?topic=130.msg1130#msg1130",
		"q": "If you're generating a new Bitcoin Address for each transaction, people may accidentally send to old ones. They will have that BA in their Transaction history and may think it's good for multiple uses. Just something to think about.\nThe possibility of accidentally sending to a random BA is insanely small though.",
		"a": "When you generate a new bitcoin address, it only takes disk space on your own computer (like 500 bytes). It's like generating a new PGP private key, but less CPU intensive because it's ECC. The address space is effectively unlimited. It doesn't hurt anyone, so generate all you want."
	},
	{
		"id": 176,
		"date": "2010-05-16 21:37:36",
		"src": "https://bitcointalk.org/index.php?topic=129.msg1131#msg1131",
		"q": "I suggest we disable IP transactions while the user uses a Proxy!\nJust to be on the safe side.",
		"a": "That's a good idea. At the very least a warning dialog explaining that it'll connect to the IP and send the information cleartext, giving the chance to cancel."
	},
	{
		"id": 177,
		"date": "2010-05-16 22:37:21",
		"src": "https://bitcointalk.org/index.php?topic=55.msg1132#msg1132",
		"q": "A freenet URI is like this:\nhttp://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf",
		"a": "There you go, we could easily do it the same way, like:\nhttp://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>\nBitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332. It would give an HTTP answer."
	},
	{
		"id": 178,
		"date": "2010-05-16 22:37:21",
		"src": "https://bitcointalk.org/index.php?topic=55.msg1132#msg1132",
		"q": "A bitcoin-link should be more like mailto: than magnet: IMHO.",
		"a": "I think we can do that.\nAlthough it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.\nThe HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page. Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in. It would work just like a mailto: link that pops up a new email with the address filled in.\n127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog. You'd still have to press Send. We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter."
	},
	{
		"id": 179,
		"type": "ignore",
		"date": "2010-05-16 22:53:59",
		"src": "https://bitcointalk.org/index.php?topic=135.msg1133#msg1133",
		"q": "Today, I've got an error message:\nException: 9key_error\nCKey::CKey(); EC:KEY_new_by_curve_name failed\nbitcoin in ThreadBitcoinMiner()\nterminate called after throwing an instance of 'key_error'\nwhat(): CKey::CKey() : EC_KEY_new_by_curve_name failed\nAborted\nI hope that isn't a buffer overflow. Have anybody this error message too?\nOS: linux",
		"a": "Does it happen every time you run it, or just happened once at some random time?\nI've never seen that fail before. It's a call to OpenSSL that I assumed would never fail, but I put an error check there just in case. I can't imagine how it would fail. Out of memory maybe.\nThe code is:\nkey.h:\nEC_KEY* pkey;\npkey = EC_KEY_new_by_curve_name(NID_secp256k1);\nif (pkey == NULL)\nthrow key_error(\"CKey::CKey() : EC_KEY_new_by_curve_name failed\");\nNID_secp256k1 is a constant."
	},
	{
		"id": 180,
		"type": "ignore",
		"date": "2010-05-16 23:34:40",
		"src": "https://bitcointalk.org/index.php?topic=101.msg1134#msg1134",
		"q": "A question to Satoshi: have you tested the program with thousands of own addresses in the wallet? If I make a new address for each automated transaction, it's going to be a big amount. Or maybe I could reuse the addresses, given a big enough pool.",
		"a": "Bitcoin addresses you generate are kept forever. A bitcoin address must be kept to show ownership of anything sent to it. If you were able to delete a bitcoin address and someone sent to it, the money would be lost. They're only about 500 bytes.\nThousands of own addresses should not be any problem at all. If you've generated 50000 BTC, then you already have 1000 own addresses, one for each 50 generated. Those are hidden, they're not shown in the UI.\nIt would be a good idea to add a little code that keeps giving the same address to the same IP. Here's what I did in C++ to keep giving the same key (aka bitcoin address) until they use it:\n// Keep giving the same key to the same ip until they use it\nif (!mapReuseKey.count(pfrom->addr.ip))\nmapReuseKey[pfrom->addr.ip] = GenerateNewKey();\n...sends the key mapReuseKey[pfrom->addr.ip]\n...later...\n// Received something with this key\nmapReuseKey.erase(pfrom->addr.ip);\nIf it's not convenient to know when you've received, just clear the cached keys every 20 minutes.\nI want to add a parameter to getnewaddress for number of days to expire if nothing is received with the address."
	},
	{
		"id": 181,
		"date": "2010-05-16 23:56:03",
		"src": "https://bitcointalk.org/index.php?topic=54.msg1135#msg1135",
		"q": "So, if I somehow I forwarded port router:8333 to bitcoinhost1:8333 and router:8334 to bitcoinhost2:8333, we get undefined behavior?\nBecause that seems like trivial to me, to keep track of port numbers in any p2p app.",
		"a": "At the moment, it always assumes the incoming port is 8333, so it would tell other bitcoin nodes to connect to router:8333 even if you're redirecting from another port number.\nI'm not in a big hurry to fix this because I can't think of any benefit to having more than one incoming connection port. If you're providing one incoming port, then you've done your bit to help the network. Having two incoming ports to the same person doesn't help redundancy.\nIf you have many computers, then using the -connect switch on most of them to connect locally makes more sense."
	},
	{
		"id": 182,
		"type": "ignore",
		"date": "2010-05-18 02:58:11",
		"src": "https://bitcointalk.org/index.php?topic=112.msg1143#msg1143",
		"q": "You are partly correct. bitcoind is a \"terminate and stay resident program\". You communicate with it over a JSON-RPC socket to send payments/poll for received payments.",
		"a": "A little late, but in case anyone else has the same issue. The compile dump had 2 warnings (that were 20 lines long) and 2 link errors. The errors were:"
	},
	{
		"id": 183,
		"type": "ignore",
		"date": "2010-05-18 02:58:11",
		"src": "https://bitcointalk.org/index.php?topic=112.msg1143#msg1143",
		"q": "obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function `wxArrayString::Item(unsigned long) const':\n/usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to `wxTheAssertHandler'\nobj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In function `wxArrayString::Item(unsigned long) const':\n/usr/src/bitcoin/trunk/uint256.h:526: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'",
		"a": "Those are probably due to switching to the release build of wxWidgets instead of debug. They're moving towards only debug build and ditching the release build, so they probably don't care that their release build is broken by referring to non-existent assert stuff. There's nothing to fear about the debug build. It's fully suitable for releases.\nbitcoind runs as a daemon and can either be controlled by command line or JSON-RPC.\nThanks madhatter and generica for detailing the instructions for building on freebsd."
	},
	{
		"id": 184,
		"date": "2010-05-18 20:06:46",
		"src": "https://bitcointalk.org/index.php?topic=125.msg1149#msg1149",
		"q": "Really from a purist stance, people should audit the code and build it themselves.\nHowever this would exclude most people except dorks like us.. so you just have to trust that you got it from a reputable source. I distribute a Mac OS X binary version but if you don't trust me you shouldn't be using it. Similarly, I can make a password manager tool or a PayPal assistant tool and I can make it send your passwords and money to me. You have to trust someone I guess unless you are willing to audit the code yourself. The network itself has some protections from non-cooperative nodes but the users are obviously targets for scamming. Kind of reminds me of the card skimmers people install on ATMs too.. they think they're using a trustworthy machine but it's been modified to capture their information.",
		"a": "It's not the download so much as verifying all the signatures in all the blocks as it downloads that takes a long time.\nHow long is the initial block download typically taking? Does it slow down half way through or is about the same speed the whole way?\nI've thought about ways to do a more cursory check of most of the chain up to the last few thousand blocks. It is possible, but it's a lot of work, and there are a lot of other higher priority things to work on.\nSimplified Payment Verification is for lightweight client-only users who only do transactions and don't generate and don't participate in the node network. They wouldn't need to download blocks, just the hash chain, which is currently about 2MB and very quick to verify (less than a second to verify the whole chain). If the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes. At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated.\nSPV is not implemented yet, and won't be implemented until far in the future, but all the current implementation is designed around supporting it.\nIn the meantime, sites like vekja.net and www.mybitcoin.com have been experimenting with account-based sites. You create an account on a website and hold your bitcoins on account there and transfer in and out. Creating an account on a website is a lot easier than installing and learning to use software, and a more familiar way of doing it for most people. The only disadvantage is that you have to trust the site, but that's fine for pocket change amounts for micropayments and misc expenses. It's an easy way to get started and if you get larger amounts then you can upgrade to the actual bitcoin software."
	},
	{
		"id": 185,
		"date": "2010-05-20 21:43:42",
		"src": "https://bitcointalk.org/index.php?topic=30.msg1169#msg1169",
		"q": "Can I just butt in with a question on why that is? To me it seems that if Bitcoin uses public-key cryptography to transfer ownership of the coins, it should be a trivial matter to include a short message that is only readable by the recipient.",
		"a": "Almost but not quite. Bitcoin uses EC-DSA, which can only do digital signing, not encryption. RSA can do both, but I didn't use it because it's an order of magnitude bigger and would have been impractical."
	},
	{
		"id": 186,
		"date": "2010-05-26 18:51:04",
		"src": "https://bitcointalk.org/index.php?topic=154.msg1254#msg1254",
		"q": "Can't we force a user to use a new address for receiving payments?\nEvery time a payment is received display another Bitcoin address in the address bar. (only transactions via Bitcoin addresses, NOT IPs of course, since that'd be useless, right?)\nThe actual key would still be kept to ensure that the user would still receive payments of people sending to the same address.",
		"a": "This is on my list. I will soon make the \"Your Bitcoin Address:\" window automatically change whenever you receive anything to the address displayed.\nI'm also recommending this approach for the implementation of web apps. I just posted some sample code showing a suggested way of implementing this.\nVersions on SVN since 0.2.4 already have a \"New...\" button next to the address bar to encourage changing it manually too.\n@theymos: If nothing else, we can fall back on that solution in the future."
	},
	{
		"id": 187,
		"type": "ignore",
		"date": "2010-05-26 20:09:34",
		"src": "https://bitcointalk.org/index.php?topic=145.msg1256#msg1256",
		"q": "An optional parameter to specify the minimum number of blocks after that transaction (getallreceived 1 for current behavior, or just getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for instant confirms)?",
		"a": "Yeah, that actually is what it is. getallreceived 0 should do what you want. (now it's renamed to listreceivedbyaddress 0) The default is 1 confirmation, but I think in reality most digital goods and services can be 0 confirmations. Like you say, if you need more than 0 confirmations, you could show two numbers, unconfirmed and available balance, so they immediately see their transaction went through.\nlistreceivedbyaddress [minconf=1] [includeempty=false]\n[minconf] is the minimum number of confirmations before payments are included.\n[includeempty] whether to include addresses that haven't received any payments.\nReturns an array of objects containing:\n\"address\" : receiving address\n\"label\" : the label of the receiving address\n\"amount\" : total amount received by the address\n\"confirmations\" : number of confirmations of the most recent transaction included\nor listreceivedbylabel if you're labelling addresses with their username.\nSo far I've concentrated on functions for web merchants, not so much on stuff for remote management of headless coin generators yet."
	},
	{
		"id": 188,
		"date": "2010-05-26 20:34:34",
		"src": "https://bitcointalk.org/index.php?topic=153.msg1258#msg1258",
		"q": "Although I'm not familiar with the specifics of the algorithm implementation in C++, I am familiar with how the verification works in general. Although the algorithm would have to be re-written, it really should be possible to verify blocks in both directions at the same time. Each block contains the hash of the previous block, but the first block contains a genesis hash, which isn't the hash of a previous block. The first time bitcoins starts, it would treat a recent hash, perhaps a one day old hash as a temporary genesis hash and quickly verify the roughly 144 blocks up to the most recent block and it would continue to verify and optionally generate new hashes. Another thread would grab a previous hash, perhaps a two day old hash and treat it as the new temporary genesis hash. It would quickly verify the roughly 144 blocks, and verify that the last hash matches the previous genesis hash. The second thread would continue verifying previous blocks until it reached the real genesis block, which I believe is defined within Bitcoin itself. As you can see, blocks are always being verified in forward direction, but the beginning point is just pushed back until it reaches the real beginning. There could even be a third thread which would start at the real genesis hash and verify blocks from there so that they meet in the middle. All three of those threads could be grouped into another thread which would be run for each different chain of blocks which it is told about from other Bitcoin peers. If more than one chain is verified as authentic, Bitcoin would calculate and compare the total amount of computing power required to create the chain and keep only the strongest chain. Off the top of my head, an easy way to calculate the strongest chain, would be to find the largest sum of the inverses of the numeric value of each hash.",
		"a": "It does in fact download 500 blocks at a time, then the counter counts one at a time as it verifies the blocks.\nThe advantage of letting bitcoin download and verify the blocks is that you do not have to trust the person you're downloading them from. If you downloaded the blk*.dat files from some site, you would have to trust that site, since you would be accepting the data without verifying it yourself. If you're copying blk*.dat from another computer of yours, that should be fine.\nHow long is the initial block download taking for you?"
	},
	{
		"id": 189,
		"date": "2010-05-26 21:16:34",
		"src": "https://bitcointalk.org/index.php?topic=151.msg1259#msg1259",
		"q": "My pleasure.\nI've fixed the problems SmokeTooMuch mentioned (thanks!) in the attached version. I also should have the FAQ translated soonish (first draft is done).\nWe also might want to update the numbers. Even though the FAQ explicitly states that it dates back to October 2009, claiming 500 generated Bitcoins per day as achievable amount might give rise to disappointment.",
		"a": "Does anyone want to translate the Bitcoin client itself? It would be great to have at least one other language in the 0.3 release.\nAll you have to do is get poedit and translate the po file I'm attaching to this post. It's less than 750 words.\nUpdated bitcoin.po attachment for 0.3.1"
	},
	{
		"id": 190,
		"date": "2010-05-26 21:34:32",
		"src": "https://bitcointalk.org/index.php?topic=141.msg1260#msg1260",
		"q": "This makes it sound like a payment wouldn't send successfully if there were insufficient funds for the fee.",
		"a": "In the SVN version, if a transaction requires a transaction fee, it says\n\"This transaction is over the size limit. You can still send it for a fee of #,\nwhich goes to the nodes that process your transaction and helps to support the network.\nDo you want to pay the fee?\"\nIf you don't have enough money with the fee added, it says\n\"Total exceeds your balance when the # transaction fee is included \""
	},
	{
		"id": 191,
		"type": "ignore",
		"date": "2010-05-27 14:18:22",
		"src": "https://bitcointalk.org/index.php?topic=151.msg1269#msg1269",
		"q": "Here there is the italian translation of the software.\nThere can be some mistakes, but it's just ok for the first version\nI hope that someone will come to do something better.",
		"a": "Hurray! We have our first language. I uploaded it to SVN to go in with the 0.3 release."
	},
	{
		"id": 192,
		"type": "ignore",
		"date": "2010-06-02 18:18:15",
		"src": "https://bitcointalk.org/index.php?topic=158.msg1322#msg1322",
		"q": "I'm not sure what you mean by again (I'm not the developer).. anyway I'm just trying to explain why I don't think you should use it to accept payments. Sending payments to a hostname is not reliable for the reasons I said above, and the biggest problem is that there is no way to even know that the payment went to the wrong place, for the sender. There is a better (reliable) alternative using one time bitcoin addresses.\nWhat I was getting at is that there is no authentication and no way to know if the payment got there with internet address based transactions. I think the internet address based payments are only for testing locally. The option is there but I don't think it's suitable for using on the internet or any multi-user network.\nIf there was any real amount of internet address based transactions and tor users I would set up an exit node just to intercept any tor based payments.. I still may do it just to see if I can get any because it's just another way to make a few more bitcoins per day.\nI guess what I'm trying to say that it is the equivalent of leaving a pile of cash in your driveway with a rock on top of it to keep it from blowing away in the wind. Anyone can just go pick it up and so if you're a service provider you would not want to encourage your customers to pay you in that way, because it would just cause problems when the customer says they paid and the service provider says they didn't receive it. The only reason it's even possible to use on the internet right now is because unlike cash which has perceived value to a lot of people, bitcoins are like a pile of rocks to random internet users, they just walk by. If there are all these piles of bitcoins in everybody's driveway and people start figuring out that they're valuable, you can bet they'll start disappearing, so it's best not to put them there in the first place.\nLaszlo",
		"a": "The current sending by IP is not very useful: it connects to the IP, so you'd like to use TOR for anonymity, but then it can totally be eavesdropped and man-in-the-middled.\nThe future plan for sending to an IP is to make it a bitcoin address plus IP, like:\n1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4\nor\n1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.com\nI need suggestions for the separator character. \":\" is a candidate, but IPv6 has : in it and that might get confusing. Something that's allowed in url parameters would be nice.\nI want to use SSL for the connection, using the bitcoin address' public key as the cert. You would be certain you're connected to who you thought, and safely encrypted. The bitcoin address would not be used for the transaction, only for authentication. A new generated bitcoin address would be sent through the SSL connection.\nSince it's authenticated, it would then be safe to allow the IP address to be a domain name. Some care taken that if a proxy is used, it uses socks4a instead of DNS lookup."
	},
	{
		"id": 193,
		"date": "2010-06-02 18:45:38",
		"src": "https://bitcointalk.org/index.php?topic=43.msg1323#msg1323",
		"q": "A nice addition to the GUI would be an estimate of how many hashes/sec it's computing. Either present this as a raw number or a \"you can expect to generate X packs of bitcoins per week.\"\nThis might partially solve the frustration of new users not getting any Bitcoins right away.",
		"a": "That's a good idea. I'm not sure where exactly to fit that in, but it could certainly calculate the expected average time between blocks generated, and then people would know what to expect.\nEvery node and each processor has a different public key in its block, so they're guaranteed to be scanning different territory.\nWhenever the 32-bit nonce starts over at 1, bnExtraNonce gets incremented, which is an arbitrary precision integer."
	},
	{
		"id": 194,
		"type": "ignore",
		"date": "2010-06-02 22:18:09",
		"src": "https://bitcointalk.org/index.php?topic=151.msg1324#msg1324",
		"q": "Here is the almost complete (93%) translation into Dutch.\nIt might contain some errors though.\nI can has credit now?",
		"a": "I uploaded the 93% complete Dutch translation to SVN. Thanks!"
	},
	{
		"id": 195,
		"type": "ignore",
		"date": "2010-06-14 18:13:21",
		"src": "https://bitcointalk.org/index.php?topic=84.msg1579#msg1579",
		"q": "I like the idea of distributed host caches like Gnutella uses. At the moment, for the majority of people, IRC is a single point of failure. Let's assume that for some reason our Freenode channel was gone. Maybe Freenode got fed up and shut us down. Maybe MenInBlack saw our system, laughed maniacally, and then pressured Freenode to shut us down.\nWhen you start your client, it will do nothing. You could drop to a command line and type \"-addnode\" (or is it -peer? whatever) to connect to a known node, but at that point you'd somehow need to know a node. It probably wouldn't be that hard for one of us, but what about a new user? We could keep a list of peers on the website for them to use, but at that point, they've gone from \"just double click the shiny gold coin and get trading\" to \"check our website for updated peer lists, open command prompt, navigated to the bitcoin directory, and type the proper peer.....\" And if MIB were after us, the website would probably be long since gone.\nOf course, we could implement addpeer in a more user-friendly manner. Perhaps a popup that says \"I can't connect to the network. Enter a peer: \" with instructions on some ways to find one, but at that point we're creating a social solution to a technical problem.\nAlso, if we get bigger we will need to move away from IRC anyway (as implied by the OP's conversation with a Freenode staffer). And what about Tor users? Why should people who want to use Tor to be anonymous have to manually add a peer?\nFinally, anyone on Freenode can easily get a list of all running Bitcoin clients, when they came online, when they went offline, etc. That goes against the project's stated goal of anonymity. Of course, with a host cache system, anybody who connected to that cache could be logged by the server operator, but no one operator would have a full picture of the network.\nI think the IRC solution is a wonderful beginning, and I applaud how stable it has proven to be. It was a great decision to get the network up easily and concentrate on the more interesting and important considerations in the program. I just think that Bitcoin will outgrow it someday, if it hasn't already.",
		"a": "Bitcoin has its own distributed address directory using the \"addr\" message. It's about time we coded in a list of the current long running static nodes to seed from. I can add code so new nodes do not preferentially stay connected to the seed nodes, just connect and get the list, so it won't be a burden on them.\nWhat do you think, should I go ahead with adding the seeds?\nIt'll still try IRC first. The IRC has the advantage that it lists nodes that are currently online, since they have to stay connected to stay on the list, but the disadvantage that it's a single point of failure. The \"addr\" system has no single point of failure, but can only tell you what nodes have recently been seen, so it takes a little longer to get connected since some of the nodes you try have gone offline. The combination of the two gets us the best of both worlds and more total robustness.\nIs there anyone who wants to volunteer to run an IRC server in case freenode gets tired of us?"
	},
	{
		"id": 196,
		"date": "2010-06-14 19:53:44",
		"src": "https://bitcointalk.org/index.php?topic=158.msg1582#msg1582",
		"q": "That would be perfect, although I would prefer to use the hostname on the right side.\nOf course, I'm the kind of guy who might shop at thenerdsshop.com\nFor grandma, the entire bitcoin concept is pretty confusing at the moment. Even neglecting all the technical details, the UI still shows a huge string of numbers and letters (your receiving address) and best practices currently require you to deal with that every time you give someone your address.\nAnother option is to use something like what OpenID uses: hidden tags on the store's (hopefully SSL) site. Then you could just enter a site's URL as the receiving address. It would hit that site, search for something like\n<link rel=\"bitcoin.address\" href=\"19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3\">\n<link rel=\"bitcoin.server\" href=\"12.34.56.78\">\nOr some other form and try to send securely to that.",
		"a": "SirArthur has a good point about the normal online merchant case, which is what the send-by-IP option is more suited to. This is the case where the merchant will have a server on a static IP and their own domain name and SSL cert.\nInstead of connecting by IP, we can connect to a domain name by SSL, using the existing CA infrastructure to authenticate that you're connected to the owner of that domain.\nThe user would send to domain.com (or www.domain.com is ok too). That would be very natural and users could see and verify that what they entered is who they intend to pay.\nThe SSL also makes it safe for TOR users.\nProblem is, I think merchants would still prefer to use bitcoin addresses to be certain they know what the payment is for. You simply cannot count on users to enter the right thing in the comment fields to identify the transaction. It would only approach practical if we had a mailto style link that prepopulates the comment field with the order number, but then the link could just as well be a bitcoin address.\nJust having an open bitcoin server at domain.com that users could send unidentified payments to would be too much of a liability. Regular users aren't used to the idea of having to identify the payment. Merchants would get too many blank payments followed by \"I paid you, where's my stuff?!\" a week later.\nThe payment sequence does have a step where the receiver verifies the order before accepting it. It can reject the payment and return an error message if it doesn't contain a valid order number. That would require a difficult level of integration of custom code with the bitcoin server though."
	},
	{
		"id": 197,
		"type": "favorite",
		"date": "2010-06-14 20:39:50",
		"src": "https://bitcointalk.org/index.php?topic=191.msg1585#msg1585",
		"q": "So it's possible to switch \"on the fly\" to a new hash function? Wouldn't all the old transactions then be compromised (because they could be trivially recomputed)?\nSHA-256 has already been weakened by a factor of 16 (according to my friend. I can't find documentation on that, but I trust him). That's 16 out of 2^256, so not a huge deal, but still.",
		"a": "SHA-256 is very strong. It's not like the incremental step from MD5 to SHA1. It can last several decades unless there's some massive breakthrough attack.\nIf SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.\nIf the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used."
	},
	{
		"id": 198,
		"date": "2010-06-14 22:21:55",
		"src": "https://bitcointalk.org/index.php?topic=179.msg1588#msg1588",
		"q": "3) Which data exactly passed between 2 nodes during transaction? (or just show me place in source code where to look)",
		"a": "3) Nothing, if sending by bitcoin address"
	},
	{
		"id": 199,
		"date": "2010-06-14 22:21:55",
		"src": "https://bitcointalk.org/index.php?topic=179.msg1588#msg1588",
		"q": "5) Is there any any plans on decentralizing node list (i have figured out from irc that bitcoin is currently not really decentralized, because nodes getting in touch by joining irc channel on freenode).",
		"a": "5) It is decentralised. After you have connected to the network the first time, you no longer need IRC."
	},
	{
		"id": 200,
		"type": "ignore",
		"date": "2010-06-14 22:40:14",
		"src": "https://bitcointalk.org/index.php?topic=163.msg1590#msg1590",
		"q": "That's my process as well, although I apply a variety of patches to things before hand. And I have boost and I think libdb from Ubuntu's repos.",
		"a": "Sorry, I didn't test compile on linux the last few revisions.\nReverted makefile.unix."
	},
	{
		"id": 201,
		"date": "2010-06-15 23:41:29",
		"src": "https://bitcointalk.org/index.php?topic=165.msg1595#msg1595",
		"q": "Adding transactions to the block you're working on will slow down your generation rate",
		"a": "The premise is false. Adding more transactions to the block you're working on does NOT slow down your generation rate. When generate is scanning hashes, it only hashes the header of the block, which is constant size. The header contains a hash of the transactions (the Merkle root) and is only updated occasionally.\nIf necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about. A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in. I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions."
	},
	{
		"id": 202,
		"date": "2010-06-16 00:15:47",
		"src": "https://bitcointalk.org/index.php?topic=55.msg1596#msg1596",
		"q": "That's a very pragmatic answer. I like it.\nHowever, how would that work with the combined IP / Bitcoin Address URI (URN? URL?) scheme described here?\n[link]http://bitcointalk.org/index.php?topic=158.msg1322#msg1322[/link]\nI know it's been nearly a month, sorry.",
		"a": "http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345\nor\nhttp://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00\nBut as long as the link is already doing the typing for you, I don't see much benefit in using a domain address instead of bitcoin address. With a bitcoin address, the user can't send an unidentified payment. They can't send payment until they've been given a correct bitcoin address to send to.\nWhat would be nice about sending by domain is you could visually verify who it's going to.\nA more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1:\nhttp://bitcointalk.org/index.php?topic=63.msg1589#msg1589\nand if that's true, then what about that example freenet link that had 127.0.0.1 in it?"
	},
	{
		"id": 203,
		"type": "ignore",
		"date": "2010-06-16 16:53:34",
		"src": "https://bitcointalk.org/index.php?topic=151.msg1600#msg1600",
		"q": "lol!",
		"a": "Thanks DataWraith! The German translation is uploaded to SVN.\nThis is great, we've already got 3 major languages."
	},
	{
		"id": 204,
		"type": "ignore",
		"date": "2010-06-17 17:07:56",
		"src": "https://bitcointalk.org/index.php?topic=184.msg1609#msg1609",
		"q": "32 bit linux? Yea I can do that.",
		"a": "I'm working on getting version 0.3 released as soon as I can. Just a last few things left to do. It's been a long time since 0.2 and we need to get a prebuilt bitcoind with command line and JSON-RPC available. This time we'll have both 32-bit and 64-bit linux binaries, and Laszlo is going to build a Mac OSX release. Plus, we'll include the German, Dutch and Italian translations by DataWraith, Xunie and Joozero (thanks you guys!)."
	},
	{
		"id": 205,
		"date": "2010-06-17 18:46:08",
		"src": "https://bitcointalk.org/index.php?topic=195.msg1611#msg1611",
		"q": "So I'm writing a little tool that dissects the Bitcoin wallet.dat, mainly because I want to understand better exactly how Bitcoin works.\nAnd I see that the outputs of transactions have a value (number of bitcoins) and a bunch of bytes that are run through the little Forth-like scripting language built in to bitcoin. E.g.:\n['TxOut: value: 100.00 Script: DUP HASH160 6fad...ab90 EQUALVERIFY CHECKSIG']\nFirst: it make me a little nervous that bitcoin has a scripting language in it, even though it is a really simple scripting language (no loops, no pointers, nothing but math and crypto). It makes me nervous because it is more complicated, and complication is the enemy of security. It also makes it harder to create a second, compatible implementation. But I think I can get over that.\nLooking at the code, new transactions are verified by pushing the signature an then public key on the interpreter's stack and then running the TxOut script (did I get that right?).\nCould I write code to create transactions with any valid script in the TxOut?\nE.g. could I create a TxOut with a script of: OP_2DROP OP_TRUE\n... to create a coin that could be spent by anybody?\nAnd is flexibility in the types of coins created the reason it is coded this way?",
		"a": "The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.\nThe script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.\nThe receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.\nThe design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.\nI don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint."
	},
	{
		"id": 206,
		"type": "favorite",
		"date": "2010-06-18 16:17:14",
		"src": "https://bitcointalk.org/index.php?topic=195.msg1617#msg1617",
		"q": "Good idea or not, SOMEBODY will try to mess up the network (or co-opt it for their own use) sooner or later. They'll either hack the existing code or write their own version, and will be a menace to the network.\nI admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.\nThat's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...",
		"a": "A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.\nI know, most developers don't like their software forked, but I have real technical reasons in this case."
	},
	{
		"id": 207,
		"type": "favorite",
		"date": "2010-06-18 16:17:14",
		"src": "https://bitcointalk.org/index.php?topic=195.msg1617#msg1617",
		"q": "I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.\nThat's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...",
		"a": "That's one of the reasons for transaction fees. There are other things we can do if necessary."
	},
	{
		"id": 208,
		"type": "favorite",
		"date": "2010-06-18 16:17:14",
		"src": "https://bitcointalk.org/index.php?topic=195.msg1617#msg1617",
		"q": "How long have you been working on this design Satoshi? It seems very well thought out, not the kind of thing you just sit down and code up without doing a lot of brainstorming and discussion on it first. Everyone has the obvious questions looking for holes in it but it is holding up well",
		"a": "Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it. Much more of the work was designing than coding.\nFortunately, so far all the issues raised have been things I previously considered and planned for."
	},
	{
		"id": 209,
		"type": "ignore",
		"date": "2010-06-18 17:28:18",
		"src": "https://bitcointalk.org/index.php?topic=84.msg1619#msg1619",
		"q": "I think the way eMule handles bootstrapping for its KAD-network is pretty close to optimal:\nThe list of known peers is stored in a file (nodes.dat), and every client maintains a list of known nodes in that file (sorted by longest uptime, I think -- that's an intrinsic property of Kademlia, but still a good idea). The released client should be accompanied by such a file that contains the addresses of a few reliable peers on static IP addresses, from which a new client can then get more addresses to connect to (and hence store in its own file).\nIf the \"seed list\" gets out of date, or the server is shut down or something, you can just ask *anyone* in the network to publish his nodes-file (on rapidshare, say), and voila, you've got a fresh list of IPs you can connect to.",
		"a": "The SVN version now uses IRC first and if that fails it falls back to a hardcoded list of seed nodes. There are enough seed nodes now that many of them should still be up by the time of the next release. It only briefly connects to a seed node to get the address list and then disconnects, so your connections drop back to zero for while. At that point, be patient. It's only slow to get connected the first time.\nThis means TOR users won't need to -addnode anymore, it'll get connected automatically."
	},
	{
		"id": 210,
		"date": "2010-06-18 23:08:34",
		"src": "https://bitcointalk.org/index.php?topic=183.msg1620#msg1620",
		"q": "The Bitcoin Faucet now shows how many coins it has available to give out (on the left-hand side of the page). The number is only moderately accurate-- donations will take 5 or 10 minutes to show up in the balance.\nI also implemented another anti-cheating measure that should make casual cheating a little harder (which I don't want to say too much about because that would make it easy for cheaters to know what to do).\nI'm very pleasantly surprised at how well freebitcoins is working so far; thanks again to everybody who tried it out and who donated bitcoins to it!",
		"a": "Excellent choice of a first project, nice work. I had planned to do this exact thing if someone else didn't do it, so when it gets too hard for mortals to generate 50BTC, new users could get some coins to play with right away. Donations should be able to keep it filled. The display showing the balance in the dispenser encourages people to top it up.\nYou should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something."
	},
	{
		"id": 211,
		"type": "ignore",
		"date": "2010-06-21 17:20:21",
		"src": "https://bitcointalk.org/index.php?topic=149.msg1646#msg1646",
		"q": "Bitcoin looks ugly in Ubuntu's new default theme. It seems that some, but not all of the theme settings are being picked up. The unselected file menu should have light text with a dark background, but it incorrectly has light text with a light background. They're similar enough that it's unreadable on my display. It should be fixed before the next stable release.",
		"a": "This is now fixed in the SVN version.\n1) Menu bar default color.\n2) Balance bar not a different color.\n3) Background behind bitcoin address and balance now the same color as toolbar.\nI checked all the standard themes and it seems reasonable with all of them.\nUbuntu minimize,maximize,close buttons to the right:\ngconf-editor\napps->metacity->general\nbutton_layout=menu:minimize,maximize,close\nThey've got it awfully buried considering 9 out of 10 users are used to having it on the right."
	},
	{
		"id": 212,
		"date": "2010-06-21 17:48:26",
		"src": "https://bitcointalk.org/index.php?topic=198.msg1647#msg1647",
		"q": "The current user interface doesn't support smaller than 0.01 increments but it is possible to support it in a future revision.",
		"a": "Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone."
	},
	{
		"id": 213,
		"date": "2010-06-21 17:48:26",
		"src": "https://bitcointalk.org/index.php?topic=198.msg1647#msg1647",
		"q": "I wonder though, is there a point where the difficulty of generating a new coinbase is so high that it would make more sense to try to recover keys for lost coins or steal other people's coins instead? The difficulty of that is really high so for now it makes a lot more sense to generate but I just wonder what the real figures are.. would that ever become more productive? Maybe Satoshi can address this..",
		"a": "Computers have to get about 2^200 times faster before that starts to be a problem. Someone with lots of compute power could make more money by generating than by trying to steal."
	},
	{
		"id": 214,
		"type": "ignore",
		"date": "2010-06-21 18:09:17",
		"src": "https://bitcointalk.org/index.php?topic=43.msg1648#msg1648",
		"q": "Thanks for clearing that up, fergalish!",
		"a": "I integrated the hashmeter idea into the SVN version. It displays khash/s in the left section of the status bar.\nTwo new log messages:\n21/06/2010 01:23 hashmeter 2 CPUs 799 khash/s\n21/06/2010 01:23 generated 50.00\ngrep your debug.log for \"generated\" to see what you've generated, and grep for \"hashmeter\" to see the performance. On windows, use:\nfindstr \"hashmeter generated\" \"%appdata%\bitcoin\\debug.log\"\nI have the hashmeter messages once an hour. How often do you think it should be?"
	},
	{
		"id": 215,
		"type": "ignore",
		"date": "2010-06-22 03:45:56",
		"src": "https://bitcointalk.org/index.php?topic=149.msg1653#msg1653",
		"q": "Satoshi, that definitely made it look better for me, but now Bitcoin won't minimize to tray in Ubuntu 10.04. The proper check box is checked, but it just minimizes to my taskbar like always.",
		"a": "On Ubuntu 10.04 it wouldn't remove the taskbar button cleanly, so I made it leave it there.\nBut now that you mention it, it's probably better to have the feature, even if it's messy, than not to have it, though it may confuse a few people when the taskbar button temporarily stays around but disappears if you click on it.\nUpdated SVN.\nThanks for testing."
	},
	{
		"id": 216,
		"date": "2010-06-22 04:35:26",
		"src": "https://bitcointalk.org/index.php?topic=197.msg1656#msg1656",
		"q": "100/day seems pretty good... Does internet connection speed matter? Also, does it matter how long your computer has been continuously connected?",
		"a": "I've noticed that hashing performance doesn't vary as much between CPUs as you'd expect. Compared to an old CPU, a newer CPU doesn't show as much of a speedup at hashing as it does on general benchmarks.\nI guess recent CPU optimizations must have concentrated on things like I/O and branch prediction. Most programs are a bunch of memory access, comparisons and branching, they rarely get down to cranking away at maths for very long.\nThe latest SVN version has a khash/s display. Around 400 khash/s per processor is typical."
	},
	{
		"id": 217,
		"type": "ignore",
		"date": "2010-06-22 16:39:43",
		"src": "https://bitcointalk.org/index.php?topic=149.msg1668#msg1668",
		"q": "Yeah, r89 works as expected for me. It doesn't seem to have any problems creating or removing icons, but I'm using XFCE, so that might be the difference.\nIn addition, there's a difference between standard behaviour for tray icons in Windows and Linux. In most Linux apps, clicking the tray button while the app's window is open will cause it to close again. I personally like that better than the Windows default, where a single click does nothing once the main window is displayed. Is there any chance that feature might get added to the Linux version?",
		"a": "It's too late now for feature changes to 0.3, but I'll add that to the post-0.3 to do list. I never would have noticed that if you hadn't pointed it out."
	},
	{
		"id": 218,
		"date": "2010-06-22 16:51:14",
		"src": "https://bitcointalk.org/index.php?topic=43.msg1669#msg1669",
		"q": "I say keep it simple; more choices isn't always better, it just makes it overwhelming and confusing for most users.",
		"a": "Agree. Certainly too trivial to clutter the user's attention with.\nI changed it to every 30 minutes.\nIf I increased it to every 10 minutes, it would still be a small enough presence in the log file. Question is whether that would be more output than the user wants when they grep."
	},
	{
		"id": 219,
		"type": "ignore",
		"date": "2010-06-22 17:02:07",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1670#msg1670",
		"q": "It would be nice if the listtransactions RPC method were finished before the next release, though.",
		"a": "My fear is too many programmers would latch onto that for checking for received payments. It can never be reliable that way. The list/getreceivedbyaddress/label functions are the only way to do it reliably.\nWe shouldn't delay forever until every possible feature is done. There's always going to be one more thing to do."
	},
	{
		"id": 220,
		"type": "ignore",
		"date": "2010-06-22 19:11:41",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1675#msg1675",
		"q": "EXCEPTION: 22DbRunRecoveryException\nDBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery\nC:\\Program Files\\Bitcoin\bitcoin.exe in OnInit()",
		"a": "What operating system?\nNormally when it does that it's because the directory where the data directory should go doesn't exist. See if the \"%appdata%\" directory exists.\nDo you get that error with 0.2 also? It's hard to see how you could get that with 0.3 and not with 0.2 since there's nothing different in that regard."
	},
	{
		"id": 221,
		"type": "ignore",
		"date": "2010-06-22 19:25:13",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1677#msg1677",
		"q": "Windows 7 x64 ENG\n4 GB RAM\nIntel i7 860\nI was using the v0.2.10 build by laszlo before yours.",
		"a": "davidonpda, were you also running laszlo's build previously?\nCheck if the \"%appdata%\" directory exists, and \"%appdata%\bitcoin\"\nrename \"%appdata%\bitcoin\" bitcoin2\ndoes it work then?"
	},
	{
		"id": 222,
		"type": "ignore",
		"date": "2010-06-22 19:46:23",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1679#msg1679",
		"q": "Yes it works.\nso I closed it, copied the walled.dat from the old folder to the new one, and now it's downloading blocks\nAddress book and old transfers seem ok, but there aren't anyone of old \"generated coins\" ... I just need to wait?\nAnyway, I can just go back with the old v0.2.10\nI did another thing.\nClosed it, copied addr.dat / blk0001.dat / blkindex.dat from old folder to the new one.\nRestarted bitcoin ( v0.30 ), and now it seems that everything is working. ( I can see also old generated coins now )\nI just did NOT copied \"log.0000000002\" from the database folder ...",
		"a": "You figured it out faster than I could post a reply.\nIt looks like laszlo's build of Berkeley DB has database/log.* files that are not compatible with ours. The .dat files are fine, their format shouldn't ever change. All data is stored in the .dat files. All your own data is stored in wallet.dat. If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded.\nWhen you copied the directory except log.0000000002, that's the best solution. You should be good now.\nThe database/log.* files only contain temporary database data. If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely. They're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data.\nPlease keep running v0.3 if at all possible, don't go back to v0.2.10.\nAnyone else who hits this problem, move the database\\log.000000000* files somewhere else. (if it works fine after that, you can delete them later)\nI'm reluctant to make the installer delete or move those files. If the previous run was stopped by crashing or killed, that would be the wrong thing to do."
	},
	{
		"id": 223,
		"type": "ignore",
		"date": "2010-06-22 22:23:39",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1686#msg1686",
		"q": "Yeah, 0.3.0 seems to have a performance increase over svn r84 with Laszlo's performance patch.",
		"a": "Laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume he used that in his own build.\n30khash increase to what total rate? (to figure the % increase)"
	},
	{
		"id": 224,
		"type": "ignore",
		"date": "2010-06-24 17:40:05",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1748#msg1748",
		"q": "Much faster than Laszlo's build for me. Went from 600-700khash/s to 1000-1100khash/s on my Intel Core 2 Duo E8500. From 700-800khash/s on a laptop i7 to ~1100khash/s.\nKeeping the \"Run Bitcoin\" option checked in the installer seems to run it with admin privileges on the first launch. (in Win7)",
		"a": "Here's RC1 for linux for testing:\n(link removed, see below)\nIt contains both 32-bit and 64-bit binaries.\nRecent changes:\nbuild-unix.txt:\n- Added instructions for building wxBase, which is needed to compile bitcoind.\n- The package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev.\n- Updated version numbers.\nmakefile.unix:\n- The libboost libraries have removed the \"-mt\" from their filenames in 1.40. If you're compiling with Boost 1.38 or lower, like on Ubuntu Karmic, you would need to change it back to boost_system-mt and boost_filesystem-mt."
	},
	{
		"id": 225,
		"type": "ignore",
		"date": "2010-06-25 02:17:41",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1760#msg1760",
		"q": "Ubuntu 9.04 x86:\nvlad@vlad:~/bitcoin/bin/32$ ./bitcoind\n./bitcoind: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoind)\nAnybody know what Bitcoin needs?",
		"a": "I don't know. Maybe someone with more Linux experience knows how to install the library it needs.\nI built it on Ubuntu 10.04. I hope that wasn't a mistake. Maybe it should have been built on an older version for more backward compatibility. Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions? Is there any way I can downgrade to an older version of GCC on 10.04?\nThe 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all.\nWe don't need to bother with a 64-bit version for Windows. 32-bit programs work on all versions of Windows. It's not like Linux where the 64-bit OS wants 64-bit programs.\nI'm also curious if it's a little faster on linux than windows.\nDo you think I should make the directories:\n/bin32/\n/bin64/\ninstead of\n/bin/32/\n/bin/64/"
	},
	{
		"id": 226,
		"type": "ignore",
		"date": "2010-06-25 14:10:06",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1769#msg1769",
		"q": "But look here:\n32-bit Linux version on Ubuntu 10.04\n4 cores: 2500 khash/s\n3 cores: 1900 khash/s\n2 cores: 1260 khash/s\n1 core: 630 khash/s\n64-bit Linux version on Ubuntu 10.04 (new measure)\n4 cores: 2880 khash/s\n3 cores: 2150 khash/s\n2 cores: 1450 khash/s\n1 core: 720 khash/s\n(Though I never created one coin, yet - but I don't let bitcoin run on 4 cores the whole day, not even on 1 core...)\n@Joozero - The Intel i7 860 is @ 2.8 Ghz, isn't it? My Phenom II is @ 3 Ghz, that's another important fact I think. I will try bitcoin on Windows 7 at the same machine later.\n32-bit Win version on Windows 7 64-bit\n4 cores: 2310 khash/s\n3 cores: 1740 khash/s\n2 cores: 1160 khash/s\n1 core: 580 khash/s",
		"a": "Thanks virtualcoin, that's a perfect comparison.\nThe 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).\nThe 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit.\nHmm, I think the 8 extra registers added by x86-64 must be what's helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers."
	},
	{
		"id": 227,
		"type": "ignore",
		"date": "2010-06-25 21:15:15",
		"src": "https://bitcointalk.org/index.php?topic=215.msg1779#msg1779",
		"q": "I'm connected now.",
		"a": "We need more details about what happened MadHatter.\nBoth 0.2 and 0.3 have a backup way of getting connected without IRC, it's just slower to get connected.\n0.2 can find other nodes without IRC if it's ever been connected before, but a new install can't discover the network for the first time without IRC.\n0.3 can also seed without IRC. It can operate entirely without IRC if it needs to, but it's better having IRC for redundancy."
	},
	{
		"id": 228,
		"type": "ignore",
		"date": "2010-06-25 22:40:47",
		"src": "https://bitcointalk.org/index.php?topic=84.msg1781#msg1781",
		"q": "I run an IRC server you can use, it's fairly stable but it's not on redundant connections or anything. It is only two servers right now but we don't mess with it or anything, it just runs.\nMy box is a dedicated irc server:\n2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08\nYou can use irc.lfnet.org to connect.",
		"a": "This seems like a good idea.\nWhat does everyone think, should we make the switch for 0.3?"
	},
	{
		"id": 229,
		"type": "ignore",
		"date": "2010-06-26 14:28:06",
		"src": "https://bitcointalk.org/index.php?topic=215.msg1797#msg1797",
		"q": "Oh so with all that being said, you guys are all welcome to IRC on irc.lfnet.org. It is a small network that me and a couple of guys run.. we don't have services or k-lines or anything like that.",
		"a": "Freenode is too visible, right in the middle of where all those users and moderators are hanging out. Laszlo's option is a much better fit for us.\nI made 0.3.0.RC2 available that uses irc.lfnet.org instead of freenode if you want to start switching over:\nhttp://bitcointalk.org/index.php?topic=199.msg1787#msg1787"
	},
	{
		"id": 230,
		"date": "2010-06-26 15:10:10",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1800#msg1800",
		"q": "It looks good! The number of hashes per second intermittently disappears for a few seconds at a time. I think it might be triggered by clicking on the file menu multiple times. I'm using the Linux 64-bit build.",
		"a": "The first panel of the status bar is shared with the help description of menu items as you hover over them. Since all our menu item descriptions are blank, it replaces it with blank when you're hovering in a menu."
	},
	{
		"id": 231,
		"date": "2010-06-26 20:58:26",
		"src": "https://bitcointalk.org/index.php?topic=177.msg1814#msg1814",
		"q": "You can of course use services like vekja.net or mybitcoin.com on a mobile browser, depositing money there to the extent you trust them.",
		"a": "I think that's the best option right now. Like cash, you don't keep your entire net worth in your pocket, just walking around money for incidental expenses.\nThey could make a smaller version of the site optimized for mobile. If there was an app, it could be a front end to one of those, with the main feature being QR-code reader, or maybe there's already a universal QR-code reading app that web sites can be designed to accept scans from.\nIf there was an iPhone app that was just a front end for vekja or mybitcoin, not a big involved P2P, would apple approve it and if not, on what basis? It could always be an Android app instead. An app is not really necessary though, just a mobile sized website.\nA web interface to your own Bitcoin server at home wouldn't be a solution for everyone. Most users don't have a static IP, and it's too much trouble to set up port forwarding."
	},
	{
		"id": 232,
		"type": "ignore",
		"date": "2010-06-26 21:06:06",
		"src": "https://bitcointalk.org/index.php?topic=171.msg1815#msg1815",
		"q": "Jago, do you have all the proper dependencies installed?",
		"a": "The linux release candidate in the \"1.3 almost ready\" thread contains prebuilt bitcoind."
	},
	{
		"id": 233,
		"date": "2010-06-26 21:39:52",
		"src": "https://bitcointalk.org/index.php?topic=206.msg1816#msg1816",
		"q": "Funny how on this forum the same people play both sides of the table--on the one hand, trying to come up with ways to preserve absolute anonymity (e.g. the heroin store thread), and then coming here and trying to do sort of the opposite to protect BTC Faucet.\nI love it",
		"a": "Many big ISPs give you a new IP every time you connect, usually in the same class B (a.b.?.?). Maybe you should have a minimum time between payments per class-B.\nIf you can't solve the problem, you can always keep lowering the amount of bitcoins given until it's manageable, and always require captcha."
	},
	{
		"id": 234,
		"date": "2010-06-27 12:43:50",
		"src": "https://bitcointalk.org/index.php?topic=217.msg1827#msg1827",
		"q": "+1 NLS. Version 1.0 sounds better than 1.3.",
		"a": "But 1.0 sounds like the first release. For some things newness is a virtue but for this type of software, maturity and stability are important. I don't want to put my money in something that's 1.0. 1.0 might be more interesting for a moment, but after that we're still 1.0 and everyone who comes along thinks we just started. This is the third major release and 1.3 reflects that development history. (0.1, 0.2, 1.3)"
	},
	{
		"id": 235,
		"type": "ignore",
		"date": "2010-06-27 13:02:38",
		"src": "https://bitcointalk.org/index.php?topic=218.msg1828#msg1828",
		"q": "Hmm, yeah, it's probably normal; I THOUGHT the default address was given an empty label; I'm wrong, they're given the label \"Your Address\".\nSo: ./bitcoind getaddressesbylabel \"Your Address\" should work.\nOr just generate a new address, either with or without a label:\n./bitcoind getnewaddress",
		"a": "Welcome, Harry.\nI hadn't thought about starting out using bitcoind without using bitcoin first. I guess for now, this thread serves as the tutorial.\nThe focus for bitcoind so far has been more on backend support for websites. There's demand for things that would be nice for adminning headless generators like listgenerated. For the moment, you can grep the debug.log file for \"generated\" and \"hashmeter\" for some feedback. Generated blocks take about 24 hours before they're credited to your balance."
	},
	{
		"id": 236,
		"type": "ignore",
		"date": "2010-06-27 15:30:13",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1834#msg1834",
		"q": "I'm not sure why but I noticed that as well - my Win32 build was a lot slower than the linux/mac builds I did. I used MinGW and all that but maybe I made a mistake somewhere.. I probably used a different version of Berkeley DB than Satoshi too so that's why the logs weren't binary compatible.",
		"a": "MinGW still only has good old stable 3.4.5. There's not much reason for them to update it.\nWhen I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?"
	},
	{
		"id": 237,
		"type": "ignore",
		"date": "2010-06-27 19:06:09",
		"src": "https://bitcointalk.org/index.php?topic=202.msg1838#msg1838",
		"q": "Amal, I admit: I got you wrong!\nI am just afraid that digital currencies will not stay legal for long because the government has not control over it. (The day they make it illegal, you should open a bottle of champagne, because that's the sign that bitcoin is a success.)\nSo at that point, they will also shut down your registry. And all the people who gave their address to that agency will get into trouble.\nIf there is a major flaw discovered in Bitcoin and there is no sufficient time to swap to a different system, I assume there is nothing you can do about a loss of your wealth.\nStill, let's suppose YOU have discovered a way to produce an unlimited amount of coins. Your goal would be to profit from that secret AS LONG AS POSSIBLE. So even people that have the power to cheat wouldn't want a collapse of the digital fiat currency. And before the collapse of the old currency they would change their fake money for a better currency. But I am afraid that also goes for the so called \"real\" money. But.. somebody who has the brains to fool the algorithm of the digital currency at least gets a reward for his genius. In our paper fiat money system in the contrary, people who have access to the \"printing press\" of the government / central bank get rewarded for being just plain assholes.",
		"a": "Here's an answer to a similar question about how to recover from a major meltdown.\nhttps://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585"
	},
	{
		"id": 238,
		"date": "2010-07-02 19:21:36",
		"src": "https://bitcointalk.org/index.php?topic=223.msg1924#msg1924",
		"q": "Might I 2nd this request as a 'standard' GUI feature.\nI've recently tested bitcoin through various socks proxies / providers and the ability to limit connections below 10 would be really useful.",
		"a": "Thanks for the feedback on this.\nOne thing we could do is lower the outbound connections from 15 to 10 or maybe even 5. The choice of 15 was arbitrary. It just needs to be enough for redundancy and fast exponential propagation of messages. 10 would still be plenty. 5 should be fine. 10 is good as a nice round number so users can see that it stopped intentionally.\nIt would help to implement UPnP so there would be more inbound accepting nodes. Your number of connections is the ratio of inbound accepting nodes to out-only times 15. We need to encourage more people to accept inbound connections.\nI will implement a feature to stop accepting inbound connections once you hit a certain number.\nWhich version are you running?\nAnyone know how many connections typical P2P software like BitTorrent can get up to?"
	},
	{
		"id": 239,
		"date": "2010-07-02 20:37:17",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1926#msg1926",
		"q": "On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.",
		"a": "It is, but generating is more than twice as slow."
	},
	{
		"id": 240,
		"date": "2010-07-02 22:03:41",
		"src": "https://bitcointalk.org/index.php?topic=217.msg1928#msg1928",
		"q": "I'm not much of a marketing guy or anything but it makes sense to me to refer to software like this by the version in source control, like Bitcoin r82 or whatever.. maybe that's too geeky for some people.",
		"a": "OK, back to 0.3 then.\nPlease download RC4 and check it over as soon as possible. I'd like to release it soon.\nhttp://bitcointalk.org/index.php?topic=199.msg1927#msg1927\nOther than the version number change, which included changes in readme.txt and setup.nsi, I reduced the maximum number of outbound connections from 15 to 8 so nodes that accept inbound don't get too many connections. 15 was a lot more than needed. 8 is still plenty for redundancy."
	},
	{
		"id": 241,
		"type": "ignore",
		"date": "2010-07-02 22:20:20",
		"src": "https://bitcointalk.org/index.php?topic=223.msg1929#msg1929",
		"q": "BitTorrent clients can do hundreds of connections easily - this is why they end up killing those little embedded routers. It should be no problem for a regular IP router but the little embedded things are doing NAT so they're tracking state on all those connections and run out of memory.. also they're very slow SoC style computers so everything going through them suffers.\nTorrent clients generally have options for configuring a global maximum number of connections, maximum inbound and maximum outbound connections.\nI think it would be good to allow configuration of unlimited inbound/outbound connections for those who have the capability to do it, and provide a conservative default for those who are using NAT, tor, proxies, etc.",
		"a": "I reduced max outbound connections from 15 to 8 in RC4.\n15 was way more than we needed for redundancy. 8 is still plenty of redundancy.\nAs the nodes upgrade to this version, this will cut in half the number of connections that inbound accepting nodes get.\nIf anyone wants more than 8 connections, they can open port 8333 on their firewall."
	},
	{
		"id": 242,
		"date": "2010-07-04 21:52:28",
		"src": "https://bitcointalk.org/index.php?topic=199.msg1947#msg1947",
		"q": "Mac OS version - requires Intel processor and 10.5 (10.4 not supported)\nhttp://heliacal.net/~solar/bitcoin/builds/MacOSX-Intel-0.3/bitcoin-0.3.0.zip",
		"a": "Laszlo's build is going to be our first Mac release so please test it!"
	},
	{
		"id": 243,
		"date": "2010-07-05 21:31:14",
		"src": "https://bitcointalk.org/index.php?topic=234.msg1976#msg1976",
		"q": "Good revisions so far.\nMore suggestions:\n1) How about mentioning bittorrent instead of hashcash? Bittorrent is a huge buzz word and could grab some attention. As a completely distributed and anonymous network, I'd say that Bitcoin is similar enough to justify the comparison.\n2) \"...clients burn CPU cycles...\" --> \"...nodes burn CPU cycles...\"\n3) Throw in \"decentralized\" and \"proof-of-work based\" somewhere\n4) Personally, I'm still not fully satisfied with the mention of energy-backing. Maybe you could replace it with something about the time-stamped transaction history being voted on / secured by the majority of CPU power?\n5) Not to be a smartass, but watch out for passive voice (e.g. \"It is expected that over time...\"). Headlines and news articles usually try to grab readers' attention by using the more exciting active voice.\nFeel free to take all, none, or somewhere in between. We're critical because we care",
		"a": "BTW, I did come to my senses after that brief bout with 1.3, this release is still going to be 0.3 beta not 1.0.\nI really appreciate the effort, but there are a lot of problems.\nWe don't want to lead with \"anonymous\". (I've been meaning to edit the homepage)\n\"The developers expect that this will result in a stable-with-respect-to-energy currency outside the reach of any government.\" -- I am definitely not making an such taunt or assertion.\nIt's not stable-with-respect-to-energy. There was a discussion on this. It's not tied to the cost of energy. NLS's estimate based on energy was a good estimated starting point, but market forces will increasingly dominate.\nSorry to be a wet blanket. Writing a description for this thing for general audiences is bloody hard. There's nothing to relate it to."
	},
	{
		"id": 244,
		"date": "2010-07-06 19:43:18",
		"src": "https://bitcointalk.org/index.php?topic=199.msg2006#msg2006",
		"q": "I'm running rc4 on xp32/64 and everything seems ok so far,\ninstalled without problems, ~50connections on a forwarded node, 8 on others,\nlimited to 1(of2) and 1-2(of3) cores, which scales up nicely, but hasnt generated any coins yet.\nHopefully i'll get some tonight.",
		"a": "0.3 released\nhttp://bitcointalk.org/index.php?topic=238.msg2004#msg2004"
	},
	{
		"id": 245,
		"type": "ignore",
		"date": "2010-07-07 01:31:07",
		"src": "https://bitcointalk.org/index.php?topic=84.msg2010#msg2010",
		"q": "Maybe we should have an option dialog that allows you to choose the IRC server and channel you connect to?",
		"a": "Everybody needs to connect to the same IRC server and channel so they can find each other."
	},
	{
		"id": 246,
		"type": "ignore",
		"date": "2010-07-07 01:31:07",
		"src": "https://bitcointalk.org/index.php?topic=84.msg2010#msg2010",
		"q": "You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's.",
		"a": "It might not be good if we suddenly rushed freenode with a ton of users all at once.\nThe fallback is our own seed system.\nirc.lfnet.org is pretty old and has impressive uptime. I think it's going to be fine.\nWe could take IRC out at some point if we want, but I'd rather ease into it and just test our own seed system as a backup for now, and I really like the complementary redundant attributes of the two different systems."
	},
	{
		"id": 247,
		"date": "2010-07-08 18:24:19",
		"src": "https://bitcointalk.org/index.php?topic=246.msg2068#msg2068",
		"q": "I know it's not the smartest move to name my user account using non-latin characters. Anyway, 0.2 has no problems with this.\nVerified as follows... created a 'normal' new user and 0.3 opened the data folder. Created new, fresh data folder and copied it to the non-standard user - 0.3 fails with DB_RUN_RECOVERY.",
		"a": "Thanks for finding that. We switched from ANSI in 0.2 to UTF-8 in version 0.3, so it must be related to that.\nJust to confirm, if you log in with the non-latin character username, not having an appdata/Bitcoin directory yet, and run Bitcoin and let it create the database from scratch, does it work or not?"
	},
	{
		"id": 248,
		"type": "ignore",
		"date": "2010-07-08 19:12:00",
		"src": "https://bitcointalk.org/index.php?topic=241.msg2071#msg2071",
		"q": "Not bad.\nAs far as anonymous internet connections go, prepaid phones aren't a bad choice either. They're cheap, nearly impossible to tie to the user, and can be destroyed when finished. Again, they can be bought in densely crowded shopping malls or walmarts.\nDont forget to use an anonymous method to pay for the VPS foreverdamaged. Perhaps a prepaid credit card also bought from a crowded location would do the trick.\nBy the way, I like to imagine that this user is in China and is trying to buy a book about freedom",
		"a": "It's hard to imagine the Internet getting segmented airtight. It would have to be a country deliberately and totally cutting itself off from the rest of the world.\nAny node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone. It would only take one node to do it. Anyone who wants to keep doing business would be motivated.\nIf the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks. Their number of confirmations would start over.\nIf anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way.\nIt wouldn't be easy to take advantage of the segmentation to double-spend. If it's impossible to communicate from one side to the other, how are you going to put a spend on each side? If there is a way, then probably someone else is also using it to flow the block chain over.\nYou would usually know whether you're in the smaller segment. For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment. If you're in the smaller segment, you should assume nothing is confirmed."
	},
	{
		"id": 249,
		"type": "favorite",
		"date": "2010-07-09 03:28:46",
		"src": "https://bitcointalk.org/index.php?topic=242.msg2078#msg2078",
		"q": "It is unnecessary to protect against an attack in which an attacker buys all Bitcoins and deletes their wallet.\nAssuming we were all willing to sell, the attacker would just give us large amounts of cash for our Bitcoins. We could then start another Bitcoin block chain and start over from square one (only with a much larger confidence in the market, since it worked once!) and reinvest that money if we wanted.\nEssentially, no matter what happens there is always the nuclear option of \"starting over.\"\nThere are much more dangerous and likely attacks to be worried about.",
		"a": "What the OP described is called \"cornering the market\". When someone tries to buy all the world's supply of a scarce asset, the more they buy the higher the price goes. At some point, it gets too expensive for them to buy any more. It's great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices. As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell.\nThe Hunt brothers famously bankrupted themselves trying to corner the silver market in 1979:\n\"Brothers Nelson Bunker Hunt and Herbert Hunt attempted to corner the world silver markets in the late 1970s and early 1980s, at one stage holding the rights to more than half of the world's deliverable silver.[1] During Hunt's accumulation of the precious metal silver prices rose from $11 an ounce in September 1979 to nearly $50 an ounce in January 1980.[2] Silver prices ultimately collapsed to below $11 an ounce two months later,[2] much of the fall on a single day now known as Silver Thursday, due to changes made to exchange rules regarding the purchase of commodities on margin.[3]\"\nhttp://en.wikipedia.org/wiki/Cornering_the_market"
	},
	{
		"id": 250,
		"type": "ignore",
		"date": "2010-07-10 12:58:02",
		"src": "https://bitcointalk.org/index.php?topic=240.msg2132#msg2132",
		"q": "I second this, however I don't think block generation time should be changed. I think it should be identical to the production network. This, for example, would allow testers to try to subvert the system by creating nodes with particularly low latency, and keep the results applicable to the real network.\nGreat idea Gavin!",
		"a": "I'll start thinking about how to do this.\nAt the moment, you can kind of use -connect. You can use -connect to make it connect to local computers on your LAN, like -connect=192.168.0.100. If you start it out blank and don't let it connect to the main network, the difficulty is still at the original low difficulty. If you've port-forwarded though, then outside nodes might still connect inward to you.\nWith -connect it still uses IRC, do you think it shouldn't get on IRC when you're telling it to only connect to specific nodes with -connect? The main scenario for -connect is where you have a server farm, with two connected to the network and the rest connected to the first two. In that case, you wouldn't want the -connect computers on IRC.\nvoid ThreadIRCSeed(void* parg)\n{\nif (mapArgs.count(\"-connect\"))\nreturn;"
	},
	{
		"id": 251,
		"type": "favorite",
		"date": "2010-07-10 13:36:17",
		"src": "https://bitcointalk.org/index.php?topic=202.msg2133#msg2133",
		"q": "However, if something happened and the signatures were compromised (perhaps integer factorization is solved, quantum computers?), then even agreeing upon the last valid block would be worthless.",
		"a": "True, if it happened suddenly. If it happens gradually, we can still transition to something stronger. When you run the upgraded software for the first time, it would re-sign all your money with the new stronger signature algorithm. (by creating a transaction sending the money to yourself with the stronger sig)"
	},
	{
		"id": 252,
		"date": "2010-07-14 16:22:03",
		"src": "https://bitcointalk.org/index.php?topic=323.msg2867#msg2867",
		"q": "Okay, I solved the problem. The solution was in http://bitcointalk.org/index.php?topic=35.0.",
		"a": "So that was responsible for keeping blocks from downloading?\nThe link: \"Win32 CPU Cycles vs 'Live Protection' Engines\"\nFor BitcoinFX, Live Protection was keeping it from getting CPU for generating coins. You said your friend was getting 1400-1600 khash/s, so it was getting CPU. I guess Live Protection must have been blocking some other part of the program then?"
	},
	{
		"id": 253,
		"type": "ignore",
		"date": "2010-07-14 16:29:39",
		"src": "https://bitcointalk.org/index.php?topic=327.msg2871#msg2871",
		"q": "C:\\Windows\\System32\\cmd.exe /c start \"BitCoin\" /LOW /MIN \"C:\\Program Files\\Bitcoin\bitcoin.exe\"",
		"a": "In Windows, you select the process in the task manager, right click, Set Priority. Set it to BelowNormal or Low. That shouldn't make a difference though.\nIf you turn off Generate Coins, does the CPU usage go flat? That would confirm that all the CPU time it's taking is generate, which is idle priority already.\nIt could be it's slow just because you have too many things running at once and you're out of memory. When you switch from one thing to another, it has to page it in from disk."
	},
	{
		"id": 254,
		"date": "2010-07-14 17:04:02",
		"src": "https://bitcointalk.org/index.php?topic=343.msg2880#msg2880",
		"q": "Given the current jump in 'difficulty' at around 875 khash/s I should be generating a block every 2.8 days.\nSo, no complaints.... yet.\nhttp://www.alloscomp.com/bitcoin/calculator.php",
		"a": "Thanks for making that calculator.\nThe difficulty doubled a day or two ago, plus it's just random and you can have surprisingly long dry spells."
	},
	{
		"id": 255,
		"type": "ignore",
		"date": "2010-07-14 17:34:50",
		"src": "https://bitcointalk.org/index.php?topic=298.msg2885#msg2885",
		"q": "Looks like your wxWidgets and STL - you should compile your own wxWidgets from the 2.9 release.\nUse something like this to configure it and adjust the reference paths in your makefile.unix",
		"a": "It doesn't work with wxWidgets 2.8, it needs wxWidgets 2.9. Unfortunately, there isn't a Debian package of wxWidgets 2.9 yet."
	},
	{
		"id": 256,
		"type": "ignore",
		"date": "2010-07-14 17:38:31",
		"src": "https://bitcointalk.org/index.php?topic=72.msg2886#msg2886",
		"q": "lachesis - htop\nits awesome.. has ANSI colors, you can fully configure it to display all threads, tree view, etc ,etc",
		"a": "Laszlo corrected this, but unfortunately it was too late to make it into 0.3.0. There will probably be a 0.3.1 soon though.\nThe problem is I used PRIO_MIN, I should have used PRIO_MAX for the lowest priority. The OS isn't supposed to let you increase priority, so the PRIO_MIN ought to leave it at priority 0."
	},
	{
		"id": 257,
		"date": "2010-07-14 18:02:28",
		"src": "https://bitcointalk.org/index.php?topic=305.msg2895#msg2895",
		"q": "When I started bitcoin (windows) It started adding blocks, everything was going well. Then i went and port forwarded (I don't knwo if that's related) and around then, probably a bit after, it stuck at 513 blocks. I left it on overnight, and generated 11 more (to be precise, the 513 is from today, idk if it was that before or not, it was low 500s though) They all say Generated (50.00 matures in [118-108] more blocks). Also, I did the 5 free bitcoins website thing, and it hasn't given me them. I currently have 10 connections, 11 transactions, 513 blocks, and 0.00 balance. What should I do?",
		"a": "This is the second time I've seen this \"Live Protection\" problem reported.\nIt must be blocking the program's network communication. It sounds like it's allowing connections to be made, hence the 10 connections shown, but not allowing any data to be sent or received on them.\nWe need to understand this problem better.\nCan someone write some instructions on the wiki explaining how to turn off or add an exclusion to Live Protection or whatever its full proper name is."
	},
	{
		"id": 258,
		"type": "ignore",
		"date": "2010-07-14 18:25:41",
		"src": "https://bitcointalk.org/index.php?topic=318.msg2903#msg2903",
		"q": "Hi,\nTried bitcoind 0.3 on Ubuntu 10.04 and I get the following error when I run bincoind\n05:23:02 IST: Debug: ../src/common/intl.cpp(2554): assert \"!m_strShort.empty()\" failed in AddCatalog(): must initialize catalog first\n[Debug] Generating a stack trace... please wait../src/common/intl.cpp(2554): assert \"!m_strShort.empty()\" failed in AddCatalog(): must initialize catalog first\nCall stack:\n[00] 0x80ed73b\n[01] 0x80ebf3e\n[02] 0x80eca8a\n[03] 0x80ed06a\n[04] 0x8133e72\n[05] 0x8133ddf\n[06] 0x80e3942\n[07] 0x80e7181\nI get a similar error when running bitcoin UI but it has a continue handle and hence it works fine.\nCan somebody tell me what this error means and how to go about resolving this?",
		"a": "What language is your computer set to? Is it set to German, Dutch or Italian? Is it one of those sub-languages like \"nl-??\"?\nIt's trying to load a translation and failing. You could delete the locale directory that came with bitcoin so it doesn't try to use it.\nCan someone test each language on Ubuntu and see if there's a problem with just one of them or maybe all three?"
	},
	{
		"id": 259,
		"type": "ignore",
		"date": "2010-07-14 18:45:53",
		"src": "https://bitcointalk.org/index.php?topic=299.msg2908#msg2908",
		"q": "One fairly simple workaround is to run bitcoind as a user other than root. Since bitcoin does not require root permissions it will run just fine and it won't be able to set a negative niceness (only root can do that). That will ensure that the highest priority bitcoind can use is 0 (normal).",
		"a": "After it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block. When you've found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid. The generate thread only changes to higher priority for less than a second every few days.\nThere should be a 0.3.1 release for this soon. There are a few other issues we need to look at fixing in 0.3.1 before making a release."
	},
	{
		"id": 260,
		"type": "ignore",
		"date": "2010-07-14 18:45:53",
		"src": "https://bitcointalk.org/index.php?topic=299.msg2908#msg2908",
		"q": "On a side note, I've tracked down the other GUI issue.\nThe \"minimize to tray instead of taskbar\" is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.\nThis only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.\nI did notice on the 64 bit Client, what happens is, it spawns multiple \"tray\" icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?",
		"a": "That's interesting. I know the minimize to tray on Ubuntu is very clunky, but I didn't know it had a CPU peg problem too. Anyone else able to reproduce this problem? We had this feature disabled on Linux before, but then it seemed better to have the imperfect UI than to lose the feature entirely. I'm thinking we should disable it again on Linux."
	},
	{
		"id": 261,
		"date": "2010-07-14 18:56:29",
		"src": "https://bitcointalk.org/index.php?topic=291.msg2913#msg2913",
		"q": "Just got started with bitcoin. I followed the directions. Forwarded the port. Had quite a few connections up to 40 at one time. I wake up this morning and I see I have 12 connections. ANd five errors saying this bitcoin was generated but not received by any other nodes. I gave bitcoin access through the firewall and allowed an exception. I am running Windows 7 64 bit. Any ideas?\nBC: 1KDwVb4udipVSYLgRPWg9GiFiKJpXBFPHg",
		"a": "Microsoft Security Essentials Live Protection is blocking your communication with the network. You have connections, which tricks Bitcoin into thinking it's connected, but they are silent because the data is being blocked.\nYou need to make bitcoin.exe an excluded process in Live Protection.\nThis is becoming a common problem. Someone should write this up in a pegged thread.\nThe message \"Warning: This block was not received by any other nodes\" occurs when Bitcoin broadcasts a block, but nobody confirms they received it. The warning is there just for this kind of situation, where for some reason you have connections, but they have gone dead and nobody can hear you. Your block will never become valid because nobody received it."
	},
	{
		"id": 262,
		"type": "favorite",
		"date": "2010-07-14 20:25:06",
		"src": "https://bitcointalk.org/index.php?topic=325.msg2935#msg2935",
		"q": "So if your computer was only 1% towards solving block 68000",
		"a": "This is a common point of confusion. There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.\nIt's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.\nThe RNG is the OpenSSL secure random number generator. On Windows it's seeded with the complete set of all hardware performance counters since your computer started, on Linux it's dev/random."
	},
	{
		"id": 263,
		"date": "2010-07-14 21:10:52",
		"src": "https://bitcointalk.org/index.php?topic=286.msg2947#msg2947",
		"q": "What can be done if the block chain becomes very large?",
		"a": "The design outlines a lightweight client that does not need the full block chain. In the design PDF it's called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can't generate blocks. It does not need to trust a node to verify payments, it can still verify them itself.\nThe lightweight client is not implemented yet, but the plan is to implement it when it's needed. For now, everyone just runs a full network node.\nI anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.\nAt equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN."
	},
	{
		"id": 264,
		"type": "ignore",
		"date": "2010-07-15 00:18:23",
		"src": "https://bitcointalk.org/index.php?topic=299.msg3008#msg3008",
		"q": "Could you make it possible to reenable that feature with a startup switch or even compile flag? I like it a lot, and I don't have this issue.",
		"a": "OK, the undocumented switch \"-minimizetotray\" which re-enables the option.\nI uploaded the change to SVN."
	},
	{
		"id": 265,
		"type": "ignore",
		"date": "2010-07-15 14:05:20",
		"src": "https://bitcointalk.org/index.php?topic=373.msg3150#msg3150",
		"q": "http://bitcointalk.org/index.php?topic=316.0\nMaybe that thread helps.",
		"a": "More directly, this:\nhttp://bitcointalk.org/index.php?topic=246.0\nI will be posting release candidate of 0.3.1 with this fix shortly. Please try that and let me know if it fixes the problem."
	},
	{
		"id": 266,
		"date": "2010-07-15 14:33:04",
		"src": "https://bitcointalk.org/index.php?topic=326.msg3157#msg3157",
		"q": "Is it possible to statically link the c++ library? If it is possible, is it something that is an acceptable practice or does it cause problems? Maybe just include the library with the program? When I said static I was only referring to openssl",
		"a": "We don't even specify linking glibcxx_3.4.11, so gcc must automatically link it behind the scenes. There's probably a compiler switch that would tell it to static link it. I'm not sure what the licensing issues would be. Typically, compiler stuff is fully redistributable."
	},
	{
		"id": 267,
		"date": "2010-07-15 14:59:00",
		"src": "https://bitcointalk.org/index.php?topic=327.msg3162#msg3162",
		"q": "thanks every one for your help\nhave tried manually setting priority to below normal, and it plays nice!! but stays at 100%\nalso, when i turn off generate coins, cpu usage drops to zero!\nturning generate on sends cpu back up to 100%",
		"a": "Then all the CPU time is the generate thread, which definitely runs at the lowest possible priority, idle priority. It's normal that your CPU meter is 100%. Since it's idle priority, it won't actually slow anything else down, even though the CPU meter is 100%."
	},
	{
		"id": 268,
		"date": "2010-07-15 17:23:48",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3205#msg3205",
		"q": "hi satoshi,\nare there any back-ups need to be done before installing?",
		"a": "Well, it can't hurt to do a backup and it's a good idea to backup regularly, but no, a backup is not required before installing this."
	},
	{
		"id": 269,
		"type": "ignore",
		"date": "2010-07-15 17:56:43",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3221#msg3221",
		"q": "on this end,\nhasn't helped.\nstill same symptoms, but can't set to belownormal. access is denied!!\nstrange,\nfirefox and windows explorer open quickly enough, bit laggy, but the likes of gomez doesn't!",
		"a": "I don't think you have a particular problem, I think your system is laggy because you're running a lot of things at once and hitting the pagefile because memory is full. You confirmed when you shut off generation that your CPU drops to 0%, so the CPU usage is definitely all idle priority. There's nothing in the 0.3.1 that would affect these things."
	},
	{
		"id": 270,
		"type": "ignore",
		"date": "2010-07-15 18:30:22",
		"src": "https://bitcointalk.org/index.php?topic=151.msg3238#msg3238",
		"q": "Ok here is the .po file for French. While I'm at it, I noted a couple of issues:\n1. The \"About\" box didn't take the translation into account, it still displays the english version to me, even though the rest of the software is using the translated strings, and the .po file contains the translation string of the \"About\" box message. Same problem with the \"Apply\" button in the Settings window.",
		"a": "I need to give an updated .po file."
	},
	{
		"id": 271,
		"type": "ignore",
		"date": "2010-07-15 18:30:22",
		"src": "https://bitcointalk.org/index.php?topic=151.msg3238#msg3238",
		"q": "2. If an transaction's description in the list of transaction in the main window contains a diacritical character (such as \"éàèç\"), it's not displayed. I suppose the string is not being properly handled as UTF8 somewhere.",
		"a": "OK, this must be a problem somewhere, I'll have to take a look at it or one of the other devs can."
	},
	{
		"id": 272,
		"type": "ignore",
		"date": "2010-07-15 18:30:22",
		"src": "https://bitcointalk.org/index.php?topic=151.msg3238#msg3238",
		"q": "4. About the .po file :\n- There are a few strings in the .po file that don't needs translation (ie: \"Bitcoin\"). Maybe those shouldn't be inside _(\"...\") ?\n- Others shouldn't be split. I can remember one message about transaction fee where the string is split in two to insert the fee value, where you could simply have put a %s. It makes the message harder to translate as I had to go in the source to find exactly what was going on.\n- Some strings have whitespace at the end or start, which necessity is very debatable, and it's easy to miss in PoEdit.",
		"a": "Many of the strings are in code automatically generated from uiproject.fbp where nothing can be done about these things. I have a program I use to find all the spacing inconsistencies at the beginning and ending of strings in your .po file and manually fix them up before I upload them to SVN."
	},
	{
		"id": 273,
		"date": "2010-07-15 18:43:54",
		"src": "https://bitcointalk.org/index.php?topic=151.msg3247#msg3247",
		"q": "I recommend to remove the download links at the bottom of the main page.\nAs you can see the links on the English page points to the new 0.3 release, but the other languages only contain links for the old 0.2 version.\nThere's a download box with the current releases on the right anyway, so why not remove the links from the translated pages.",
		"a": "I updated them to 0.3.0.\nI am tempted to remove the download links from the other languages and only keep it on English.\nThey will need to be updated for 0.3.1 soon. Perhaps there's a way for someone to manage the updating of the translated drupal pages."
	},
	{
		"id": 274,
		"type": "ignore",
		"date": "2010-07-15 21:40:34",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3295#msg3295",
		"q": "On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.",
		"a": "I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn't get any CPU to update it.\nDo you have dual-proc? Are you sure you weren't running a single processor hog?"
	},
	{
		"id": 275,
		"date": "2010-07-15 22:07:35",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3305#msg3305",
		"q": "On the Linux client (64 bit), the \"minimize on close\" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).",
		"a": "I updated the first post with a link to rc2 for linux with the fix for this. Please check that this is fixed for you. Thanks!\nhttp://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz"
	},
	{
		"id": 276,
		"type": "ignore",
		"date": "2010-07-15 22:10:19",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3306#msg3306",
		"q": "The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)",
		"a": "Yes a bug. It'll have to be fixed in the next version."
	},
	{
		"id": 277,
		"type": "ignore",
		"date": "2010-07-15 22:18:26",
		"src": "https://bitcointalk.org/index.php?topic=391.msg3308#msg3308",
		"q": "In Windows, when opening the \"Send Coins\" or the \"Your Receiving Addresses\", I get the following message.\nClicking Cancel allows me to make it go away, and everything still works fine, but it is still a bit annoying.\nI am running BitCoin 0.3.0 on Windowx Vista SP2 x64.",
		"a": "That's surprising that we've never heard of that before now.\nMaybe you're the first person to ever run it on Vista\nI have to guess it has something to do with your display color depth selection. e.g. 8-bit, 16-bit, 24-bit, 32-bit, what is it? Do you have a weird video card, display setup or running it on a tablet or mobile or something?"
	},
	{
		"id": 278,
		"type": "ignore",
		"date": "2010-07-15 22:22:30",
		"src": "https://bitcointalk.org/index.php?topic=299.msg3309#msg3309",
		"q": "I like it alot too, wished it work for me",
		"a": "The fix for the thread priority level on linux is available in the 0.3.1 release candidate here:\nhttp://bitcointalk.org/index.php?topic=383.msg3198#msg3198"
	},
	{
		"id": 279,
		"type": "ignore",
		"date": "2010-07-15 23:23:04",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3319#msg3319",
		"q": "I don't see either happening, although it did get put into the \"Startup\" folder. That is so Windows 95ish (just kidding..... Microsoft has so screwed this up that it isn't even funny). I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows should behave.",
		"a": "It could go either way. The Startup folder has the advantage that the end user can see it and manually remove it with the regular UI (not regedit) if they already blew away the Bitcoin directory and its uninstaller. Bitcoin will not relentlessly keep re-adding it if you delete it manually.\nOpenOffice is another example of something that puts its link in the Startup folder."
	},
	{
		"id": 280,
		"type": "ignore",
		"date": "2010-07-15 23:41:23",
		"src": "https://bitcointalk.org/index.php?topic=391.msg3323#msg3323",
		"q": "in 120DPI mode.",
		"a": "What is \"120DPI mode\"? Is that an actual setting somewhere? Sounds like an obscure enough candidate. I suppose it needs twice the resolution icon to fill the size of the upper left corner icon. Only one size is provided."
	},
	{
		"id": 281,
		"type": "ignore",
		"date": "2010-07-16 00:44:32",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3339#msg3339",
		"q": "Satoshi, you didn't fix the bug; you just ripped out the minimize to tray code. Could you possibly make this optional? I wasn't experiencing the original bug, and I very much like the minimize to tray feature.",
		"a": "Run it with the undocumented switch -minimizetotray and the option is available in the options menu.\nI don't know how to fix it. It's something wrong deep inside wxWidgets or GTK or Gnome."
	},
	{
		"id": 282,
		"date": "2010-07-16 02:02:07",
		"src": "https://bitcointalk.org/index.php?topic=295.msg3350#msg3350",
		"q": "i send my 5 coins back right after i got them,\nwas a great way to check our system and still is a great way for new \"potential customers\", to test us.\nregrettably i havent been around back in those early days, but i'll gladly send all incoming 5coin credits back to you.",
		"a": "5 BTC seems like a lot these days, maybe the normal amount should be 1 or 2 BTC.\nThis is an important service so new users can at least get something if generating is too hard."
	},
	{
		"id": 283,
		"date": "2010-07-16 02:43:29",
		"src": "https://bitcointalk.org/index.php?topic=391.msg3362#msg3362",
		"q": "Also using 120 DPI here. Same bit depth and resolution as the previous user as well.",
		"a": "That must be it then.\nIt must be looking for a larger icon like 20x20 but we don't have one."
	},
	{
		"id": 284,
		"date": "2010-07-16 14:46:12",
		"src": "https://bitcointalk.org/index.php?topic=43.msg3488#msg3488",
		"q": "13/07/2010 0000000005a3f437d4a7f529fd4a7f529fd4a7f529fd4a7f529fd4a7f529fd4a",
		"a": "The proof-of-work difficulty is currently 45.38. (see http://www.alloscomp.com/bitcoin/calculator.php)\nIt's about to increase again in a few hours. It's only been 3-4 days since the last increase, so I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54.\nThe target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase."
	},
	{
		"id": 285,
		"type": "ignore",
		"date": "2010-07-16 14:52:04",
		"src": "https://bitcointalk.org/index.php?topic=400.msg3492#msg3492",
		"q": "I'm running Ubuntu Lucid (32 bit), all packages up to date. I had run bitcoin 0.2 previously, and just downloaded 0.3. I ran bitcoind and I got:\nbitcoin: main.cpp:823: unsigned int GetNextWorkRequired(const CBlockIndex*): Assertion `pindexFirst' failed.\nAborted\nSo I ran the bitcoin GUI, and it came up and showed my existing coins, but quickly gave me the same error and died. Then I went back and ran the 0.2 GUI again and I get:\nbitcoin: main.cpp:743: unsigned int GetNextWorkRequired(const CBlockIndex*): Assertion `pindexFirst' failed.\nAborted\nHas my db got corrupted? Do I have a broken dependancy?\nI tried to build 0.3 from source but got many errors, probably missing some *-dev packages. Will look at that more later.",
		"a": "That's the first time I've seen this error.\nHow many blocks do you have? (in the status bar)\nYou should move your blk*.dat files (in ~/.bitcoin) to another directory and let it start over downloading the block chain again. If you don't mind, could you keep the old blk*.dat files for a little while in case I need to look at them?"
	},
	{
		"id": 286,
		"type": "ignore",
		"date": "2010-07-16 14:55:23",
		"src": "https://bitcointalk.org/index.php?topic=296.msg3495#msg3495",
		"q": "I'll pledge my first hundred bitcoins to anyone who can post a 32-bit Fedora version. I'd pledge more, except I don't know how many I'll be able to generate. Perhaps other 32-bit Fedora users can add their pledges to mine.",
		"a": "Please try the 0.3.1 release candidate, it should at least resolve the libcrypto dependency:\nhttp://bitcointalk.org/index.php?topic=383.0\nLet me know if that works."
	},
	{
		"id": 287,
		"type": "ignore",
		"date": "2010-07-16 15:01:33",
		"src": "https://bitcointalk.org/index.php?topic=303.msg3499#msg3499",
		"q": "0/unconfirmed means that your client has seen the transaction\n1/unconfirmed means that your transaction has been included in 1 block, at this point you can be reasonably sure someone has picked up your transaction and it's now in the chain.\nas the number of confirmations increases, so does the confidence in the 'truth' of the transaction.\nThere is no way to cancel a transaction.\nIt is not possible with the current client to resend a transaction.",
		"a": "Bitcoin automatically rebroadcasts your transactions if it receives new blocks that don't contain them. It may take about an hour to get rebroadcasted. It is relentless though. It will keep nagging the network forever until your transaction gets into a block."
	},
	{
		"id": 288,
		"date": "2010-07-16 15:09:59",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3505#msg3505",
		"q": "Build 0.3.1 on an x86 gentoo linux system with my own makefile (builds a dynamic client instead of a static one), seems to run more smoothly than 0.3.0.\nB.T.W. Why does the standard makefile builds a static version anyway?",
		"a": "Because of all the dependencies that different systems don't have. It's easier to just static link what we can. It doesn't increase the size by very much."
	},
	{
		"id": 289,
		"type": "ignore",
		"date": "2010-07-16 15:37:00",
		"src": "https://bitcointalk.org/index.php?topic=393.msg3510#msg3510",
		"q": "I didn't think this would be something people would object to. Hopefully I hear definitively from Satoshi that it is OK. I will probably start working on this tonight then (tonight in USA time). Also, I saw another thread questioning how to send in patches; the stated answer was that we should e-mail them to Satoshi, is this still the preferred method?\n-Buck",
		"a": "I like that in libraries for the external API's, but you can probably tell from the code that I'm not a fan of it for interior functions. Big obligatory comment headers for each function space out the code and make you hesitate about creating a small little function where the comment header would be bigger than the function. They're some trouble for maintenance, as changes to the function then require duplicate changes in the comment header. I like to keep code compact so you can see more code on the screen at once.\nTo add them now at this point, what would be written would just be what's obvious from looking at the function.\nThe external API we have, in rpc.cpp, the usage documentation is in the help string.\nSorry to be a wet blanket."
	},
	{
		"id": 290,
		"type": "favorite",
		"date": "2010-07-16 16:13:53",
		"src": "https://bitcointalk.org/index.php?topic=360.msg3520#msg3520",
		"q": "It's doubtful that SHA2 would be that broken before all coins have been minted. The issue is it then becomes a question of how much it costs to hijack someone's bank account.",
		"a": "SHA256 is not like the step from 128 bit to 160 bit.\nTo use an analogy, it's more like the step from 32-bit to 64-bit address space. We quickly ran out of address space with 16-bit computers, we ran out of address space with 32-bit computers at 4GB, that doesn't mean we're going to run out again with 64-bit anytime soon.\nSHA256 is not going to be broken by Moore's law computational improvements in our lifetimes. If it's going to get broken, it'll be by some breakthrough cracking method. An attack that could so thoroughly vanquish SHA256 to bring it within computationally tractable range has a good chance of clobbering SHA512 too.\nIf we see a weakness in SHA256 coming gradually, we can transition to a new hash function after a certain block number. Everyone would have to upgrade their software by that block number. The new software would keep a new hash of all the old blocks to make sure they're not replaced with another block with the same old hash."
	},
	{
		"id": 291,
		"type": "favorite",
		"date": "2010-07-16 16:47:14",
		"src": "https://bitcointalk.org/index.php?topic=397.msg3524#msg3524",
		"q": "I think of my machines running bitcoin as slot machines. I put in CPU time and energy costs in at a regular rate, and once in a while I get money back. If I'm to treat bitcoin as part of a business, then I need to be able to calculate my expected return on investment, just as a casino owner needs to be able to calculate how much money she's making off of her slot machines. I know that the bitcoin generation difficulty will stabilize at some point in the future, but at this point it would be useful to me to be able to calculate my ROI quickly and easily.\nSo, if nobody else is going to do it, I'll probably make a patch for this. Bitcoin donations appreciated, of course, and would help motivate me to make it available quickly.",
		"a": "Many businesses are like that. For a car salesman, when will the next customer walk in the door?\nOn the OP's question, it's a good feature, but the question is, how would we word it so people don't expect to get something after that specific amount of time? \"it said 7 days and I waited more than a week and didn't get anything!\" Approx, average, but still they're going to think that way. It can't be a whole sentence, unless we think of somewhere else to put it, but where would that be? Suggestions?\nThe difficulty quadrupled a few minutes ago to 181.54. It's going to take typically about a week to generate now."
	},
	{
		"id": 292,
		"type": "favorite",
		"date": "2010-07-16 16:56:54",
		"src": "https://bitcointalk.org/index.php?topic=43.msg3526#msg3526",
		"q": "If I'm reading the source code correctly, it should go up and down based on how much CPU is being thrown at it. So if someone rented a super computer to drive up the difficulty for a week, then it vanished, the difficulty should float back down.",
		"a": "It adjusted to 181.54 a few minutes ago. Typical time to get a block is about a week now.\nThe difficulty can adjust down as well as up.\nThe network should be generating close to 6 blocks per hour now."
	},
	{
		"id": 293,
		"type": "ignore",
		"date": "2010-07-16 17:15:47",
		"src": "https://bitcointalk.org/index.php?topic=393.msg3534#msg3534",
		"q": "No problem, that is why I asked about documentation before I started writing it. I still would like to document it though and maybe we can come to some system which you would find acceptable. One possible way is that I just run Doxygen on my own code and just use the auto-generated docs without adding any descriptions, etc. This would have no impact on the project and myself or anyone else could do this whenever but it limits the usefulness of the documentation.\nA second, and perhaps more appealing method would be to utilize the fact that Doxygen does not require the added documentation to be in the same file as the source code it is documenting. We could add a single file that contains the documentation blocks with links pointing to the function names. Doxygen then combines this with the auto-generated info it collects from the source to produce the docs.\nFinally, whether we use Doxygen or not, I would like to write a \"man page\" for the program documenting the command-line options it takes. Where is the command line processed in the code? I looked at main.cpp and didn't see it (in fact I couldn't even find the \"main\" function).\n-Buck",
		"a": "It's in init.cpp.\nIt's a wxWidgets app, so it doesn't have a main() function. It may in a little while, since I'm pretty close to making bitcoind build w/o wxBase. (it'll be in init.cpp)\nSorry about my choice of the filename \"main.cpp\", another possible name would have been \"core.cpp\". It's much too late to change. I still prefer main.cpp.\nWe're still in great need of sample code showing the recommended way to use the JSON-RPC functions, like for a basic account system on a typical storefront website. Using getreceivedbylabel using the username as the label, changing to a new bitcoin address once the stored one for that account gets used. I posted a sample code fragment on the forum somewhere. (search on getreceivedbylabel or getnewaddress) The sample code could be a plain vanilla bank site where you can deposit and send payments."
	},
	{
		"id": 294,
		"type": "ignore",
		"date": "2010-07-16 17:26:17",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3536#msg3536",
		"q": "Anyone notice, that for Windows Clients anyway, when you connect a bunch of other clients to it manually (through the -connect option) that if you go over 8, the windows client ends up cutting out the \"outside world\" connections and stick with the original 8 or more internal machines thinking that it's the entire network?\nI never noticed this since I use a Linux client to funnel all my PCs to the outside world, but I tried it with a Windows client and noticed that at first, it had about 10 connections, then after adding another 50 clients internally that connect directly to it, the number would eventually drop down to just \"internal clients\" only.\nWhen this happens, the block count doesn't increment anymore, basically the Windows client has separated itself from \"the network\" and all the other clients all think that they are the entire network now. If I do a \"netstat -a -n\" on the windows client, I can see it's only connected to the Internal clients and the IRC bootstrap channel and basically doesn't to connect to anyone else on the outside world. You know it's happening because the block count starts to fall behind of what is really going on outside of your local network (Internet for the rest of the world)\nIt's kind of a self-collapsing loop? Doesn't seem to affect Linux clients though, they will happily connect to and be connected to about as many as it can handle. I could see this is kind of a DoS on windows clients if someone was evil enough.",
		"a": "Good point. If you're going to have more than 8 LAN nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections. Otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections. As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them. You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you."
	},
	{
		"id": 295,
		"date": "2010-07-16 17:29:28",
		"src": "https://bitcointalk.org/index.php?topic=43.msg3537#msg3537",
		"q": "Yeah, I've noticed the \"10 second blocks\" are gone, replaced with 419 and 741 second block generation with no more in the last 20 minutes. That should keep those server farms on hold for a while\nNow, correct me if I'm wrong, but now that block generation is taking a lot longer, doesn't that mean that the lucky person who got the block is going to take a lot longer to be verified by the network that he/she was the winner before they could ever spend it?",
		"a": "Yes, about 20 hours. (120 conf / 6 blocks per hour = 20 hours) That's the normal length of time before you can spend it. You know long before that that you won one."
	},
	{
		"id": 296,
		"date": "2010-07-16 17:47:05",
		"src": "https://bitcointalk.org/index.php?topic=378.msg3540#msg3540",
		"q": "could there be a possible copyright thing here?\ndid a search for bitcoin on twitter and came up with these links...\nhttp://twitter.com/bitcoin\nwhich leads to\nhttp://bitcoin.com/\nor are these somehow related?",
		"a": "No, not related at all."
	},
	{
		"id": 297,
		"date": "2010-07-16 17:58:44",
		"src": "https://bitcointalk.org/index.php?topic=403.msg3545#msg3545",
		"q": "Don't forget to amortize your fixed costs. Those parts don't last forever and eventually need replacing.",
		"a": "Neat chart.\nDifficulty just increased by 4 times, so now your cost is US$0.02/BTC."
	},
	{
		"id": 298,
		"date": "2010-07-16 18:23:04",
		"src": "https://bitcointalk.org/index.php?topic=364.msg3559#msg3559",
		"q": "*nods* It's a good initiative, and ANY development in the interest of bitcoins right now is good development.",
		"a": "I've been trying to encourage someone to write and release some sample Python code showing the recommended way to do the typical accounting stuff, but to no avail. It would be nice if you didn't have to re-invent the wheel like you're doing here. Search on getnewaddress and you should find a thread where I gave a small fragment of sample pseudocode."
	},
	{
		"id": 299,
		"date": "2010-07-16 18:43:51",
		"src": "https://bitcointalk.org/index.php?topic=43.msg3565#msg3565",
		"q": "I think that the overall network is generating the same amount of blocks regardless of the difficulty; the difficulty is intended so that the network generates a block in a relatively constant amount of time. Therefore, this confirmation time should always be around the same.\nSatoshi or anyone else can correct me if I'm wrong",
		"a": "Right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour. The time for your block to mature will always be around 20 hours.\nThe recent adjustment put us back to close to 6 blocks per hour again.\nThere's a site where you can see the time between blocks, and since block 68545, it's been more like 10 minutes per block:\nhttp://nullvoid.org/bitcoin/statistix.php"
	},
	{
		"id": 300,
		"type": "ignore",
		"date": "2010-07-16 21:06:57",
		"src": "https://bitcointalk.org/index.php?topic=383.msg3590#msg3590",
		"q": "I think size (static binary is 8x as big in my case) is not the problem, but security.\nBoost, openssl and Berkeley DB are fairly common on unix systems (many things depend on them) and also Wxwidgets (the only argument is that bitcoin uses the current development branch and not the stable branch). Second, static linking doesn't mean you can always run it (in my case it tries to load libpng-1.2, which is not present on my system, libpng-1.4 is, and the static fails to load). Third, openssl hasn't been free of security issues, by statically compiling people keep using the insecure version even if their system provides an updated safe version.",
		"a": "I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.\nYou don't need to update to 0.3.1 unless you had one of the problems listed in the first post. If you've got it working already, stay with 0.3.0."
	},
	{
		"id": 301,
		"type": "ignore",
		"date": "2010-07-16 22:20:09",
		"src": "https://bitcointalk.org/index.php?topic=128.msg3605#msg3605",
		"q": "When I run bitcoin it becomes very sluggish, almost unusable. When I stop bitcoin everything goes ok again. Its running Ubuntu desktop 10.04 amd64 using ia32libs and the binary in bitcoin 0.20 tarball.",
		"a": "0.3.1 fixes that, sets the generate threads to the lowest priority. Download links are on the homepage now."
	},
	{
		"id": 302,
		"type": "ignore",
		"date": "2010-07-17 16:06:12",
		"src": "https://bitcointalk.org/index.php?topic=432.msg3769#msg3769",
		"q": "Check this out...\nI just installed 0.3.1 on two different machines and moved one bitpenny (0.01):\n-= Before the transfer =-\n[bitcoind@box1 ~]$ ~/bin/bitcoind getinfo\n{\n\"balance\" : 1.150000000000,\n\"blocks\" : 68717,\n\"connections\" : 6,\n\"proxy\" : \"\",\n\"generate\" : false,\n\"genproclimit\" : -1,\n\"difficulty\" : 181.5432893640505\n}\n[bitcoind@box2 ~]$ ~/bin/bitcoind getinfo\n{\n\"balance\" : 0.000000000000,\n\"blocks\" : 68717,\n\"connections\" : 22,\n\"proxy\" : \"\",\n\"generate\" : false,\n\"genproclimit\" : -1,\n\"difficulty\" : 181.5432893640505\n}\n-= AFTER the transfer =-\n[bitcoind@box1 ~]$ ~/bin/bitcoind getinfo\n{\n\"balance\" : 1.139999999999,\n\"blocks\" : 68717,\n\"connections\" : 10,\n\"proxy\" : \"\",\n\"generate\" : false,\n\"genproclimit\" : -1,\n\"difficulty\" : 181.5432893640505\n}\n[bitcoind@box2 ~]$ ~/bin/bitcoind getinfo\n{\n\"balance\" : 0.010000000000,\n\"blocks\" : 68717,\n\"connections\" : 20,\n\"proxy\" : \"\",\n\"generate\" : false,\n\"genproclimit\" : -1,\n\"difficulty\" : 181.5432893640505\n}\nI personally think it is a display problem, but I can't be sure.. strange, no?\nBoth machines are running FreeBSD 7.2/amd64.",
		"a": "It must be a rounding error when getinfo converts to floating point to return the JSON-RPC result. The only place where it uses floating point to represent money is returning a value in JSON-RPC.\n1.139999999999 is longer than bitcoin can internally represent.\ninternally, it could only be:\n1.13999999 or\n1.14000000\n1.139999999999 is much much closer to 1.14000000 than 1.13999999, so it must be 1.14000000.\nThe code is this:\n(double)GetBalance() / (double)COIN.\n(I can't think of an easy way to fix it at the moment)"
	},
	{
		"id": 303,
		"date": "2010-07-17 16:27:39",
		"src": "https://bitcointalk.org/index.php?topic=434.msg3770#msg3770",
		"q": "Isn't this just a result of restoring to an out of date backup?\nThat aside,\nSimple possible change return methods:\na) change gets returned to the address it came from.\nb) change gets returned to a newly generated bitcoin address.\nMost people wont care and will expect the a) behavior, so make this the default.\nThose who care about the privacy of their transactions can enable b) through some option setting in the client.",
		"a": "We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed. They aren't very big, so it wouldn't hurt to have a lot of them. This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it. Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.\nThe addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses. When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.\nThere's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat. I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored."
	},
	{
		"id": 304,
		"type": "favorite",
		"date": "2010-07-17 16:56:06",
		"src": "https://bitcointalk.org/index.php?topic=431.msg3773#msg3773",
		"q": "If he was generating one block per minute before the difficulty increase that would mean he is actually representing more than 50% of bitcoin's CPU power. Actually, rather nearly all of it.",
		"a": "0.3.2 has some security safeguards to lock in the block chain up to this point and limit the damage a little if someone gets 50%.\nBut if someone has 50%+ of the CPU power and malicious intent, they can prove what it already says in the design document."
	},
	{
		"id": 305,
		"date": "2010-07-17 22:29:13",
		"src": "https://bitcointalk.org/index.php?topic=423.msg3819#msg3819",
		"q": "a prepaid account with the snack machine company works great for snack machines in corporate cafeterias (or other places with a fairly static consumer base) not so much for areas with a large transitory consumer base, such as airports, ferry boats, train stations etc.",
		"a": "I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.\nThe network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.\nA rough back-of-the-envelope example:\n1 0\n4 1\n16 4\n64 16\n80% 20%\nSo if a double-spend has to wait even a second, it has a huge disadvantage.\nThe payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn't get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes."
	},
	{
		"id": 306,
		"date": "2010-07-17 22:37:06",
		"src": "https://bitcointalk.org/index.php?topic=400.msg3823#msg3823",
		"q": "My coins disappeared, but I assume they'll come back when it's up to current?",
		"a": "Right, they'll re-appear when it's finished downloading all the blocks."
	},
	{
		"id": 307,
		"date": "2010-07-17 22:54:24",
		"src": "https://bitcointalk.org/index.php?topic=437.msg3825#msg3825",
		"q": "However, it's important that you don't lock all the way up the very latest block. Otherwise, the attacker could generate a fake block (or a few) right before you happen to lock it, and then his attack would be far easier than it would have been without the block lock.",
		"a": "I went about 200 blocks back. The block chain was a clean straight line without branches, and there was only one known version of the locked block."
	},
	{
		"id": 308,
		"date": "2010-07-17 22:54:24",
		"src": "https://bitcointalk.org/index.php?topic=437.msg3825#msg3825",
		"q": "Also, I'm assuming that the block lock means that the blocks will also come prepackaged with the client. Is this so?",
		"a": "Sorry, not yet, but I do want to make the initial block download faster."
	},
	{
		"id": 309,
		"type": "ignore",
		"date": "2010-07-17 23:18:30",
		"src": "https://bitcointalk.org/index.php?topic=393.msg3828#msg3828",
		"q": "Thanks Insti. I got the man page written. I documented all of the command line switches the program supports, not just the ones in the usage output given by \"bitcoin -h\". Any of the ones that do not appear in the usage output should have a comment in the man page file noting this (comment lines start with .\" which is a period then a double quote).\nI provided the update as a patch since I also made some changes to the sourcecode itself. If you want to install the man page first extract it from the diff file with the patch program and then copy the file \"bitcoin.1\" to section 1 of you man pages. On my Ubuntu systems the directory /usr/local/man/man1/ serves as a good place to keep it. Actually on my systems I put a symlink from there to the bitcoin/trunk/bitcoin.1 file so it stays up to date if it gets updated in SVN.\nI have also exported the man page using man2html and will post this to the wiki so people can reference it without having to install it on their systems, as well as for the underprivileged Windows users who have to forgo the true awesomeness of the man page system.\nAttached to this message you should find a zip file with the patch in it.\nThe wiki doesn't seem to be sending the registration e-mail so I can log in to edit, is there some problem with the server or something?\n-Buck",
		"a": "I didn't realize you were going to document all the intentionally undocumented commands. They're unsupported and not intended to be used by users.\nAll the user-facing commands are listed in the -? help."
	},
	{
		"id": 310,
		"type": "ignore",
		"date": "2010-07-17 23:25:16",
		"src": "https://bitcointalk.org/index.php?topic=419.msg3830#msg3830",
		"q": "Version 0.3 was supposed to reduce the number of outgoing connections on non-port forwarded clients from 15 to 8, but I don't think it really happened. I'm not positive if this is the case. Correct me if I'm wrong.",
		"a": "In 0.3.0, the change to 8 only ended up in the Windows version, the other versions still had 15.\nPlease upgrade to 0.3.2, it's available now."
	},
	{
		"id": 311,
		"date": "2010-07-18 01:59:15",
		"src": "https://bitcointalk.org/index.php?topic=423.msg3867#msg3867",
		"q": "This is a good start, but still not impermeable.",
		"a": "I didn't say impermeable, I said good-enough. The loss in practice would be far lower than with credit cards."
	},
	{
		"id": 312,
		"date": "2010-07-18 01:59:15",
		"src": "https://bitcointalk.org/index.php?topic=423.msg3867#msg3867",
		"q": "(for example, by refusing to propogate word of the transaction at the vending machine)",
		"a": "No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants. Think something like a credit card processor with a new job. They would have many well connected network nodes."
	},
	{
		"id": 313,
		"type": "ignore",
		"date": "2010-07-18 15:12:54",
		"src": "https://bitcointalk.org/index.php?topic=393.msg3999#msg3999",
		"q": "I wondered if they were not really meant to be public facing. I think they are useful to have documented though, at least for now. If the program accepts it as valid input it should be documented. You can either add a notice to the commands in the man-page that are experimental, or just remove them. In my opinion it makes more sense to label them experimental so people know they might change, but can use them if they need to. I would just add the following to the beginning of each of the commands in the makefile:\nBUnsupported - Behaviour may change in future versions\fR\nThe \fB switches on bold text and the \fR switches back to regular. This way people can use the program to its fullest potential during the development stages. Too much documentation is never a bad thing, especially for an open source project. Since people can see the code they will find these calls anyway and use them whether you want them to or not. If they are documented and marked as volatile then people can at least make an informed choice on whether or not they want to use them.\nFor example, just at the moment someone in IRC is making use of the -printblock command to generate statistics about the block chain that might help us understand the program better (as in how it performs in the real world). Although the output of this command may change in the future, and therefore we shouldn't be building complex frameworks around it, it is nice to know it exists if you need something done as a quick hack. Also because the program is open source, if someone comes to depend on a certain command line switch they can maintain it. Eventually what you thought was just a temporary debugging tool make end up being one of the most widely used switches available.\n-Buck",
		"a": "They're only intended for intrepid programmers who read the sourcecode."
	},
	{
		"id": 314,
		"type": "ignore",
		"date": "2010-07-18 16:06:16",
		"src": "https://bitcointalk.org/index.php?topic=55.msg4008#msg4008",
		"q": "I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).",
		"a": "That's what I thought too."
	},
	{
		"id": 315,
		"type": "ignore",
		"date": "2010-07-18 16:06:16",
		"src": "https://bitcointalk.org/index.php?topic=55.msg4008#msg4008",
		"q": "Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.",
		"a": "Now I'm hearing a report that it IS possible for javascript to do a cross-domain POST request to 127.0.0.1. Not other domains, but just specifically to that one. Great...\nIf this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.\nI'll get started on adding the password field."
	},
	{
		"id": 316,
		"type": "ignore",
		"date": "2010-07-18 18:58:21",
		"src": "https://bitcointalk.org/index.php?topic=437.msg4037#msg4037",
		"q": "Anyone know where the changelist is, I'm curious to what was fixed/changed/etc.",
		"a": "The change list is basically encompassed by what's listed in the first message. Everyone should upgrade to get the important security improvements.\nMinimizing to tray had at least 3 different glitches and bugs on Linux, including a crash one, so I disabled it again. You can still re-enable the option with \"-minimizetotray\" if you want to use it anyway. The bugs/glitches are somewhere in wxWidgets or GTK or Gnome and I don't know how to fix them. Sorry, I just don't know what else to do, it's just too glitchy and buggy to have as a mainline feature."
	},
	{
		"id": 317,
		"type": "ignore",
		"date": "2010-07-18 21:24:09",
		"src": "https://bitcointalk.org/index.php?topic=453.msg4068#msg4068",
		"q": "I've managed to set up dependencies and build bitcoin with MS Visual C++ 2008 Express Edition. I'll give 2010 a try at some time.\nThere is a custom allocator class in serialize.h, secure_allocator, that fails to build with non-debug runtime selected. It is my understanding allocator classes require a template copy constructor, I've attached a small patch that solves the problem.\nAs Satoshi noted elsewhere, the MSVC build is indeed significantly slower khash/s-wise (more than twice) than the prebuilt one (MinGW?), even though I enabled the highest optimization level options and also global optimization with link-time code generation. I find that result strange, since MSVC is not known to have significantly worse optimizer than GCC's. Most probably the problem can be traced to the sha module that is extracted from Crypto++. I find in Crypto++ SVN there are revised versions of the module, including x86/x64 assembly for SHA-256. Using the newer versions would involve reintegrating their dependencies, though. On that note, why aren't we using OpenSSL's SHA-2 hashing functions instead? Since we already use OpenSSL, this would be a better solution than to manually support a SHA module from another library.",
		"a": "OpenSSL doesn't have any interface for doing just the low level raw block hash part of SHA256. SHA256 begins by wrapping your data in a specially formatted buffer. Setting up the buffer takes an order of magnitude longer than the actual hashing if you're only hashing one or two blocks like we do. It's intended that the time is amortised if you were hashing many KB or MB of data. In BitcoinMiner, we format the buffer once and keep reusing it.\nIf you can find SHA256 code that's faster (with MinGW/GCC) than what we've got, that would be really great! (although, keep licensing in mind) The one we have is the only one I tried, so there's significant chance for improvement.\nWhen I wrote it more than 2 years ago, there were screaming hot SHA1 implementations but minimal attention to SHA256. That's a lot of time for them to come up with better stuff. SHA256 was a lot slower than the fastest SHA1 at the time than I thought it should be. Obviously SHA256 should be slower than SHA1 by a certain amount, but not by as much as I saw.\n(hope you don't mind I renamed your thread, SHA-256 optimisation is something important that I keep forgetting about)"
	},
	{
		"id": 318,
		"date": "2010-07-18 21:56:18",
		"src": "https://bitcointalk.org/index.php?topic=431.msg4073#msg4073",
		"q": "What amount does one have to send to incur a transaction fee though? I've send some large amounts around myself and never saw a fee?",
		"a": "Typically, over 25,000 BTC."
	},
	{
		"id": 319,
		"date": "2010-07-18 23:35:27",
		"src": "https://bitcointalk.org/index.php?topic=441.msg4095#msg4095",
		"q": "MacRohard: Cool graph. It would be nice if it should time on the x axis and number of blocks on the y",
		"a": "Nice graph! A moving average to smooth it out would be nice.\nhttp://nullvoid.org/bitcoin/statistix.php says 212 blocks in the last 24 hours, or 8.8 per hour."
	},
	{
		"id": 320,
		"type": "ignore",
		"date": "2010-07-19 04:43:13",
		"src": "https://bitcointalk.org/index.php?topic=461.msg4169#msg4169",
		"q": "I'm afraid I have to agree with laszlo here, using a certificate/keyfile would be far more secure. Saying that, thanks for adding some security to the JSON api",
		"a": "Right, that is quite a bit better.\nCan you give me any examples of other stuff that does it that way? (and what the command line looks like)\nThe main change you're talking about here is instead of -rpcpw= when you start bitcoind, you'd use a switch that specifies a text file to go and read it from, right? (any ideas what I should name the switch?)"
	},
	{
		"id": 321,
		"date": "2010-07-19 16:20:50",
		"src": "https://bitcointalk.org/index.php?topic=461.msg4268#msg4268",
		"q": "After further research... I think the Transmission approach, combined with the existing \"only allow connections from 127.0.0.1\" is a good short/medium-term solution.\nPutting the username:password in a settings.json file in the Bitcoin directory aught to work nicely (since Bitcoin can already parse JSON). And keeping the authentication stuff off the command line and in the HTTP headers instead of the JSON request params is nice and clean.\nLong term, the \"right\" way to do authenticated, secure JSON-RPC is with client-side certificates and https. But that looks like it would be a lot of work to implement and a big learning curve for users to figure out how to generate client-side certificates and how to get both sides of the JSON-RPC connection using them. And I'm not even certain a full-blown client certificate solution would solve the problem of malicious Javascript making JSON-RPC requests via XMLHttpRequests to localhost; if the user installed the client certificate in the browser (because maybe there was a nifty JSON-RPC-powered web front-end to controlling Bitcoin), would the browser automatically send the client certificate if a malicious website made requests?",
		"a": "So you drop a settings file in the ~/.bitcoin directory, that sounds better. In the \"no password is set\" warning, it could tell you where the file is and what to do.\nWhat is the most popular and common settings file format?\nHTTP basic authentication should be considered. In actual practice though, it's more work for web developers to figure out how to specify the password through some extra parameter in the HTTP or JSON-RPC wrapper than to just stick an extra parameter at the beginning of the parameter list. What do you think? Does HTTP basic authentication get us any additional benefits? Moving it off the parameter list but then you still have to specific it in a more esoteric place I'm not sure is a net win."
	},
	{
		"id": 322,
		"date": "2010-07-19 16:20:50",
		"src": "https://bitcointalk.org/index.php?topic=461.msg4268#msg4268",
		"q": "I was confused for a bit because the password is given LAST on the command line, but FIRST in the JSON-RPC params list. I agree that reading the command-line password from a file would be more convenient and more secure.",
		"a": "You're also confusing me, what do you mean? Did I do something unintended?"
	},
	{
		"id": 323,
		"date": "2010-07-20 18:38:28",
		"src": "https://bitcointalk.org/index.php?topic=342.msg4508#msg4508",
		"q": "Would Wikipedia have ignored the airplane until it was independently verified an explained by \"professionals\" who weren't smart enough to invent it in the first place?",
		"a": "Bitcoin is an implementation of Wei Dai's b-money proposal http://weidai.com/bmoney.txt on Cypherpunks http://en.wikipedia.org/wiki/Cypherpunks in 1998 and Nick Szabo's Bitgold proposal http://unenumerated.blogspot.com/2005/12/bit-gold.html\nThe timing is strange, just as we are getting a rapid increase in 3rd party coverage after getting slashdotted. I hope there's not a big hurry to wrap the discussion and decide. How long does Wikipedia typically leave a question like that open for comment?\nIt would help to condense the article and make it less promotional sounding as soon as possible. Just letting people know what it is, where it fits into the electronic money space, not trying to convince them that it's good. They probably want something that just generally identifies what it is, not tries to explain all about how it works.\nIf you post in http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Bitcoin please don't say \"yeah, but bitcoin is really important and special so the rules shouldn't apply\" or argue that the rule is dumb or unfair. That only makes it worse. Try to address how the rule is satisfied.\nSearch \"bitcoin\" on google and see if you can find more big references in addition to the infoworld and slashdot ones. There may be very recent stuff being written by reporters who heard about it from the slashdot article.\nI hope it doesn't get deleted. If it does, it'll be hard to overcome the presumption. Institutional momentum is to stick with the last decision. (or at least I assume so, that's how the world usually works, but maybe Wiki is different)"
	},
	{
		"id": 324,
		"type": "ignore",
		"date": "2010-07-21 00:05:20",
		"src": "https://bitcointalk.org/index.php?topic=461.msg4577#msg4577",
		"q": "If you're using another JSON-RPC client that you wrote you can take care to protect the password, but using the bitcoin binary as the client and passing the password on the command line has the same issue as starting the daemon with it. It's still visible to every user that way.\nSo both the server and the client mode invocation need to use the file and not accept the password on the command line. Generally programs like this refuse to start if the mode on the file isn't 600 or something like that, because that means other users can read it.",
		"a": "Still need to know what's the most typical settings file format on Linux. Is there a standard file extension? I've never seen a settings file using JSON, and it doesn't look very human friendly with everything required to be in quotes. I think what I usually see is like:\n# comment\nsetting=value\nIs there a settings file thing in Boost?\nWhen you're using bitcoind to issue commands from the command line as a client, can we have it get the password from the settings file then too?\nGavin pointed out I forgot to increment the column of numbers in CommandLineRPC, so the current -rpcpw= implementation doesn't work right from the command line with non-string parameters. (JSON-RPC is fine) Still under construction."
	},
	{
		"id": 325,
		"type": "ignore",
		"date": "2010-07-21 05:51:34",
		"src": "https://bitcointalk.org/index.php?topic=461.msg4646#msg4646",
		"q": "You could do worse than using yaml for the settings",
		"a": "I was researching config file formats, here's a comparison.\nYAML is massive. I'm not sure there's a lightweight easy to build library we can integrate into our project. Seems overkill.\nJSON is tempting and I'm inclined to like it, but two main sticking points:\n1) No comments! How can you have a config file where you can't comment out a line to disable it?\n2) Not very user friendly to have to \"quote\" all the strings, including the keys, and also have to remember the comma at the end of lines.\n{\n\"key\" : \"value\",\n}\nI suppose we could easily preprocess JSON reading the config file one line at a time, truncate the lines at any # character (and/or \"//\"?), concatenate them into a string and pass it to JSON, so you could go:\n# comment\n\"key\" : \"value\", # still have to remember the comma\n\"key2\" : \"value\", // comment like this or both\nBoost has boost::program_options.\nWe could read lines ourselves and feed them into a map<string, string> mapConfig.\nwhile (!eof)\nread line\nif '#' found, truncate line\nsplit line at first ':' -> key, value\nmapConfig.insert(key, value)\nIf we use the syntax:\n# comment\nkey : value\n...and don't allow whitespace indenting before the keys, I guess we would be a subset of YAML and could switch to YAML someday if we need more complexity.\nIf we go with self parsed, that doesn't mean we can't use JSON on particular parameter values as needed. If an option needs a list or more structured data, it could always parse its value as json:\nkey : [\"item1\", \"item2\", \"item3\"]\nAlthough it has to be all on one line then.\nI guess I'm leaning towards self parsed mapConfig:\n# comment\nkey : value"
	},
	{
		"id": 326,
		"type": "ignore",
		"date": "2010-07-21 16:07:57",
		"src": "https://bitcointalk.org/index.php?topic=461.msg4758#msg4758",
		"q": "I just did a quick survey of 20 .conf files in /etc on my debian system, and found:\n1 file used \"key value\"\n5 used \"key=value\"",
		"a": "Thanks for that survey!\nI find \"key value\" a little unnatural. There ought to be a more definite separator between key and value that suggests assignment. The space people may just be getting lazy using their language's split function.\nkey=some full sentence with spaces in it. # seems more clear\nkey some full sentence with spaces in it. # than this\nAllright then, lets go with self-parsed mapConfig, syntax:\n# comment\nkey=value\nfile extension .conf. What's the filename, is it ~/.bitcoin/settings.conf or ~/.bitcoin/bitcoin.conf or what?\nI think we better strip whitespace at the beginning and end of the key and the value.\n# user who likes column formatted\nk = value\nkey = value\nlongerkey = this sentence would be this # \"this sentence would be this\"\nkey = value # guess this is ok too\nnextkey = value\nright = justified\nThe normal syntax should be \"key=value\", but you can't blame people for the occasional \"key = value\"."
	},
	{
		"id": 327,
		"type": "ignore",
		"date": "2010-07-22 02:34:23",
		"src": "https://bitcointalk.org/index.php?topic=461.msg4928#msg4928",
		"q": "TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.",
		"a": "In many of the contexts of this RPC stuff, you can print to the console with fprintf(stdout, like this:\n#if defined(__WXMSW__) && wxUSE_GUI\nMyMessageBox(\"Warning: rpc password is blank, use -rpcpw=<password>\n\", \"Bitcoin\", wxOK | wxICON_EXCLAMATION);\n#else\nfprintf(stdout, \"Warning: rpc password is blank, use -rpcpw=<password>\n\");\n#endif"
	},
	{
		"id": 328,
		"date": "2010-07-23 17:07:40",
		"src": "https://bitcointalk.org/index.php?topic=461.msg5337#msg5337",
		"q": "Question for everybody: should I add a section to the wiki page describing, in detail, how to do HTTP Basic authentication? PHP and Python make is really easy-- just use the http://user:pass@host:port/ URL syntax.",
		"a": "Yes, I think that would be really good so each dev doesn't have to figure it out themselves. We need a simple example for each of Python, PHP and Java importing the json-rpc library and using it to do a getinfo or something, including doing the http authentication part."
	},
	{
		"id": 329,
		"date": "2010-07-23 17:23:47",
		"src": "https://bitcointalk.org/index.php?topic=548.msg5339#msg5339",
		"q": "I also get it anytime I send an invalid bitcoin address. Which is weird since it doesn't seem like that would effect the connecting.",
		"a": "If I recall correctly, 500 is the prescribed status code for JSON-RPC error responses. There is still a JSON response in the body of the reply telling the explanation of the error, which could be something like {\"result\":\"\",\"error\":\"bitcoin address not found\",\"id\":\"1\"}."
	},
	{
		"id": 330,
		"date": "2010-07-23 20:13:27",
		"src": "https://bitcointalk.org/index.php?topic=550.msg5378#msg5378",
		"q": "Is there a safety reason to stop within the last 2000 blocks or can it be tweaked to stop at remaining 500 blocks for example?",
		"a": "Not really. I'll change it to 1000 next time."
	},
	{
		"id": 331,
		"type": "ignore",
		"date": "2010-07-23 20:39:03",
		"src": "https://bitcointalk.org/index.php?topic=461.msg5383#msg5383",
		"q": "I strongly disagree; software should be secure by default, and running bitcoind without a password (or bitcoin -server) is definitely NOT secure.\nI just don't see somebody saying \"Man, Bitcoin sucks because I have to add a password to a configuration file before running it as a daemon.\" I can see somebody saying \"Man, Bitcoin sucks because I accidently ran it with the -server switch and somebody stole all my money.\"",
		"a": "I don't think authentication should be disabled by default if there's no conf file or the config file doesn't contain \"rpcpassword\", but what if it contains \"rpcpassword=\"?\nI can see both points.\nWhat if the programmer can't figure out how to do HTTP authentication in their language (Fortran or whatever) or it's not even supported by their JSON-RPC library? Should they be able to explicitly disable the password requirement?\nOTOH, what if there's a template conf file, with\nrpcpassword= # fill in a password here\nThere are many systems that don't allow you to log in without a password. This forum, for instance. Gavin's point seems stronger.\nBTW, I haven't tested it, but I hope having rpcpassword= in the conf file is valid. It's only if you use -server or -daemon or bitcoind that it should fail with a warning. If it doesn't need the password, it should be fine. Is that right?"
	},
	{
		"id": 332,
		"type": "ignore",
		"date": "2010-07-24 00:59:08",
		"src": "https://bitcointalk.org/index.php?topic=528.msg5416#msg5416",
		"q": "Alright, I know it hasn't been more than an hour since I last posted about this, but I decided to solve this problem myself.\nIf there's a better solution out there, I'd be glad to hear it, but here's my version 0.1 attempt to make this work:\nhttp://www.alloscomp.com/bitcoin/btcjsonrpc.pys\nLet me know if you like it, hate it, or see any obvious flaws with it. There's some getting started docs in the source, but here's the code of the test suite:\nfrom btcjsonrpc import Service\ns = Service()\nprint 'preparing getbalance; id:',s.getbalance() # Each call returns its ID so you can find it later in the results\nprint 'preparing getdifficulty; id:',s.getdifficulty()\nprint 'preparing listreceivedbyaddress; id:',s.listreceivedbyaddress(10000) # Call with a parameter\nprint 'preparing getbalance; id:',s.getbalance(id='getbalance 2') # You can also specify your own ID\nprint '\nexecuting call\nresults:'\nresults = s() # Get the results by calling the Service object\nfor id,value in results.iteritems():\nprint id,value\n# If you'd prefer to work directly with the JSON responses instead of a dict of IDs, then access the list Service.responses.\nprint '\njson responses'\nprint s.responses\nAnd here's the output, including the docstr:\n$ ./btcjsonrpc.py\nSocket-based, Bitcoin-compatible JSON-RPC v1.0 client.\nBy: Eric Swanson (http://www.alloscomp.com/bitcoin)\nVersion 0.1, July 21, 2010\nDon't use this for one-off request->response pairs. Use something like the reference python-jsonrpc library, or urllib2 + json. This client is hackish, but it works for me (and has sped up my JSON-RPC accesses tremendously).\nFor details of WHY exactly I felt the need to redo python-jsonrpc using a raw socket, check out the follow forum post: http://bitcointalk.org/index.php?topic=528.0\nUsage is fairly straightforward, and a code sample can be found below the library code (in the if __name__=='__main__' clause).\npreparing getbalance; id: jss-1\npreparing getdifficulty; id: jss-2\npreparing listreceivedbyaddress; id: jss-3\npreparing getbalance; id: getbalance 2\nexecuting call\njss-2 181.543289364\njss-3 []\ngetbalance 2 2345.94\njss-1 2345.94\njson responses\n[{u'id': u'jss-2', u'result': 181.54328936405051, u'error': None}, {u'id': u'jss-3', u'result': [], u'error': None}, {u'id': u'getbalance 2', u'result': 2345.9400000000001, u'error': None}, {u'id': u'jss-1', u'result': 2345.9400000000001, u'error': None}]",
		"a": "Obviously it's a bug that it repeats the header.\nI was trying to follow the 1.0 spec: http://json-rpc.org/wiki/specification It called for multiple invocation.\nI think they mean it's like this, but I'm not sure:\n{\"method\": \"postMessage\", \"params\": [\"Hello all!\"], \"id\": 99}\n{\"method\": \"postMessage\", \"params\": [\"I have a question:\"], \"id\": 101}\n{\"result\": 1, \"error\": null, \"id\": 99}\n{\"result\": 1, \"error\": null, \"id\": 101}\nI can't remember where I think I saw that it's supposed to send back HTTP status 500 for an error reply. If it contains multiple responses and one is an error, I wonder if that makes the status 500 for the whole thing, I guess so. Maybe it should always return 200. I think someone sounded like the 500 might be causing a problem.\nThis probably gets fixed after 0.3.3. Until then, just use single invocation. I wonder if any JSON-RPC package even supports multiple invocation, probably not.\nIt would be nice if we could pin down better how multiple-invocation is supposed to work, if at all, before trying to fix it, and whether returning HTTP status 500 for error response is right."
	},
	{
		"id": 333,
		"date": "2010-07-24 01:15:58",
		"src": "https://bitcointalk.org/index.php?topic=548.msg5419#msg5419",
		"q": "Weird I guess fopen() in php dies if the response is 500?\nIt seems like errors such as invalid address should just be normal replies just not \"sent\" so we can just check the reply string. I think of 500 errors as the server itself having an error.",
		"a": "Can anyone confirm if JSON-RPC over HTTP is supposed to use status 500 if the reply is an error reply? I can't remember where I picked that up, maybe it's wrong. It seems like 200 would make more sense unless there's something wrong with the mechanics of the HTTP request itself. (and maybe that's what it said and I forgot and spread 500 to all error responses)"
	},
	{
		"id": 334,
		"type": "ignore",
		"date": "2010-07-24 02:29:09",
		"src": "https://bitcointalk.org/index.php?topic=479.msg5432#msg5432",
		"q": "chroot: won't protect you.\nRunning as a separate VM: I think will protect you. But I thought browsers wouldn't allow XMLHTTPRequests to \"localhost\" from web pages fetched from the web, so my advice would be to test it. See if you can talk to the Bitcoin daemon from another VM on the same machine by running \"bitcoind getinfo\" or \"bitcoin getinfo\" on the non-bitcoin-vm.",
		"a": "The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem."
	},
	{
		"id": 335,
		"date": "2010-07-24 04:04:20",
		"src": "https://bitcointalk.org/index.php?topic=555.msg5450#msg5450",
		"q": "Thanks for clearing that up for me.\nI keep making really elementary code mistakes....",
		"a": "FLATDATA was a workaround to serialize a fixed field length array. There was a cleaner way to make it understand how to serialize arrays directly, but MSVC6 couldn't do it and I wanted to keep compatibility with MSVC6 at that time. We don't support MSVC6 anymore because we use something in Boost that doesn't. We lost support for it after 0.2.0. Maybe someday I'll swap in the clean way that just knows how to serialize fixed length arrays without wrapping them in FLATDATA."
	},
	{
		"id": 336,
		"date": "2010-07-25 14:46:33",
		"src": "https://bitcointalk.org/index.php?topic=567.msg5694#msg5694",
		"q": "There was a lot of slowdown in the rate of transactions during the second half of the test. If this was a problem with the network, then I would be very worried about future denial of service attacks. Hopefully a bigger test can be organized later.\nHere is a packet capture of the event (from an \"edge\" computer with only one connection) if anyone is interested in exact times and stuff.\nhttp://www.freefilehostingnow.com/filedownload.aspx?code=6bb2dbeea18e6a419daaadda5798bb05ec6b",
		"a": "Was that on the test network?\nhttp://bitcointalk.org/index.php?topic=363.0"
	},
	{
		"id": 337,
		"type": "ignore",
		"date": "2010-07-25 15:29:52",
		"src": "https://bitcointalk.org/index.php?topic=567.msg5698#msg5698",
		"q": "No.",
		"a": "Please do these tests on the test network. That's what it's for. Thanks."
	},
	{
		"id": 338,
		"date": "2010-07-25 17:45:22",
		"src": "https://bitcointalk.org/index.php?topic=571.msg5712#msg5712",
		"q": "I think there is a pretty significant crypto flaw in Bitcoin as currently implemented. I'm not sure it is exploitable now (I'm not a real cryptohacker) but it is more than plausible that will be in the near future.\nThe flaw would enable anonymous stealing of coins from arbitrary bitcoin addresses. And no it doesn't involve solving any of the hard problems that keep existing crypto systems secure. It is simply a *potential* correctable logic flaw in the implementation.\nI would like bitcoins to succeed, so I'd rather not jump up and down in public yelling about flaws in public. Is there an appropriate place to discuss these types of issues?",
		"a": "It's best if you tell it to me privately so it can be fixed first.\nI just e-mailed you my e-mail address. (or you could PM me here)"
	},
	{
		"id": 339,
		"date": "2010-07-25 19:06:23",
		"src": "https://bitcointalk.org/index.php?topic=571.msg5724#msg5724",
		"q": "You stopped my post just in time! :-)",
		"a": "Red, thanks for telling me privately first! Please go ahead and post it (and relieve the suspense for everyone!)\nHis point is that transactions paid to a Bitcoin Address are only as secure as the hash function. To make Bitcoin Addresses short, they are a hash of the public key, not the public key itself. An attacker would only have to break the hash function, not ECDSA."
	},
	{
		"id": 340,
		"type": "favorite",
		"date": "2010-07-25 20:01:40",
		"src": "https://bitcointalk.org/index.php?topic=571.msg5740#msg5740",
		"q": "If I figure out that Public Key 123456 generates Hash ABCD\nand\nPublic Key 654321 also generates Hash ABCD\nI'm still left without the Private Key.\nBut from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456.",
		"a": "You would still have to sign it with public key 654321. You need to find a collision using a public key for which you know the private key.\nWhen you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.\nRed's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision.\nHe points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone. Someone trying to brute force would have to take time generating a key for each attempt."
	},
	{
		"id": 341,
		"type": "favorite",
		"date": "2010-07-25 20:48:01",
		"src": "https://bitcointalk.org/index.php?topic=571.msg5754#msg5754",
		"q": "Here is a paper that claims to find SHA-1 collisions in 2^52 crypto operations. And optimally secure hash would take 2^80 operations. 2^52 time is still large, but it is getting into cluster and botnet range.",
		"a": "2^80 is if you can use a birthday attack. You can't use a birthday attack for this, so the difficulty is the full 2^160 bits. Although, if you were trying to crack any one of 1 million (2^20) transactions, you could do a partial birthday attack 2^160/2^20 = 2^140.\nBitcoin Addresses are the only place where 160-bit hash is used. Everything else is SHA-256. They're calculated as:\nbitcoinaddress = RIPEMD-160(SHA-256(publickey))\nCorrect me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case. An analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision. Here, you don't have that kind of control over RIPEMD-160's input, because the input is the output of SHA-256. If an analytical attack helps you find an input to RIPEMD-160 that produces a collision, what are you going to do with it? You still have to get SHA-256 to output that value, so you would still have to break SHA-256 too.\nFor brute force, RIPEMD-160(SHA-256(x)) is no stronger than RIPEMD-160 alone. But for analytical attack, it seems like you must analytical attack both RIPEMD-160 and SHA-256. If I'm wrong, then the strength is the same as RIPEMD-160 and the SHA-256 only serves as one round of key strengthening."
	},
	{
		"id": 342,
		"type": "ignore",
		"date": "2010-07-25 21:34:29",
		"src": "https://bitcointalk.org/index.php?topic=461.msg5767#msg5767",
		"q": "I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind produces authorization headers that look like this:\n...\nAuthorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93\nb3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk\nIt inserts a newline every 64 characters, which obviously breaks the Authorization header, so commands like \"bitcoin getinfo\" fail. The server still works fine with properly behaving clients.\nThis can be solved by removing the newlines (and maybe '\n's) from result at the end of the Base64Encode function:\nresult.erase(std::remove(result.begin(), result.end(), '\n'), result.end());\nresult.erase(std::remove(result.begin(), result.end(), '\n'), result.end());",
		"a": "+1 to you for having such a long password that you found this bug.\nUploaded to SVN as rev 110."
	},
	{
		"id": 343,
		"date": "2010-07-25 21:44:16",
		"src": "https://bitcointalk.org/index.php?topic=461.msg5769#msg5769",
		"q": "i got some problems here too trying to get this run on PHP.\nso far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen(http://username:password@localhost:8332/)), nor my curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to work.",
		"a": "That's strange, didn't someone just say that was supposed to work? (what library was he using?) Post if you figure out what wrong.\nI hope it's not going to put up this much of a fight for all PHP users.\nLooks like we've got the Fortran scenario already."
	},
	{
		"id": 344,
		"type": "ignore",
		"date": "2010-07-25 21:51:31",
		"src": "https://bitcointalk.org/index.php?topic=461.msg5771#msg5771",
		"q": "Great catch! Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function",
		"a": "SVN rev 111"
	},
	{
		"id": 345,
		"date": "2010-07-25 22:06:57",
		"src": "https://bitcointalk.org/index.php?topic=458.msg5772#msg5772",
		"q": "Hashes are good but it's already time to start doing gpg-signatures to tarball. Suffice it now to hack the site or even deception to obtain control over the wiki, put \"fresh\" version of the client and everything collapses.",
		"a": "For future reference, here's my public key. It's the same one that's been there since the bitcoin.org site first went up in 2008. Grab it now in case you need it later.\nhttp://www.bitcoin.org/Satoshi_Nakamoto.asc"
	},
	{
		"id": 346,
		"date": "2010-07-25 22:27:36",
		"src": "https://bitcointalk.org/index.php?topic=571.msg5778#msg5778",
		"q": "So the way I read it.\nGiven two numbers p and q. Which for RSA are supposed to be large primes.\nThen n = p*q\nThe public key is the two fields (n, e). e is called the public exponent and appears to be chosen from a set of common values.\nThe private key is also two fields (n, d). d is called the private exponent it it is derived by knowing e, p-1, and q-1.\nThe trick is, it is really hard to factor n into p & q. Therefore it is equally as hard to find p-1 and q-1\nMy postulation is that if n is arbitrary, and e is one of the common values, then there are lots of different p, q pairs that would work. The less prime the numbers the easier to find p and q, and therefore p-1 and q-1. And if you have a big block of arbitrary data that give you lots of flexibility in trying to collide a hash.\n(That is the point where I could be totally off base though. Really interested, if a crypto geek knows better than me.)\nI did read that the key generation algorithms create p and q such that they are \"very likely prime\" but it is too much work to know for sure. This leads me to believe non-primes don't cause any obvious FAILs. I could be wrong though.",
		"a": "Sorry, actually it's ECDSA (Elliptic Curve Digital Signature Algorithm) not RSA. I shouldn't have said \"prime numbers\". ECDSA doesn't take much time to generate a keypair."
	},
	{
		"id": 347,
		"type": "ignore",
		"date": "2010-07-26 18:41:31",
		"src": "https://bitcointalk.org/index.php?topic=501.msg5920#msg5920",
		"q": "Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.\nPerformance: 4700khash/s on 4 cores, I think that speaks for itself.\nI've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.",
		"a": "Is that still starting from Crypto++? Lets get this into the main sourcecode."
	},
	{
		"id": 348,
		"type": "ignore",
		"date": "2010-07-27 01:29:42",
		"src": "https://bitcointalk.org/index.php?topic=572.msg5978#msg5978",
		"q": "Crypto++ 5.6.0: http://www.cryptopp.com/\nCached SHA256: http://pastebin.com/rJAYZJ32 (although I'm pretty sure this is publically submitted elsewhere, I was linked to it on IRC)",
		"a": "I added the cached SHA256 state idea to the SVN, rev 113. The speedup is about 70%. I credited it to tcatm based on your post in the x64 thread.\nI can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon as it runs it crashes. It says its for MASM (Microsoft's assembler) and the sample command line they give looks like Visual C++. Does it only work with the MSVC and Intel compilers?"
	},
	{
		"id": 349,
		"date": "2010-07-27 03:04:58",
		"src": "https://bitcointalk.org/index.php?topic=43.msg5990#msg5990",
		"q": "Try the Bitcoin Economics Forum\nYou should be able to find many discussions about this topic there.\nThis thread is about the proof of work difficulty number.",
		"a": "New difficulty factor 244.213223092\n+35%\nI updated the first post.\ndate, difficulty factor, % change\n2009 1.00\n30/12/2009 1.18 +18%\n11/01/2010 1.31 +11%\n25/01/2010 1.34 +2%\n04/02/2010 1.82 +36%\n14/02/2010 2.53 +39%\n24/02/2010 3.78 +49%\n08/03/2010 4.53 +20%\n21/03/2010 4.57 +9%\n01/04/2010 6.09 +33%\n12/04/2010 7.82 +28%\n21/04/2010 11.46 +47%\n04/05/2010 12.85 +12%\n19/05/2010 11.85 -8%\n29/05/2010 16.62 +40%\n11/06/2010 17.38 +5%\n24/06/2010 19.41 +12%\n06/07/2010 23.50 +21%\n13/07/2010 45.38 +93%\n16/07/2010 181.54 +300%\n27/07/2010 244.21 +35%"
	},
	{
		"id": 350,
		"type": "ignore",
		"date": "2010-07-27 18:27:30",
		"src": "https://bitcointalk.org/index.php?topic=572.msg6069#msg6069",
		"q": "I was able to integrate the SHA256 functionality from Crypto++ 5.6.0 into Bitcoin. This is the fastest SHA256 yet using the SSE2 assembly code. Since Bitcoin was sending unaligned data to the block hash function, I had to change the MOVDQA instruction to MOVDQU.\nI think using the SHA256 functionality from Crypto++ 5.6.0 is the way forward right now.",
		"a": "I added a subset of the Crypto++ 5.6.0 library to the SVN. I stripped it down to just SHA and 11 general dependency files. There shouldn't be any other crypto in there other than SHA.\nI aligned the data fields and it worked. The ASM SHA-256 is about 48% faster. The combined speedup is about 2.5x faster than version 0.3.3.\nI guess it's using SSE2. It automatically sets its build configuration at compile time based on the compiler environment.\nIt looks like it has some SSE2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available. I want the release builds to have SSE2. SSE2 has been around since the first Pentium 4. A Pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway.\nThis is SVN rev 114."
	},
	{
		"id": 351,
		"type": "ignore",
		"date": "2010-07-27 19:47:42",
		"src": "https://bitcointalk.org/index.php?topic=572.msg6083#msg6083",
		"q": "I've got some older machines (for the windows client and linux clients) to test with that don't support SSE2. Mainly if you try to run them, the program just crashes when I tried some of the experimental builds here, but I'll be glad to test some future official builds to see if the \"detect SSE2\" part works or the program goes belly up.",
		"a": "OK, thanks. I'd also like to know if it runs fine as long as you don't turn on Generate. You'd think as long as it doesn't actually execute any SSE2 instructions, it would still load. At least Pentium 3's could run it without generating."
	},
	{
		"id": 352,
		"type": "ignore",
		"date": "2010-07-28 20:58:26",
		"src": "https://bitcointalk.org/index.php?topic=601.msg6268#msg6268",
		"q": "Does it work if you specify the full path? e.g. -datadir=/home/psyvenrix/datadir2 ?",
		"a": "It was able to reproduce this. The database doesn't like the relative path.\n\"bitcoind -datadir=./subdir getinfo\" works against a running daemon, but trying to start the daemon as \"bitcoind -datadir=./subdir\" gets that exception.\nI guess we should resolve the full path before passing it to the database.\nIt looks like you were the first one to ever use -datadir with a relative path."
	},
	{
		"id": 353,
		"type": "ignore",
		"date": "2010-07-28 21:23:23",
		"src": "https://bitcointalk.org/index.php?topic=604.msg6273#msg6273",
		"q": "I get:\n/var/folders/n7/n7Do3Krz2RWPeE+1YxvhUU+++TM/-Tmp-//cc8PgHsQ.s:879:suffix or operands invalid for `call'\n... compiling cryptopp/sha.cpp (latest SVN source) on my Mac (gcc version 4.2.1).\nI 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.",
		"a": "Was that the only thing I broke in the OSX build?! Does it actually work after just that one change?\nI had to do that for makefile.vc also. It compiled, but SHA-256 didn't work correctly; it returned the same incorrect hash each time.\nWe'll disable it now, and if anyone figures out how to fix it, we can re-enable it then. It's still 1.7x faster from the midstate optimisation.\nThe Crypto++ ASM SHA-256 works with GCC on Linux and Windows (MinGW).\nI uploaded this makefile.osx change to SVN. (let me know if that compiles now)"
	},
	{
		"id": 354,
		"type": "ignore",
		"date": "2010-07-29 01:16:23",
		"src": "https://bitcointalk.org/index.php?topic=587.msg6301#msg6301",
		"q": "It appears that block 70718 was found two hours in the future and followed with block 70719 being found about two hours in the past (from the future date of previous block).\n-7017 seconds to find block 70719\n8153 seconds to find block 70718\n49 seconds to find block 70717\n524 seconds to find block 70716\nblock timestamp\n70715 1280275621\n70716 1280276145\n70717 1280276194\n70718 1280284347\n70719 1280277330\nThis doesn't seem to have any effect on things so much other than providing a kind of inaccurate depiction of statistical results every now and then (when a block is claimed to be from the future or the past), however what would happen if either the first or second (whichever one triggers new difficulty being established) of a new set of 2016 blocks is generated to have a timestamp 2+ weeks in the past or the future? If in the past, I presume according to the code in main.cpp: GetNextWorkRequired function that the lowest accepted interval is 3.5 days. And if in the future I presume according to the code the lowest accepted interval is 56 days.",
		"a": "You were looking at the wrong code. Here's the code that applies:\nbool CBlock::CheckBlock() const\n{\n...\n// Check timestamp\nif (nTime > GetAdjustedTime() + 2 * 60 * 60)\nreturn error(\"CheckBlock() : block timestamp too far in the future\");\n...\nbool CBlock::AcceptBlock()\n{\n...\n// Check timestamp against prev\nif (nTime <= pindexPrev->GetMedianTimePast())\nreturn error(\"AcceptBlock() : block's timestamp is too early\");\nThe timestamp is limited to up to 2 hours in the future. It can be earlier than the previous block, but it must be greater than the median of the last 11 blocks. The reason for doing it that way is so the time can get corrected in the next block if the previous block had the time too far in the future, like what happened."
	},
	{
		"id": 355,
		"type": "favorite",
		"date": "2010-07-29 02:00:38",
		"src": "https://bitcointalk.org/index.php?topic=532.msg6306#msg6306",
		"q": "I am convinced that bandwidth, disk space, and computation time necessary to distribute and \"finalize\" a transaction will be prohibitively expensive for micro-payments. Consider for a second that the current banking industry is unable to provide a reasonable micropayment solution that does not involve depositing a reasonable sum and only allowing a withdraw after a reasonable sum has been accumulated.\nBesides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.\nThus we need bit-banks that allow instant transfers among members and peer banks. Anyone can open a bit-bank but the system would, by necessity operate on some level of trust. Transfers in and out of the banks and peer-to-peer would still be possible but will be more costly. Thus, a bit bank could make money by enabling transfers cheaper and faster than the swarm with the added risk of trusting the bank. A bank has to maintain trust to make money.",
		"a": "The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate."
	},
	{
		"id": 356,
		"type": "favorite",
		"date": "2010-07-29 02:00:38",
		"src": "https://bitcointalk.org/index.php?topic=532.msg6306#msg6306",
		"q": "Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.",
		"a": "See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry.\nhttp://bitcointalk.org/index.php?topic=423.msg3819#msg3819"
	},
	{
		"id": 357,
		"date": "2010-07-29 02:10:46",
		"src": "https://bitcointalk.org/index.php?topic=338.msg6307#msg6307",
		"q": "Looks like bitcoin.org is listed on the PBL.",
		"a": "WTF? How did we get on that? AFAIK, the only e-mail is if you tell the forum to do notifications, and I guess the wiki registration. I'd consider turning off the forum notification e-mails, I don't know why we have that."
	},
	{
		"id": 358,
		"type": "ignore",
		"date": "2010-07-29 19:55:51",
		"src": "https://bitcointalk.org/index.php?topic=626.msg6469#msg6469",
		"q": "Yes, I've tested on Windows XP, 2003, and 7 all went through just fine. You'll enjoy the speed increase as well.\n[err, wait I guess, new version about to spawn]",
		"a": "Haven't had time to update the SVN yet. Wait for 0.3.6, I'm building it now. You can shut down your node in the meantime."
	},
	{
		"id": 359,
		"type": "ignore",
		"date": "2010-07-29 21:20:38",
		"src": "https://bitcointalk.org/index.php?topic=626.msg6490#msg6490",
		"q": "Tested the Windows build across XP, 2003, Vista, 7 (both 32 and 64bit builds), no issues installing or running client. So far so good, looking forward to the Linux client.",
		"a": "0.3.6 Linux build is back to the old makefile.unix. It static links libjpeg so that shouldn't be a problem.\nIs that working better?\nIf you got 22DbRunRecoveryException and you've used someone else's build before, you may need to delete (or move the files somewhere else) database/log.000000*\nWindows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6."
	},
	{
		"id": 360,
		"type": "ignore",
		"date": "2010-07-29 21:43:15",
		"src": "https://bitcointalk.org/index.php?topic=626.msg6502#msg6502",
		"q": "sorry. I'm checked binaries on Debian GNU/Linux squeeze/sid",
		"a": "\"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)\" isn't a new problem that started with 0.3.6 is it? This was built on the same OS installations as 0.3.0.\nUnfortunately I upgraded to Ubuntu 10.04 before 0.3.0. I will not upgrade anymore. I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself."
	},
	{
		"id": 361,
		"date": "2010-07-29 22:04:15",
		"src": "https://bitcointalk.org/index.php?topic=628.msg6508#msg6508",
		"q": "BTW, an important feature of these mailing lists is that anyone can post... but only the \"vendor security\" group can read the posts.\nThus, it is easy for an outsider with a real security issue to provide detailed information to vendor-sec@myopensourceproject.org, while preventing unscrupulous people from reading the sensitive information.\nI suppose a PM to <somebody>, plus discussion on a closed forum, is the best this forum software can handle.",
		"a": "Actually, it works well to just PM me. I'm the one who's going to be fixing it. If you find a security flaw, I would definitely like to hear from you privately to fix it before it goes public."
	},
	{
		"id": 362,
		"date": "2010-07-29 22:08:31",
		"src": "https://bitcointalk.org/index.php?topic=615.msg6512#msg6512",
		"q": "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.",
		"a": "If the transaction didn't go out immediately at first, like if you weren't connected at the time, it may take up to 2 hours to resend it. Long term, it does keep relentlessly sending it.\nI'll shorten that length of time in a future version.\nYou do need to have downloaded the complete block chain (currently 71040 blocks) before you'll see any confirms. Same with the recipient."
	},
	{
		"id": 363,
		"type": "ignore",
		"date": "2010-07-29 22:17:24",
		"src": "https://bitcointalk.org/index.php?topic=612.msg6516#msg6516",
		"q": "Sorry to post to my own post.\nOne possible solution would be to create a project on the OpenSUSE OBS platform http://wiki.meego.com/Build_Infrastructure .\nThis platform is an auto-builder anyone can use (by creating your own account and home area).\nYou can upload your project and *.spec (build descriptor) and it will build your distribution in the format of all the leading Linux distributions (OpenSUSE, CentOS/RHEL, Fedora, Ubuntu, ...). So there is no need for you to maintain them seperately it will do that for you.\nThe result will be a *.deb or *.rpm or whatever your platform uses.",
		"a": "Yeah, acutely aware that I should have stayed on 9.04 or 9.10. It's a lot more work to downgrade than upgrade and I've been squeezed for time. Ubuntu is the most popular distro, so I'm staying with that."
	},
	{
		"id": 364,
		"type": "ignore",
		"date": "2010-07-29 23:12:12",
		"src": "https://bitcointalk.org/index.php?topic=626.msg6542#msg6542",
		"q": "On Debian testing 32-bit, I get a few build errors, all resembling:\nscript.cpp:114: error: OP_NOP1 was not declared in this scopeI got these when attempting to \"make bitcoind\" without \"make clean\" or \"make\" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present.\nIf anyone else gets this error, the simplest solution is to \"make clean\" and retry the build.",
		"a": "We don't really need pre-compiled header. It only makes it compile slightly faster. I think I'll just get rid of it. Even still, you'd still need to remember to \"make -f makefile.unix clean\" or delete headers.h.gch one more time to get rid of the leftover file.\nDamn that GLIBC_2.11. I thought I'd been careful not to accept any of the updates."
	},
	{
		"id": 365,
		"type": "ignore",
		"date": "2010-07-30 19:19:05",
		"src": "https://bitcointalk.org/index.php?topic=642.msg6701#msg6701",
		"q": "Howdy,\nI am running R119 on a Linux box, and last night was fortunate enough to solve a block and get 50 BTC. Hooray, right? Well, I tried to send 30 BTC before they were \"mature\" (i.e. before the 100+ block mark had passed), and so of course bitcoind reported an error. However, it also marked those 30 coins as spent, so not only was no transaction created, but the coins aren't usable by me at the moment.\nHere is the relevant bit from my debug.log:\nThreadRPCServer method=sendtoaddress\nCTransaction(hash=cf3bee, ver=1, vin.size=1, vout.size=2, nLockTime=0)\nCTxIn(COutPoint(e9894c, 0), scriptSig=0x014866DE7A1889014BAC9A)\nCTxOut(nValue=20.00000000, scriptPubKey=OP_DUP OP_HASH160 0x01BA)\nCTxOut(nValue=30.00000000, scriptPubKey=OP_DUP OP_HASH160 0x3F3A)\nAddToWallet cf3bee new\nCommitTransaction() : Error: Transaction not validreceived: addr (27 bytes)\n07/30/10 15:27:00 Flushing wallet.dat\nFlushed wallet.dat 1ms\nSo my wallet started with 50.01 BTC in it (the 0.01 was just a test I'd run the other day from one machine to another), and now my wallet just has 20.01 BTC in it. I'm a little sad---I was excited about generating those coins!\nErik",
		"a": "I don't get how it let you send if it was not matured. Your balance would have been lower than the amount. It would have said balance 0.01, right? If I try that it says \"you don't have enough money\" or \"Insufficient funds\" from the command line.\nHow many blocks did it say it had left to mature when you sent?\nThere's a chance it might still go through.\nHave you copied or moved your wallet.dat in any way?"
	},
	{
		"id": 366,
		"type": "ignore",
		"date": "2010-07-30 19:40:54",
		"src": "https://bitcointalk.org/index.php?topic=611.msg6706#msg6706",
		"q": "Here is 'listtransaction' version 7:\nhttp://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactions\nThis adds the suggested txn_id field -- very nice suggestion, gavin! I wanted a unique transaction id, and now I have one",
		"a": "What are you needing to use listtransactions for?\nThe reason I didn't implement listtransactions is I want to make sure web programmers don't use it. 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.\nWhen we do implement listtransactions, maybe one way to fight that is to make it all text. It should not break down the fields into e.g. comment, confirmations, credit, debit. It could be one pretty formatted string like \"0/unconfirmed 0:0:0 date comment debit 4 credit 0\" or something so it's hard for programmers to do the wrong thing and process it. It's only for viewing the status of your server. I guess that would be kinda annoying for web interfaces that would rather format it into html columns though."
	},
	{
		"id": 367,
		"type": "ignore",
		"date": "2010-07-30 19:53:06",
		"src": "https://bitcointalk.org/index.php?topic=626.msg6711#msg6711",
		"q": "I can only imagine the pain you went through to get these builds because I'm trying to build the program on a Ubuntu 9.04 box and so far I can't seem to find all the dependencies to compile no matter how much I keep installing packages and compiling source, LOL.",
		"a": "I can't understand why you're having so much pain. I just followed the instructions in build-unix.txt. I made a couple little corrections for Boost 1.37, which I'll put on SVN the next time I update it, noted below:\nDependencies\n------------\nsudo apt-get install build-essential\nsudo apt-get install libgtk2.0-dev\nsudo apt-get install libssl-dev\nsudo apt-get install libdb4.7-dev\nsudo apt-get install libdb4.7++-dev\nsudo apt-get install libboost-all-dev (or libboost1.37-dev)\nwxWidgets\n---------\ncd /usr/local\ntar -xzvf wxWidgets-2.9.0.tar.gz\ncd /usr/local/wxWidgets-2.9.0\nmkdir buildgtk\ncd buildgtk\n../configure --with-gtk --enable-debug --disable-shared --enable-monolithic\nmake\nsudo su\nmake install\nldconfig\nadded a comment in makefile.unix:\n# for boost 1.37, add -mt to the boost libraries\nLIBS= \\\n-Wl,-Bstatic \\\n-l boost_system \\\n-l boost_filesystem \\\n-l boost_program_options \\\n-l boost_thread \\\n-l db_cxx \\\n-l crypto \\\n-Wl,-Bdynamic \\\n-l gthread-2.0"
	},
	{
		"id": 368,
		"type": "ignore",
		"date": "2010-07-30 21:44:04",
		"src": "https://bitcointalk.org/index.php?topic=626.msg6728#msg6728",
		"q": "So that last command should simply be\nsudo apt-get install libboost1.37-dev",
		"a": "Except that wouldn't work for boost 1.40+ (on Ubuntu 10.04), where you need to get libboost-all-dev.\nSeems they changed everything around in Boost recently, \"-mt\" and all that, makes it hard.\nBTW, I tried Boost 1.34 but it didn't have the boost.interprocess stuff.\nMac OSX version is available now. See bitcoin.org or the SourceForge link."
	},
	{
		"id": 369,
		"date": "2010-07-31 00:29:20",
		"src": "https://bitcointalk.org/index.php?topic=648.msg6751#msg6751",
		"q": "Tell me if it works\nDonations are welcome. 17asVKkzRGTFvvGH9dMGQaHe78xzfvgSSA",
		"a": "That's amazing...\nSo are you saying you use 128-bit registers to SIMD four 32-bit data at once? I've wondered about that for a long time, but I didn't think it would be possible due to addition carrying into the neighbour's value."
	},
	{
		"id": 370,
		"type": "ignore",
		"date": "2010-07-31 14:38:52",
		"src": "https://bitcointalk.org/index.php?topic=612.msg6822#msg6822",
		"q": "Please cite exactly which library is using which feature of very recent glibc version (or any library for that matter) ? (just so we can all understand the problem in the way you state).\nFrom what I can see wxWidgets and boost are linked statically. I guess this is due to the \"build against very specific versions of its dependent libs\". But from what I can see there is _NO_ need for either of thes libraries to use a recent glibc, wxWidgets for example only has a check for glibc 2.1 or newer (during its ./configure). But it is not clear which features of wxWidgets 2.9.0 and/or boost 1.40.0 require the use of a glibc say above version 2.5 (which is also pretty old, but pretty compatibile). I have sucessfully been able to build these versions (of wxWidgets/boost) against glibc 2.5.\nI believe this can be confirmed by the use of -Bstatic in \"src/makefile.unix\".\nThe only reason that glibc is a \"compatibility worry\" (as you put it) is because the project was build on a very new linux system. This forces all the downloaders to have as-new-a linux system as the build system in order to run it. This is not because there is some intrinsic compatibility worry as you describe it.\nI think I have created a custom wxWidgets 2.9.x build on OpenSUSE build service (OBS). I shall have a go with \"boost\" over the new few hours if all goes well. Then I can commit bitcoind package and get openSuSE builds. Then I can enable other distribution repos (CentOS, Ubuntu, SLE, Fedora, etc...).\nCan anyone confirm if boost \"1.40.0\" is needed or just \"1.40.0 or newer\" ? since 1.42.x is current (and that is already available for a number of platforms as packages). Can anyone explain the story behind this matter.\nWith wxWidgets 2.9.x is a development series so it is pre-release, so that is clear cut that a custom version needs to be built to get access to pre-release versions. But this problem I have solved in an OBS build.",
		"a": "It can be built with Boost 1.37 or later."
	},
	{
		"id": 371,
		"type": "ignore",
		"date": "2010-08-02 17:39:27",
		"src": "https://bitcointalk.org/index.php?topic=655.msg7057#msg7057",
		"q": "Hey guys,\nMy linux machine (debian 5 stable, 32 bit) was running bitcoin 0.20 for months now. I upgraded it to 0.36 today and the GUI won't appear, however bitcoin is running and seems to use the CPU. Where is the GUI? It won't appear, but there are no errors in the console when I run bitcoin from xterm.",
		"a": "Did it print anything to the console? Are you sure you didn't run \"bitcoind\"?\nTry version 0.3.7."
	},
	{
		"id": 372,
		"type": "ignore",
		"date": "2010-08-02 18:02:20",
		"src": "https://bitcointalk.org/index.php?topic=660.msg7068#msg7068",
		"q": "Hardware\nMacBook Pro 2.4 GHz Intel Core 2 Duo (Model 4,1)\n2 GB 667 MHz DDR2 SDRAM\nSoftware\nMac OS X 10.6.4 Snow Leopard\nBitcoin 0.3.7 (according to Bitcoin >> About)\nProblems\nPreferences: the preferences I have tried all have zero effect as far as I can tell. \"Minimize to the tray instead of the taskbar\" & \"Minimize to the tray on close\" do nothing (including effecting the cpu usage...see below). Start Bitcoin on system startup is grayed out although I have added it manually to my login items. I have not tried \"Limit coin generation to 'x' processors\" or \"Connect through socks4 proxy:\", but I can only guess that these options are not working either.\nA friend just explained what a \"nice process\" is. Sorry.\nCrash On Close: about ever other time I attempt to close Bitcoin using Bitcoin >> Quit the app crashes rather than closing like a friendly app should.\nCoin Generation: frankly I am trusting that this is NOT a bug, but just bad luck. I have been running the app for a few weeks now with zero generation. Again, I assume this is bad luck, but considering the other problems I wanted to mention it in case others were noticing this that were using my setup as well.\n-----------\nIf there are any known solution to these problems or if there is anything I can do to help sort them out please let me know. Thanks!",
		"a": "\"Minimize to the tray instead of the taskbar\" & \"Minimize to the tray on close\" must not be implemented yet on the Mac. We should grey them out in the next version."
	},
	{
		"id": 373,
		"type": "ignore",
		"date": "2010-08-02 19:02:46",
		"src": "https://bitcointalk.org/index.php?topic=648.msg7084#msg7084",
		"q": "Yes, since applying this patch I've generated 2 blocks.",
		"a": "Is it 2x fast on AMD and 1/2 fast on Intel?"
	},
	{
		"id": 374,
		"type": "ignore",
		"date": "2010-08-02 19:02:46",
		"src": "https://bitcointalk.org/index.php?topic=648.msg7084#msg7084",
		"q": "Btw. Why are you using this alignup<16> function when __attribute__ ((aligned (16))) will tell the compiler to align at compiletime?",
		"a": "Tried that, but it doesn't work for things on the stack. I ran some tests.\nIt doesn't even cause an error, it just doesn't align it."
	},
	{
		"id": 375,
		"date": "2010-08-02 20:22:08",
		"src": "https://bitcointalk.org/index.php?topic=632.msg7090#msg7090",
		"q": "Since it's a non breaking change, it should be done as soon as possible in my opinion, for those very reasons.\nThe question remains, is anyone willing to help implement it? I'm an experience programmer but I have no C++ experience unfortunately, so I'm gonna need a little help if I try to do this myself",
		"a": "The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure. Their code is too large to read and be sure that there's no way to form an input that would do something unexpected.\nI hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly. The serialization format we have is as dead simple and flat as possible. There is no extra freedom in the way the input stream is formed. At each point, the next field in the data structure is expected. The only choices given are those that the receiver is expecting. There is versioning so upgrades are possible.\nCAddress is about the only object with significant reserved space in it. (about 7 bytes for flags and 12 bytes for possible future IPv6 expansion)\nThe larger things we have like blocks and transactions can't be optimized much more for size. The bulk of their data is hashes and keys and signatures, which are uncompressible. The serialization overhead is very small, usually 1 byte for size fields.\nOn Gavin's idea about an existing P2P broadcast infrastructure, I doubt one exists. There are few P2P systems that only need broadcast. There are some libraries like Chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want. Those libraries are also much harder to install than ourselves."
	},
	{
		"id": 376,
		"type": "ignore",
		"date": "2010-08-03 20:56:11",
		"src": "https://bitcointalk.org/index.php?topic=454.msg7328#msg7328",
		"q": "Is satoshi noWx patch in 0.3.7 already? Before that bitcoind required wx, and I never seen Satoshi announcing that it's in trunk",
		"a": "Yes, 0.3.7 has it. It was in rev 112."
	},
	{
		"id": 377,
		"type": "ignore",
		"date": "2010-08-03 21:05:08",
		"src": "https://bitcointalk.org/index.php?topic=685.msg7331#msg7331",
		"q": "I have successfully built it with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the initial block download to disk.",
		"a": "I urge you not to use BDB 4.8. The database/log0000* files will be incompatible if anyone uses your build and then goes back to the official build."
	},
	{
		"id": 378,
		"date": "2010-08-03 21:26:26",
		"src": "https://bitcointalk.org/index.php?topic=689.msg7335#msg7335",
		"q": "Can you be more specific about which JSON libraries don't provide Content-Length ? It'd be nice to document that.",
		"a": "I guess we should try to support the case where there's no Content-Length parameter. I don't want to rip and replace streams though, even if it has to read one character at a time.\nThat is, assuming there actually are any libraries that don't support Content-Length."
	},
	{
		"id": 379,
		"date": "2010-08-03 22:45:07",
		"src": "https://bitcointalk.org/index.php?topic=661.msg7356#msg7356",
		"q": "Really? It seems to me more likely that a bunch of people left/crashed than a whole new network half the size of the legit one has gotten to you.\nI'm probably misunderstanding.",
		"a": "creighto: I agree with that idea. After a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance. It could tell if it's not hearing the hum of the world anymore."
	},
	{
		"id": 380,
		"date": "2010-08-03 22:45:07",
		"src": "https://bitcointalk.org/index.php?topic=661.msg7356#msg7356",
		"q": "Interesting info, so other than some double-spending issues, as long as the block chain isn't separated for more than 100 or so blocks (or 16+ hours),",
		"a": "In practice, splits are likely to be very asymmetrical. It would be hard to split the world down the middle. More likely it would be a single country vs the rest of the world, lets say a 1:10 split. In that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days. Also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong."
	},
	{
		"id": 381,
		"date": "2010-08-03 22:45:07",
		"src": "https://bitcointalk.org/index.php?topic=661.msg7356#msg7356",
		"q": "If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?",
		"a": "There's no time limit. Assuming you weren't spending coins generated in the minority fork, or spending someone's double-spends you received, your transactions can get into the other chain at any time later."
	},
	{
		"id": 382,
		"date": "2010-08-04 00:09:32",
		"src": "https://bitcointalk.org/index.php?topic=685.msg7372#msg7372",
		"q": "There are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)",
		"a": "I'd rather you didn't make a build of the 1000 node connecting version available. It won't take very many people running that before we have to make another release just to limit the incoming connections."
	},
	{
		"id": 383,
		"date": "2010-08-04 00:29:37",
		"src": "https://bitcointalk.org/index.php?topic=696.msg7381#msg7381",
		"q": "Link takes me to 3.7",
		"a": "I guess SourceForge hasn't updated its mirrors yet. The files are there on the admin side, but not on the user side. I have no idea how long that will take. It's always been immediate in the past.\nSourceForge is updated now."
	},
	{
		"id": 384,
		"date": "2010-08-04 00:40:40",
		"src": "https://bitcointalk.org/index.php?topic=635.msg7385#msg7385",
		"q": "I think that Red's idea is great if it can be properly designed.\nThe only problem with this whole procedure is that both parties are required to put up capital. The one buying a service and the one performing the service both must put up cash. Unfortunately the one providing the service is also putting up their service.",
		"a": "The software is designed to support things like this. I was going to post details of the plans for Escrow, but since getting slashdotted I haven't had time."
	},
	{
		"id": 385,
		"type": "favorite",
		"date": "2010-08-04 16:25:36",
		"src": "https://bitcointalk.org/index.php?topic=287.msg7524#msg7524",
		"q": "It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.",
		"a": "Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.\nBitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments."
	},
	{
		"id": 386,
		"type": "ignore",
		"date": "2010-08-05 16:03:21",
		"src": "https://bitcointalk.org/index.php?topic=287.msg7687#msg7687",
		"q": "I think the current system works fine. If someone wants to implement a micro-payment system then they will have to host enough nodes and contribute enough processing power to include their small transactions. I see no reason to require any node to accept or forward micro-payment transactions if said nodes does not wish to.\nThe real issue is that even a simple legitimate automated micro-payment system could overload bitcoin by introducing more transactions than the credit card system currently uses. The net result is that block sizes could become HUGE.\nIn my use case you have a P2P system where they pay for priority downloads. Assume you have a single \"torrent\" file with 100,000 people all seeding and downloading. That could easily generate 100,000 micro-payments per minute. Now clearly, the program would only have to use BTC in the event that upload != download between two clients.\nIt would be distributed and thus there would be no easy way to identify \"spam\" from legitimate usage. Even using my solution of transferring 1+ BTC at a time and giving change if the balance is greater than 0.01 could cause a transaction bloat writ large.\nI suspect that the \"cost\" of handing individual transactions may be low (.00001 BTC) but the cost of handling ALL of those little transactions from millions of users using automated payment negotiation/bidding systems would quickly make it impossible to even listen for all incoming transactions.\nThe only solution to this problem is to make broadcasting of a transaction \"non free\". Namely, if you want me to include it you have to pay me. The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block. In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.\nThe implication is that you may not even receive notice of payment until a node that you paid to receive your transaction and *attempt* to integrate it into a block manages to do so. This means that you would not even see 0/unconfirmed and that a transaction must make it into a block before anyone that wasn't paid to *attempt* to integrate it even knows it exists.\nThis structure would encourage pay-to-ip systems because that make the receiver of the payment responsible for paying to get it integrated. Either they run their own bitcoin generators *or* they pay to send the transaction to someone who is.",
		"a": "Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.\nI am not claiming that the network is impervious to DoS attack. I think most P2P networks can be DoS attacked in numerous ways. (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)\nIf we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee. 0.1.5 actually had an option to set that, but I took it out to reduce confusion. Free transactions are nice and we can keep it that way if people don't abuse them.\nThat brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01? It would be awfully annoying to ask each time. If you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left. I think it should just add it automatically. It's trivial compared to the fees many other types of services add automatically."
	},
	{
		"id": 387,
		"type": "ignore",
		"date": "2010-08-05 16:03:21",
		"src": "https://bitcointalk.org/index.php?topic=287.msg7687#msg7687",
		"q": "Does including more slow down your hashing rate?",
		"a": "No, not at all."
	},
	{
		"id": 388,
		"date": "2010-08-05 16:30:20",
		"src": "https://bitcointalk.org/index.php?topic=287.msg7694#msg7694",
		"q": "Payments would generally be advanced, say 1 BTC at a time and when the connection closes any \"change\" would be returned. This rule makes it impossible to pay for a simple \"search query\" with no further transactions.",
		"a": "One alternative is to use a round-up system. You pay for, say, 1000 pages or images or downloads or searches or whatever at a time. When you've used up your 1000 pages, you pay for another 1000 pages. If you only use 1 page, then you have 999 left that you may never use, but it's not a big deal because the cost per 1000 is still small.\nOr you could pay per day. The first time you access the site on a given day, you pay for 24 hours of access.\nPer 1000 or per day may be easier for consumers to get their heads around too. They worry about per item because it's harder to figure if it might add up too fast. Unlimited for 24 hours they know what the cost will be. Or if 1000 seems like plenty, they're not worrying that it's costing more with each click if they figure 1000 is more than they'll probably use."
	},
	{
		"id": 389,
		"date": "2010-08-05 16:39:58",
		"src": "https://bitcointalk.org/index.php?topic=287.msg7696#msg7696",
		"q": "The only solution to this problem is to make broadcasting of a transaction \"non free\". Namely, if you want me to include it you have to pay me. The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block. In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.",
		"a": "I don't know a way to implement that. The transaction fee to the block creator uses a special trick to include the transaction fee without any additional size. If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?"
	},
	{
		"id": 390,
		"date": "2010-08-05 17:06:03",
		"src": "https://bitcointalk.org/index.php?topic=704.msg7703#msg7703",
		"q": "Just an idea... you could remove the message that tells the user he already got coins and always pretend to have sent coins when in reality you didn't. Maybe with a nice \"If it doesn't work contact me at ...\" message. Hopefully they'll just assume it's broken and don't bother trying to get coins from it anymore.",
		"a": "Silently failing would look bad."
	},
	{
		"id": 391,
		"date": "2010-08-05 17:06:03",
		"src": "https://bitcointalk.org/index.php?topic=704.msg7703#msg7703",
		"q": "1. Rate limit based on the first byte of the IP address (79. or 81. in this case).",
		"a": "Definitely needed. What rate are you thinking of? Ultimately, it's better to rate limit it than to let it all drain out."
	},
	{
		"id": 392,
		"date": "2010-08-05 17:06:03",
		"src": "https://bitcointalk.org/index.php?topic=704.msg7703#msg7703",
		"q": "3. Rate limit based on last two domains of reverse DNS lookup of the IP address (rima-tde.net in this case).",
		"a": "That might work surprisingly well. If it works, it keeps them from hitting the rate limit, but the rate limit is there as the last line of defence."
	},
	{
		"id": 393,
		"date": "2010-08-05 17:06:03",
		"src": "https://bitcointalk.org/index.php?topic=704.msg7703#msg7703",
		"q": "4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet).",
		"a": "Definitely time to lower it."
	},
	{
		"id": 394,
		"type": "ignore",
		"date": "2010-08-05 17:28:40",
		"src": "https://bitcointalk.org/index.php?topic=711.msg7705#msg7705",
		"q": "I cant figure out how to send a transaction to an ip address from bitcoind command line interface. Has the function been implemented yet? (linux 64 if it matters)",
		"a": "It's not implemented.\nIt turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention."
	},
	{
		"id": 395,
		"type": "ignore",
		"date": "2010-08-05 17:38:21",
		"src": "https://bitcointalk.org/index.php?topic=713.msg7706#msg7706",
		"q": "The downside to a non \"broadcast\" system is that it makes it easier to double-spend and in fact your payment to generate would be a prime candidate for double spending.\nI am not sure that the system can stand such delays in the broadcast system. I suppose those worried about double spending would pay to have the transaction \"vetted\" by more nodes and those that can handle a loss would take the risk.",
		"a": "I can't think of a way to implement that. All the transaction fees would be additional transactions. What about the transaction fees for the transaction fee's transaction?"
	},
	{
		"id": 396,
		"date": "2010-08-05 17:49:43",
		"src": "https://bitcointalk.org/index.php?topic=287.msg7710#msg7710",
		"q": "Right now the transaction fee address is left \"blank\" and the block generator fills it out.\nNow you would fill it in with the address of the person you are asking to build the block.",
		"a": "If you're only going to have one person work on building the block, that could take days. Oh, do you mean send a different variation to each node with the tx fee written to them?\nThe way it is now, it's whoever builds this gets it.\nIf we needed to, we could have a BitTorrent-esque tit-for-tat for transaction broadcast. Relay paying transactions to me, or I won't relay them to you. It probably won't be an actual problem though. It only takes one node relaying like it should to cancel out 7 others greedily not relaying."
	},
	{
		"id": 397,
		"type": "favorite",
		"date": "2010-08-05 18:08:30",
		"src": "https://bitcointalk.org/index.php?topic=645.msg7712#msg7712",
		"q": "if the buyer refuses to finalise the transaction and the seller refuses to permit a refund, they have 2 choices.\n1) be spiteful and nobody will get anything\n2) agree on a third party to send the money to. that third party will be an arbitrator who will weigh up both sides of the argument and come to a decision as to who should be returned the money, minus whatever fee they agreed with the two hurt parties.\nSubsequent to this, I also realised that my suggestion is open to trolling whereby a seller makes someone do an escrow transaction and then refuses to ship anything or arbitrate, my solution to this issue gives the following modification of the system:\nthe buyer makes an escrow transaction which is then presented to the seller, if the seller wants to go ahead, they must agree to be debited a sum stipulated by the buyer, the seller agrees and the escrow transaction then goes into the network for inclusion into the block chain, both parties are now down on their money.\nif everything goes to plan, the buyer OKs the release of the funds and the seller gets the payment + his \"trust deposit\" returned.\nif the buyer wishes to cancel, the seller authorises the cancellation and both parties get their original funds back.\nif nobody can agree on a release, both parties now have an incentive to go to an arbitrator, when the arbitrator is authorised to receive the transaction funds, the trust deposit gets immediately returned to the seller, the arbitrator doesn't get a say over those funds.",
		"a": "A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money."
	},
	{
		"id": 398,
		"date": "2010-08-07 16:28:17",
		"src": "https://bitcointalk.org/index.php?topic=723.msg8103#msg8103",
		"q": "...which doesn't sound like it would work very well for Bitcoin.",
		"a": "Once you get away from a system where each node's influence is proportional to their CPU power, then what else do you use to determine who is (approximately) one person?"
	},
	{
		"id": 399,
		"type": "favorite",
		"date": "2010-08-07 17:46:09",
		"src": "https://bitcointalk.org/index.php?topic=721.msg8114#msg8114",
		"q": "I'd rather like to support a system like bitcoin, that i can use myself for value-transaction, than searching for E.T. to make some scientist save cash. That's a waste of energy and still people do it voluntarily without any benefits.\nAnd i really dont care if some botnet-ops make a profit or not, as long as they don't bother ME (or anyone else).",
		"a": "It's the same situation as gold and gold mining. The marginal cost of gold mining tends to stay near the price of gold. Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange.\nI think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore, not having Bitcoin would be the net waste."
	},
	{
		"id": 400,
		"type": "favorite",
		"date": "2010-08-07 17:46:09",
		"src": "https://bitcointalk.org/index.php?topic=721.msg8114#msg8114",
		"q": "As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to \"roll as many dice as posible\" within that given time period? The \"chain of proof\" for coin ownership and transactions doesn't depend on the method for spawning coins.",
		"a": "Each node's influence on the network is proportional to its CPU power. The only way to show the network how much CPU power you have is to actually use it.\nIf there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it. IP addresses... much easier to get lots of them than CPUs.\nI suppose it might be possible to measure CPU power at certain times. For instance, if the CPU power challenge was only run for an average of 1 minute every 10 minutes. You could still prove your total power at given times without running it all the time. I'm not sure how that could be implemented though. There's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back.\nProof-of-work has the nice property that it can be relayed through untrusted middlemen. We don't have to worry about a chain of custody of communication. It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself."
	},
	{
		"id": 401,
		"date": "2010-08-07 20:04:59",
		"src": "https://bitcointalk.org/index.php?topic=645.msg8137#msg8137",
		"q": "Due to that recourse, it is unlikely to be used as an escrow mechanism",
		"a": "Really? Do you think people won't be able to understand the benefit? (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.)"
	},
	{
		"id": 402,
		"type": "ignore",
		"date": "2010-08-07 21:16:01",
		"src": "https://bitcointalk.org/index.php?topic=648.msg8145#msg8145",
		"q": "CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp.",
		"a": "Sorry about that. CRITICAL_BLOCK isn't perfect. You have to be careful not to break or continue out of it. There's an assert that catches and warns about break. I can be criticized for using it, but the syntax would be so much more bloated and error prone without it.\nIs there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around? For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow? I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level. I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope. But it would be really nice if this was working on most CPUs."
	},
	{
		"id": 403,
		"type": "ignore",
		"date": "2010-08-09 18:50:41",
		"src": "https://bitcointalk.org/index.php?topic=753.msg8388#msg8388",
		"q": "Yet another argument for cmake or similar.",
		"a": "I found that SSE2 only added a slight 2% speedup, which didn't seem worth the incompatibility. I was trying to take the safer option.\nIt doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime. There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime. Maybe I'm not looking in the right place.\nShould we enable SSE2 in all the makefiles? It seems like we must in case someone compiles with 64-bit.\nI will recompile the 64-bit part of the Linux 0.3.8 release."
	},
	{
		"id": 404,
		"date": "2010-08-09 20:13:26",
		"src": "https://bitcointalk.org/index.php?topic=760.msg8413#msg8413",
		"q": "I understand the Y2038 problem from a layman's perspective. My point was that, I doubted that a Y2038 problem exists within the structure of bitcoin. Since the timestamp is relative only to a particular position within the blockchain, there is no reason that a client should require an accurate timestamp within the block. And then, what would that be? GMT? I'm pretty sure that my client is doing fine with local time. If that could be getting any successful blocks rejected, let me know, please.",
		"a": "unsigned int is good until 2106. Surely the network will have to be totally revamped at least once by then.\nThere should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int."
	},
	{
		"id": 405,
		"type": "ignore",
		"date": "2010-08-09 20:34:06",
		"src": "https://bitcointalk.org/index.php?topic=753.msg8417#msg8417",
		"q": "It's a fact.\nI intend to eventually sort out all building hassles and have a reliable build procedure across all win/unix 32/64-bit platform combinations.\nOn that note, I'm currently tackling x64 build for windows and notice that for 64-bit MSVC, the X86_SHA256_HashBlocks function is deferred to an external definition that is not present in the project. In the original CryptoPP library it seems to be in a separate asm module. I wonder how are people building x64 on windows, are they setting defines to use the C-source sha version?",
		"a": "I uploaded 0.3.8.1 for Linux with re-built 64-bit. I ran a difficulty 1 test with it and it has generated blocks.\nhttp://bitcointalk.org/index.php?topic=765.0\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download"
	},
	{
		"id": 406,
		"type": "ignore",
		"date": "2010-08-09 20:55:06",
		"src": "https://bitcointalk.org/index.php?topic=765.msg8422#msg8422",
		"q": "IMO, SSE should be required for generation, not simply to run the client.",
		"a": "That's a good point, I believe you could run with generation off if you don't have SSE2.\nHow about add to the top of cryptopp/config.h:\n#if !defined(_M_X64) && !defined(__x86_64__)\n#define CRYPTOPP_DISABLE_SSE2 1\n#endif\nthat would disable SSE2 for 32-bit builds. (at least with GCC or MSVC)"
	},
	{
		"id": 407,
		"type": "favorite",
		"date": "2010-08-09 21:28:39",
		"src": "https://bitcointalk.org/index.php?topic=721.msg8431#msg8431",
		"q": "The power used is not wasteful. It is simply what the owner is willing to commit to the project. Even so, it may be used even as \"waste heat\". I am an electritian by trade, and years ago I had the following idea form, while installing a 'heat trace' network on insulated sprinkler lines inside an open air parking garage.\nThe 'heat trace' is a fairly expensive cable that has a continuous resistive core to produce low intensity electric heat along the length of the pipe that it's taped onto. Insulation is then wrapped around this assembly. The best, and most efficient, systems have a temp reactive core; so that the closer to the freezing point that the cable itself becomes at any given length, the lower the resistance across the core becomes, resulting in an increase in heat output along the colder and less well insulated sections.\nAt the time, I was playing with an early form of distributed computing called \"Condor\", which allowed single processes to be exported to other computers upon a network and their disk I/O shipped back across the network to a master server without the process being able to tell the difference. I thought then that a small \"computer on a chip\" wired upon a flat network cable would be able to effectively perform the same functions of keeping the pipes above freezing with local temp sensitivity while also crunching numbers in exactly the same way that bitcoin requires. Such an idea would require a network that permited quite a bit of power in order to not need an unacceptable number of power points along the pipe, but imagine the usefulness of such a system for companies that have such needs in very high (or very low) latitudes.\nWhat if such a system were retrofitted onto the Alaskan Oil Pipeline, for example, one mile at a time?",
		"a": "The heat from your computer is not wasted if you need to heat your home. If you're using electric heat where you live, then your computer's heat isn't a waste. It's equal cost if you generate the heat with your computer.\nIf you have other cheaper heating than electric, then the waste is only the difference in cost.\nIf it's summer and you're using A/C, then it's twice.\nBitcoin generation should end up where it's cheapest. Maybe that will be in cold climates where there's electric heat, where it would be essentially free."
	},
	{
		"id": 408,
		"date": "2010-08-10 23:46:00",
		"src": "https://bitcointalk.org/index.php?topic=765.msg8628#msg8628",
		"q": "Fix is in svn r124, r125 added -maxconnections.",
		"a": "SVN rev 128: disable SSE2 on 32-bit. This may only disable it for MSVC and GCC. Other compilers might have different 64-bit defines."
	},
	{
		"id": 409,
		"date": "2010-08-11 00:14:22",
		"src": "https://bitcointalk.org/index.php?topic=770.msg8637#msg8637",
		"q": "You also don't have to prove to the notary that you have X BTC in your account to spend.\nAlthough I was recently reading about Zero-knowledge proofs if you could use something like that to prove that your account had X BTC in it without revealing anything else it might be what you're looking for.\nI'm just worried what you want is theoretically impossible.",
		"a": "This is a very interesting topic. If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.\nOriginally, a coin can be just a chain of signatures. With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations. It's the need to check for the absence of double-spends that requires global knowledge of all transactions.\nThe challenge is, how do you prove that no other spends exist? It seems a node must know about all transactions to be able to verify that. If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before. Do you have any ideas on this?\nIt's hard to think of how to apply zero-knowledge-proofs in this case.\nWe're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included."
	},
	{
		"id": 410,
		"date": "2010-08-11 01:30:02",
		"src": "https://bitcointalk.org/index.php?topic=750.msg8649#msg8649",
		"q": "Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party.",
		"a": "That makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate.\nWhen you pay for something up front, you can't get it back either. Consumers seem comfortable with that. It's no worse than that.\nEither party always has the option to release it to the other."
	},
	{
		"id": 411,
		"date": "2010-08-11 01:30:02",
		"src": "https://bitcointalk.org/index.php?topic=750.msg8649#msg8649",
		"q": "But the money burning solution, while great at preventing economically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that.",
		"a": "Then you must also be against the common system of payment up front, where the customer loses.\nPayment up front: customer loses, and the thief gets the money.\nSimple escrow: customer loses, but the thief doesn't get the money either.\nAre you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?\nImagine someone stole something from you. You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too? If they give it back, you can re-activate it.\nImagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again.\nIt still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about \"money burning\" for the purposes of game theory discussion. The money is never truly burned. You have the option to release it at any time forever."
	},
	{
		"id": 412,
		"type": "ignore",
		"date": "2010-08-11 01:42:30",
		"src": "https://bitcointalk.org/index.php?topic=784.msg8651#msg8651",
		"q": "Building r127 here, we see some missing casts, apparently:\nrpc.cpp: In function json_spirit::Value gethashespersec(const json_spirit::Array&, bool):\nrpc.cpp:340: error: conversion from int64 to json_spirit::Value is ambiguous\njson/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:275: note: json_spirit::Value_impl<Config>::Value_impl(uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:267: note: json_spirit::Value_impl<Config>::Value_impl(int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:259: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:251: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:219: note: json_spirit::Value_impl<Config>::Value_impl(typename Config::String_type::const_pointer) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\nrpc.cpp:341: error: conversion from int64 to json_spirit::Value is ambiguous\njson/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:275: note: json_spirit::Value_impl<Config>::Value_impl(uint64_t) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:267: note: json_spirit::Value_impl<Config>::Value_impl(int64_t) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:259: note: json_spirit::Value_impl<Config>::Value_impl(int) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:251: note: json_spirit::Value_impl<Config>::Value_impl(bool) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]\njson/json_spirit_value.h:219: note: json_spirit::Value_impl<Config>::Value_impl(typename Config::String_type::const_pointer) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >] <near match>\nThe following patch seems to solve the problem:\n--- a/rpc.cpp\n+++ b/rpc.cpp\n@@ -337,8 +337,8 @@ Value gethashespersec(const Array& params, bool fHelp)\n\"Returns a recent hashes per second performance measurement while g\nif (GetTimeMillis() - nHPSTimerStart > 8000)\n- return (int64)0;\n- return (int64)dHashesPerSec;\n+ return (int64_t)0;\n+ return (int64_t)dHashesPerSec;\n}",
		"a": "Updated SVN. Thanks.\nThere's little hope of not repeatedly stumbling over that in the future. It doesn't break the compile for me."
	},
	{
		"id": 413,
		"date": "2010-08-11 21:07:59",
		"src": "https://bitcointalk.org/index.php?topic=770.msg8798#msg8798",
		"q": "It's hard for me too! :-) Was interesting to re-read though!\nWas hoping it would spawn some insight on a way for nodes to demonstrate that they \"always follow\" the block generating rules, in absence of everyone needing to have the set of all transactions to double check.\nIt didn't. :-)",
		"a": "Still thinking this idea through...\nThe only job the network needs to do is to tell whether a spend of an outpoint is the first or not.\nIf we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as:\n- the value\n- the association of inpoints and outpoints in one transaction\nThe network would track a bunch of independent outpoints. It doesn't know what transactions or amounts they belong to. A client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent. The network keeps the outpoint and the first valid inpoint that proves it spent. The inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is.\nI believe the clients would have to keep the entire history back to the original generated coins. Someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend. Maybe the data transfer could be done as an e-mail attachment.\nThe fact that clients have to keep the entire history reduces the privacy benefit. Someone handling a lot of money still gets to see a lot of transaction history. The way it retrospectively fans out, they might end up seeing a majority of the history. Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history."
	},
	{
		"id": 414,
		"date": "2010-08-11 21:46:51",
		"src": "https://bitcointalk.org/index.php?topic=782.msg8803#msg8803",
		"q": "I added to the FAQ the warning to back up after each transaction. Is it necessary btw to stop the client before making a backup? That's a bit inconvenient. Automatic backups would be useful indeed.",
		"a": "You can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup. (like 5 seconds)"
	},
	{
		"id": 415,
		"date": "2010-08-11 21:46:51",
		"src": "https://bitcointalk.org/index.php?topic=782.msg8803#msg8803",
		"q": "Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to \"empty your wallet\" for EACH transaction.",
		"a": "No, it doesn't usually empty your wallet with each transaction. It uses the smallest set of coins it can find to add up to near the amount. In this case, unfortunately, his wallet had a single 9000 BTC bill in it, and it had to break it to get 1 BTC and 8999 BTC change."
	},
	{
		"id": 416,
		"date": "2010-08-11 22:40:25",
		"src": "https://bitcointalk.org/index.php?topic=788.msg8804#msg8804",
		"q": "I agree that eventually the latter will have to be done. It's for the reasons you pointed out that my DHT solution has flaws. Curiously it's all a side effect of not being able to implement the former constraint.\nIf you allow validating nodes to arbitrarily ignore transactions you risk breaking the key requirement that all validating nodes receive and record all transactions. The current presumption is that all validators try to receive and record all transactions. If a transaction is non-uniformly delayed and missed by the node who completes the block, it is presumed that statistically the transaction would be recorded in a subsequent block. However, that requires continually rebroadcasting the transaction to assure it gets through.\nLet's say throughput was right and there was an advantage to a node saying, \"I'm only willing to take 5 transactions a 10 block period.\" in that case it still generates blocks that can't be rejected by others, but an increasing number of unrecorded transactions backlogs with each minimal block. This causes additional retransmissions exacerbating the bandwidth problem.\nIn effect you rely on unrestricted nodes to compensate for a problem caused by restricted nodes. So if the restricted nodes are causing problems and doing less validation and recording work than other nodes, why should they be rewarded equally for generating blocks? That seems counter productive.\nIt would be better to say, \"record all transactions or you can't be a validator!\" Less validators means less bandwidth usage overall. It also becomes easier to spot abusers.\n----ps----\nAn zero knowledge proof-of-completeness would be for competing validators to reject a proof-of-work block if it didn't contain 99% of the known outstanding transactions.",
		"a": "It doesn't have to be such a breaking change. New nodes could accept old transactions for a long time until most nodes have already upgraded before starting to refuse transactions without PoW. Or, they could always accept old transactions, but only a limited number per time period.\nI've thought about PoW on transactions many times, but usually I end up thinking a 0.01 transaction fee is essentially similar and better. 0.01 is basically a proof of work, but not wasted. But if the problem is validating loads of transactions, then PoW could be checked faster.\nA more general umbrella partial solution would be to implement the idea where an unlikely dropoff in blocks received is detected. Then an attacker would still need a substantial portion of the network's power to benefit from a DoS attack."
	},
	{
		"id": 417,
		"date": "2010-08-11 22:40:25",
		"src": "https://bitcointalk.org/index.php?topic=788.msg8804#msg8804",
		"q": "Bitcoin's p2p network is subject to various kinds of denial of service attacks.\nThere, I said it.",
		"a": "+1\nAny demonstration tests at this point would only show what we already know, and divert dev time from strengthening the system to operational fire fighting."
	},
	{
		"id": 418,
		"date": "2010-08-11 23:28:50",
		"src": "https://bitcointalk.org/index.php?topic=287.msg8810#msg8810",
		"q": "Test network have test scale.\nHmm, I think the other guys may not ask your permission to abuse the real network next time.\nThey will just do it.\nI'm sure, the Bitcoin is useless if it is vulnerable to such a simple intrusion.\nWe should prove, that it is sustainable to real world threats. Like me\nPerhaps somebody just experimented already?",
		"a": "It would be nice to keep the blk*.dat files small as long as we can.\nThe eventual solution will be to not care how big it gets.\nBut for now, while it's still small, it's nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won't matter much anymore.\nThere's more work to do on transaction fees. In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee. However, I haven't had time yet to add that option to the UI.\nScale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance."
	},
	{
		"id": 419,
		"type": "ignore",
		"date": "2010-08-12 00:02:06",
		"src": "https://bitcointalk.org/index.php?topic=790.msg8814#msg8814",
		"q": "There is this piece of code in headers.h:\n#ifdef __WXMAC_OSX__\n#define __WXMAC__ 1\n#define __WXOSX__ 1\n#define __BSD__ 1\n#endif\n#endif",
		"a": "That code was a bad idea anyway, I'm deleting it. Any Mac code should only use __WXMAC_OSX__, not __WXMAC__ or __WXOSX__, and we should stop using __BSD__."
	},
	{
		"id": 420,
		"type": "ignore",
		"date": "2010-08-12 00:02:06",
		"src": "https://bitcointalk.org/index.php?topic=790.msg8814#msg8814",
		"q": "#if (defined(__unix__) || defined(unix)) && !defined(USG)\n#include <sys/param.h>\n#endif",
		"a": "Will that definitely cause BSD to be defined on Mac?"
	},
	{
		"id": 421,
		"date": "2010-08-12 02:46:56",
		"src": "https://bitcointalk.org/index.php?topic=770.msg8836#msg8836",
		"q": "I thought this too at first. But then I convinced myself otherwise.",
		"a": "Are you back to talking about the existing Bitcoin system here?\nI was talking about in the hypothetical system I was describing, if the network doesn't know the values and lineage of the transactions, then it can't verify them and vouch for them, so the clients would have to keep the history all the way back.\nIf a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is:\n1) Show it the entire history back to the original generated coin.\n2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true.\nBut if the network didn't know all the values and lineage of the transactions, it couldn't do 2), I don't think."
	},
	{
		"id": 422,
		"type": "ignore",
		"date": "2010-08-12 21:14:20",
		"src": "https://bitcointalk.org/index.php?topic=790.msg8919#msg8919",
		"q": "Don't know if Mac OS X is technically a BSD and I don't have access to a Mac, maybe someone else may test it.\nIf there are other Mac (and not BSD) specialties, then we'd need to check both for __WXMAC_OSX__ and BSD or detect these in some other way altogether.",
		"a": "This is in SVN rev 130. Check that it compiles right.\n#if (defined(__unix__) || defined(unix)) && !defined(USG)\n#include <sys/param.h> // to get BSD define\n#endif\n#ifdef __WXMAC_OSX__\n#ifndef BSD\n#define BSD 1\n#endif\n#endif"
	},
	{
		"id": 423,
		"type": "ignore",
		"date": "2010-08-12 21:34:44",
		"src": "https://bitcointalk.org/index.php?topic=691.msg8922#msg8922",
		"q": "How would an attacker connect to both sides during this split in order to spend the coins? And if the attacker can do it, the likelihood that one or more honest nodes could bridge the divide is pretty good.",
		"a": "True, there would probably be someone with a dial-up modem or satellite dish internet. Rarer would be someone who has both that and the wired internet that has the outage, but if it's a big enough segment to matter, out of a million people there's bound to be a multi-home geek.\nISP network cuts are just your local area. If you still have communication with the rest of your area, it would probably be something like 1/1000 of the world or less. Block generation in the segment would take several hours per block.\nI favour the plan to monitor if the frequency of blocks received drops too slow. That covers a large range of possibilities."
	},
	{
		"id": 424,
		"date": "2010-08-12 21:43:29",
		"src": "https://bitcointalk.org/index.php?topic=601.msg8924#msg8924",
		"q": "I've tried to do it before too, but I never considered it a large enough bug to report. It would be nice to see a fix, though.",
		"a": "Fixed in SVN rev 130."
	},
	{
		"id": 425,
		"type": "ignore",
		"date": "2010-08-12 22:07:23",
		"src": "https://bitcointalk.org/index.php?topic=648.msg8929#msg8929",
		"q": "My Core2Quad (Q6600) slowed down 50%, my i5 improved ~200%, thus I don't think what you state is accurate. Maybe starting at some specific Core2?",
		"a": "That big of a difference in speed, by a factor of 4 or 6, feels like it's likely to be some quirky weak spot or instruction that the old chip is slow with. Unless it's a touted feature of the i5 that they made SSE2 six times faster.\nA quick summary:\nXeon Quad 41% slower\nCore 2 Duo 55% slower\nCore 2 Duo same (vess)\nCore 2 Quad 50% slower\nCore i5 200% faster (nelisky)\nCore i5 100% faster (vess)\nAMD Opteron 105% faster\naceat64:\nMy system went from ~7100 to ~4200.\nThis particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz.\nimpossible7:\non an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121)\nMy Core2Quad (Q6600) slowed down 50%,\nmy i5 improved ~200%,\nimpossible7:\non an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!)"
	},
	{
		"id": 426,
		"type": "favorite",
		"date": "2010-08-13 03:15:23",
		"src": "https://bitcointalk.org/index.php?topic=795.msg8960#msg8960",
		"q": "From what I understand a node will not include transactions in it's blocks unless the transaction includes a fee that meets the node's requirements. So in the case of a node setting the fee to 1,000 it would likely never include any transactions in blocks it generates, which means it will miss out on any transaction fees other nodes would have gotten. There really isn't a reason to set a nodes requirements higher then the rest of the network since you are basically just pricing yourself out of the market.",
		"a": "No, that's not what it is.\n-paytxfee allows you to include a transaction fee with your transactions. If transaction confirmations become slow, you can get priority by using \"-paytxfee=0.01\". Any transactions you send would cost an extra 0.01. There's no reason to use more than 0.01.\nIt's just there in case we need it. It probably won't be needed, and it can be explained more if we do."
	},
	{
		"id": 427,
		"type": "ignore",
		"date": "2010-08-13 17:09:27",
		"src": "https://bitcointalk.org/index.php?topic=691.msg9041#msg9041",
		"q": "But there will be no irc server to bootstrap from.",
		"a": "Which doesn't matter because you can't access sourceforge to download the software either.\nIf you've ever been connected before, you don't need IRC to bootstrap anymore. Even if you haven't, you can bootstrap from seed nodes. IRC is completely redundant since 0.3.0."
	},
	{
		"id": 428,
		"type": "ignore",
		"date": "2010-08-13 19:28:47",
		"src": "https://bitcointalk.org/index.php?topic=770.msg9074#msg9074",
		"q": "If a client joined the network recently, it did so presuming that prior validators followed the rules and all pre-existing blocks are valid. (No one would join a known corrupt network)\nSure, in the current system, if transactions were never purged, a new node could validate all prior blocks for self consistency. But they still couldn't prove absolute truth. A bot net could have taken over and erased some transactions leaving \"a new truth\" and unhappy users. Equivalent to case 1) above.\nIn the current system, if transactions were Merkle tree purged then you have case 2) above. New comers must trust in the process. Anything missing, they don't need to worry about. Everyone must presume it was valid.\nThe unique thing I'm saying is that, if you have confidence in the bitcoin validation competition process (and we do!), then you really don't need \"a 2) thoroughly deep block\" to be very deep at all. Someone said in another thread that clients reject any changes to blocks more than two hours old. So we can have absolute confidence in all blocks buried 12 deep.\nSo if a transaction is unspent and buried 12 deep, we can purge all it's ancestors. They add warm fuzzies but no additional validation. We have to rely on them. There is simply no way to back up and change course.\nAfter that, every succeeding block presumes all the preceding blocks are true. Otherwise it would be a fork and not a succeeding block. So for any transaction validated against out-points in a preceding block, if those out-points exist and are unspent, they must be presumed valid. If those are presumed valid, their ancestors must be presumed valid even if purged.\n---\nIn the proposed system, exactly the same things are true.\nIf an antecedent out-point hash is unspent and buried 12 blocks deep, then it is absolutely unspent. Nothing can change that fact. No point in checking its ancestors. You can finish validating the transaction, cancel the in-points hashes and create new out-point hashes.\nInterestingly, if an antecedent out-point hash is unspent and buried LESS THAN 12 blocks deep, then it is RELATIVELY unspent. Curiously, there is still no point in checking its ancestors. The only thing that could change the antecedent's validity is a branch swap to a longer chain. If an ancestor of the antecedent you are validating this transaction against was swapped out, this transaction would be swapped out as well.\nIt's one of those cheesy time machine movie plots. Someone when back in time and spent my ancestor. Now I don't exist!\n=====\nSo what I'm saying is that in BOTH systems (existing and proposed) the only thing validators need to do is to validate that the antecedent out-points exist and are unspent (for the current block chain). The process assures that everything else remains relatively or absolutely valid.\nThe rest is just warm fuzzies.\n-- PS --\nI know this is too long and redundant, but I'm to tired to edit. :-)",
		"a": "I'm not grasping your idea yet. Does it hide any information from the public network? What is the advantage?\nIf at least 50% of nodes validated transactions enough that old transactions can be discarded, then everyone saw everything and could keep a record of it.\nCan public nodes see the values of transactions? Can they see which previous transaction the value came from? If they can, then they know everything. If they can't, then they couldn't verify that the value came from a valid source, so you couldn't take their generated chain as verification of it.\nDoes it hide the bitcoin addresses? Is that it? OK, maybe now I see, if that's it.\nCrypto may offer a way to do \"key blinding\". I did some research and it was obscure, but there may be something there. \"group signatures\" may be related.\nThere's something here in the general area:\nhttp://www.users.zetnet.co.uk/hopwood/crypto/rh/\nWhat we need is a way to generate additional blinded variations of a public key. The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them. Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key. These are the properties of blinding. Blinding, in a nutshell, is x = (x * large_random_int) mod m.\nWhen paying to a bitcoin address, you would generate a new blinded key for each use.\nThen you need to be able to sign a signature such that you can't tell that two signatures came from the same private key. I'm not sure if always signing a different blinded public key would already give you this property. If not, I think that's where group signatures comes in. With group signatures, it is possible for something to be signed but not know who signed it.\nAs an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it."
	},
	{
		"id": 429,
		"date": "2010-08-13 23:39:14",
		"src": "https://bitcointalk.org/index.php?topic=807.msg9134#msg9134",
		"q": "Do you need 'gettransaction', given the existence of 'getblock'?",
		"a": "It's too soon to start junking up the API for backward compatibility at all costs.\nJust return \"<txid>\"."
	},
	{
		"id": 430,
		"type": "ignore",
		"date": "2010-08-14 00:49:18",
		"src": "https://bitcointalk.org/index.php?topic=648.msg9145#msg9145",
		"q": "1. Do we know why it doesn't work on 32bit? Is is it because it's using 128bits and if so, would it help if we dropped it to 64?\n2. Thank you, I will look into implementing it on my 64bit systems.\n3. Excellent to hear. I'm looking forward to using it.\nI was planning on using it on a PE2650 dual proc Xeon @3.2GHz w/HT. I would really like to get this figured out to utilize that system. I am planning one as well. At current difficulty I would agree, except when the system needs to be run anyway and latency isn't an issue.",
		"a": "MinGW on Windows has trouble compiling it:\ng++ -c -mthreads -O2 -w -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH -I\"/boost\" -I\"/db/build_unix\" -I\"/openssl/include\" -I\"/wxwidgets/lib/gcc_lib/mswud\" -I\"/wxwidgets/include\" -msse2 -O3 -o obj/sha256.o sha256.cpp\nsha256.cpp: In function `long long int __vector__ Ch(long long int __vector__, long long int __vector__, long long int __vector__)':\nsha256.cpp:31: internal compiler error: in perform_integral_promotions, at cp/typeck.c:1454\nPlease submit a full bug report,\nwith preprocessed source if appropriate.\nSee <URL:http://www.mingw.org/bugs.shtml> for instructions.\nmake: *** [obj/sha256.o] Error 1"
	},
	{
		"id": 431,
		"type": "ignore",
		"date": "2010-08-14 04:22:29",
		"src": "https://bitcointalk.org/index.php?topic=648.msg9159#msg9159",
		"q": "Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?",
		"a": "If you haven't already, try aligning thash. It might matter. Couldn't hurt."
	},
	{
		"id": 432,
		"type": "ignore",
		"date": "2010-08-14 04:22:29",
		"src": "https://bitcointalk.org/index.php?topic=648.msg9159#msg9159",
		"q": "Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?",
		"a": "No help from -O0, same error.\nMinGW is GCC 3.4.5. Probably the problem.\nI'll see if I can get a newer version of MinGW."
	},
	{
		"id": 433,
		"type": "ignore",
		"date": "2010-08-15 03:40:29",
		"src": "https://bitcointalk.org/index.php?topic=648.msg9359#msg9359",
		"q": "Well, reporting back.\nI got it to compile by specifying -msse and -msse2 to gcc when compiling. I first was hashing about 692kh/s (50% of SVN r130[1400kh/s]) but recompiled and am now receiving about ~1120kh/s. This is currently the equivalent of using both of my CPUs without HyperThreading, though I can verify that it IS using HyperThreading. With HyperThreading turned off, I get ~1350kh/s. Pretty close to the stock build.\nAlso, does the git contain the patched and updated code?\n// SVN r130 Using HT.\n08/14/10 19:02 hashmeter 4 CPUs 1392 khash/s\n08/14/10 19:32 hashmeter 4 CPUs 1387 khash/s\n08/14/10 20:02 hashmeter 4 CPUs 1386 khash/s\n08/14/10 20:32 hashmeter 4 CPUs 1380 khash/s\n08/14/10 21:02 hashmeter 4 CPUs 1363 khash/s\n// With -msse -msse2, first run. Using HT.\n08/14/10 21:32 hashmeter 4 CPUs 692 khash/s\n08/14/10 22:06 hashmeter 4 CPUs 1011 khash/s\n08/14/10 22:11 hashmeter 4 CPUs 1104 khash/s\n08/14/10 22:16 hashmeter 4 CPUs 1120 khash/s\n// NOT using HT.\n08/14/10 22:21 hashmeter 2 CPUs 1359 khash/s\n08/14/10 22:26 hashmeter 2 CPUs 1340 khash/s\nJust wanted to tell my story and help with whatever information I could.",
		"a": "On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but SIGSEGV when called by BitcoinMiner. So now it doesn't look like it's the version of GCC, it's something else, maybe just the luck of how the stack is aligned.\nI have it working fine on GCC 4.3.3 on Ubuntu 32-bit.\nI found the problem with Crypto++ on MinGW 4.5.0. Here's the patch for that:\n--- \\old\\sha.cpp Mon Jul 26 13:31:11 2010\n+++\new\\sha.cpp Sat Aug 14 20:21:08 2010\n@@ -336,7 +336,7 @@\nROUND(14, 0, eax, ecx, edi, edx)\nROUND(15, 0, ecx, eax, edx, edi)\n- ASL(1)\n+ ASL(label1) // Bitcoin: fix for MinGW GCC 4.5\nAS2(add WORD_REG(si), 4*16)\nROUND(0, 1, eax, ecx, edi, edx)\nROUND(1, 1, ecx, eax, edx, edi)\n@@ -355,7 +355,7 @@\nROUND(14, 1, eax, ecx, edi, edx)\nROUND(15, 1, ecx, eax, edx, edi)\nAS2( cmp WORD_REG(si), K_END)\n- ASJ( jne, 1, b)\n+ ASJ( jne, label1, ) // Bitcoin: fix for MinGW GCC 4.5\nAS2( mov WORD_REG(dx), DATA_SAVE)\nAS2( add WORD_REG(dx), 64)"
	},
	{
		"id": 434,
		"date": "2010-08-15 16:37:16",
		"src": "https://bitcointalk.org/index.php?topic=813.msg9454#msg9454",
		"q": "This is a good point. I don't think I underestimated people's ability to generate bitcoins efficiently and legitimately - the difficulty adjustment does a good job of compensating for that, and that makes it a non-issue in my scenario. But I probably underestimated the effect of minters using other people's resources without their knowledge and consent. The FAQ theorizes that the cost of minting will approach the price of electricity minus a thin profit margin, and I probably accepted that theory too uncritically. If resource theft becomes the primary way to finance bitcoin minting, flaws in the difficulty adjustment will have a more subtle impact.",
		"a": "Some places where generation will gravitate to:\n1) places where it's cheapest or free\n2) people who want to help for idealogical reasons\n3) people who want to get some coins without the inconvenience of doing a transaction to buy them\nThere are legitimate places where it's free. Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating. Many small flats have electric heat out of convenience.\nHow expensive is heating oil? With the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost.\nThere's also kids putting it on their parent's power bill, employees their employer, botnets, etc.\nCase 3 comes into play for small amounts. The overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments. I think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change."
	},
	{
		"id": 435,
		"date": "2010-08-15 18:11:41",
		"src": "https://bitcointalk.org/index.php?topic=806.msg9475#msg9475",
		"q": "the extended-help might have been based on my idea, but the code was somewhat different.",
		"a": "The idea was the main part. When you posted your patch, I realized it should have been done that way instead of \"-?\". I always had reservations about \"-?\" because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server."
	},
	{
		"id": 436,
		"type": "ignore",
		"date": "2010-08-15 18:23:26",
		"src": "https://bitcointalk.org/index.php?topic=820.msg9478#msg9478",
		"q": "I did a quick test, will report back when I try it on more machines.\nPentium E5300 Dual-Core 2.6 GHz (2MB cache, FSB 800MHz)\nProcessor info: http://en.wikipedia.org/wiki/Wolfdale_%28microprocessor%29\nStock = 2261 khash/s\n4-way = 1103 khash/s (64 bit)\nPentium 4 - 3.0GHz (hyper-threading off) 1MB Cache, FSB 800MHz\nProcessor info: http://en.wikipedia.org/wiki/NetBurst_%28microarchitecture%29\nStock = 1024 khash/s (32 bit)\n4-way = 658 khash/s (32 bit)\nPentium 4 - 2.8GHz (hyper-threading off) 1MB Cache, FSB 800MHz\nProcessor info: http://en.wikipedia.org/wiki/NetBurst_%28microarchitecture%29\nStock = 917 khash/s (64 bit)\n4-way = 747 khash/s (64 bit)\nIf I didn't know better, I would say the key is the CPU cache size. Seems all the CPU that run slower have 2 MB or less onboard cache, where as the Core i5 starts with at least 3MB of onboard CPU cache.",
		"a": "I hope someone can test an i5 or AMD to check that I built it right. I don't have either to test with.\nI'm also curious if it performs much worse on 32-bit linux vs 64-bit."
	},
	{
		"id": 437,
		"type": "ignore",
		"date": "2010-08-15 18:43:27",
		"src": "https://bitcointalk.org/index.php?topic=820.msg9483#msg9483",
		"q": "Where is the code for this? I'm on a CentOS 5.5 box and need to build it myself. Once I do that I will report back with linux 32-bit and 1MB cache Xeon.",
		"a": "I just uploaded a quick build so testers can check if I built it right. (I don't have an i5 or AMD) If it checks out, I'll put together the full package and do all the release stuff."
	},
	{
		"id": 438,
		"type": "ignore",
		"date": "2010-08-15 20:59:09",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9530#msg9530",
		"q": "Or the same patch from your github, http://gist.github.com/525921 which gives us the raw patch that can be applied directly,\nhttp://gist.github.com/raw/525921/fe2ad7583f0dd2444caa0b3e24d750bf45cac11b/Quick%20fix%20block%2074652\nI was unable to patch directly using this, perhaps CRLF problems.\nI applied your changes manually, and uploaded the result here: http://yyz.us/bitcoin/patch.bitcoin-gavin-overflow-quick-fix",
		"a": "Here's the preliminary change. Look right? I have more changes to make, this isn't all of it. Will SVN shortly.\nbool CheckTransaction() const\n{\n// Basic checks that don't depend on any context\nif (vin.empty() || vout.empty())\nreturn error(\"CTransaction::CheckTransaction() : vin or vout empty\");\n// Check for negative and overflow values\nint64 nTotal = 0;\nforeach(const CTxOut& txout, vout)\n{\nif (txout.nValue < 0)\nreturn error(\"CTransaction::CheckTransaction() : txout.nValue negative\");\nif (txout.nValue > 21000000 * COIN)\nreturn error(\"CTransaction::CheckTransaction() : txout.nValue too high\");\nnTotal += txout.nValue;\nif (nTotal > 21000000 * COIN)\nreturn error(\"CTransaction::CheckTransaction() : txout total too high\");\n}\nif (IsCoinBase())\n{\nif (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)\nreturn error(\"CTransaction::CheckTransaction() : coinbase script size\");\n}\nelse\n{\nforeach(const CTxIn& txin, vin)\nif (txin.prevout.IsNull())\nreturn error(\"CTransaction::CheckTransaction() : prevout is null\");\n}\nreturn true;\n}\nDon't sticky the topic, nobody looks up there. There'll be enough posts to bump."
	},
	{
		"id": 439,
		"date": "2010-08-15 21:23:55",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9539#msg9539",
		"q": "Or just a quick re-verification of all blocks. After all, it is 5x faster than it used t be.",
		"a": "Once you have an update, you could download knightmb's block chain. You'll want one that's old enough that it ends before block 74000 so the most recent security lockin will check it. Can someone find the link for that?"
	},
	{
		"id": 440,
		"date": "2010-08-15 21:40:19",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9548#msg9548",
		"q": "It means replacing files in the bitcoin data directory. It is not recommended, unless you know what you're doing.\nEasiest and safest way is to backup wallet.dat then redownload everything.",
		"a": "Patch is uploaded to SVN rev 132!\nFor now, recommended steps:\n1) Shut down.\n2) Download knightmb's blk files. (replace your blk0001.dat and blkindex.dat files)\n3) Upgrade.\n4) It should start out with less than 74000 blocks. Let it redownload the rest.\nIf you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once.\nI'll build releases shortly."
	},
	{
		"id": 441,
		"type": "ignore",
		"date": "2010-08-15 22:58:08",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9573#msg9573",
		"q": "He didn't, he said \"you'll want one\", not that it needs to be, a little different.\nand if \"..Only the blocks including and after the invalid block are invalid. All previous blocks are valid..\", it doesn't need to be before 74000.\njust wanted to save knightmb some time, but yours is bigger than mine anyway.",
		"a": "Don't update the block chain download. When you take someone's block chain download, you don't want it right up to the end. A somewhat old one is better so it can download and verify the most recent blocks.\ntcatm's 4-way SSE2 SHA-256 is in the file sha256.cpp and already uploaded a few revs ago.\nI just now uploaded rev 134 which is the makefile.unix that enables building with it on Linux. If you build rev 134 on Linux now you'll get the -4way switch.\nIf you have problems building because of it, then edit makefile.unix and:\n- remove -DFOURWAYSSE2\n- remove obj/sha256.o from the end of these lines:\nbitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o\nbitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o\nThe 0.3.10 linux build will have the -4way option when I build it.\nHere are the patch downloads for Windows:\nhttp://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe\nhttp://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip\nSHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe\nSHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip\n1) Shut down.\n2) Download knightmb's blk files and replace your blk0001.dat and blkindex.dat files.\nhttp://knightmb.dyndns.org/files/bitcoin/blocks/\nhttp://rapidshare.com/files/413168038/BitcoinBlocks.torrent\n3) Upgrade to 0.3.10.\n4) It should start out with less than 74000 blocks and redownload the rest.\nOr if you don't want to mess with downloading blk files, you can just do this:\n1) Shut down.\n2) Delete (or move) blk*.dat\n3) Upgrade to 0.3.10.\n4) It redownloads all blocks, probably take about an hour."
	},
	{
		"id": 442,
		"date": "2010-08-15 23:17:24",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9576#msg9576",
		"q": "Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain.",
		"a": "Just leave the old one alone! Older is better. What block number is it? Anywhere from 60000-74000 is good. The one that you've had available for a while has been vetted and is the best choice."
	},
	{
		"id": 443,
		"type": "ignore",
		"date": "2010-08-15 23:36:10",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9584#msg9584",
		"q": "Cool, works for me!",
		"a": "Starting at 67000 is perfect.\nYeah, at the moment you'll stop at 74638. It should start slowly creeping up as more nodes upgrade and generate.\nLinux build links below.\nThe Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5 and AMD CPU's. Use the \"-4way\" switch to enable it and check if it's faster for you.\nDownload links:\nhttp://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe\nhttp://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip\nhttp://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz\nSHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe\nSHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip\nSHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz"
	},
	{
		"id": 444,
		"date": "2010-08-15 23:37:07",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9586#msg9586",
		"q": "I think that you should add something about this: http://bitcointalk.org/index.php?topic=259.0\nThere must be a label on the client that show a warning message if needed\nNow everyone have always to check the website, and I think that this is bad.",
		"a": "Agree, wanted to do that for a long time, haven't had time to do it.\nFor now, you could also subscribe to the bitcoin-list mailing list. It rarely gets used except for announcements like this and major new versions.\nSubscribe/unsubscribe page:\nhttp://lists.sourceforge.net/mailman/listinfo/bitcoin-list"
	},
	{
		"id": 445,
		"date": "2010-08-16 00:28:28",
		"src": "https://bitcointalk.org/index.php?topic=828.msg9608#msg9608",
		"q": "There are 74643 blocks as I write this. The split is causing some network problems. You should connect your computers to each other with the addnode parameter.",
		"a": "I suspect there's some difficulty receiving blocks if all the nodes you're connected to are 0.3.9 or lower. We need enough of us so that at least one node you connect to will be 0.3.10. The problem will start to go away when we make up more than 1/8th of the network.\nIt'll help if you port forward so you can get lots of connections."
	},
	{
		"id": 446,
		"date": "2010-08-16 01:00:45",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9623#msg9623",
		"q": "Question about fallout: I had a transaction that I submitted after the bad block, using the bad block chain.\nWhat is the status of that transaction?\nFrom what I can tell, my (updated) sending client wallet shows the deducted amount.\nWill it get reincorporated into the fixed chain, and will the recipient be able to spend it?",
		"a": "Right, it will get reincorporated into the fixed chain. The transaction won't disappear, it'll still be visible on both sides, but the confirmation count will jump back to 0 and start counting up again.\nIt's only if you generated a block in the bad chain after block 74638 that the 50 BTC from that will disappear. Any blocks in the bad chain wouldn't have matured yet."
	},
	{
		"id": 447,
		"date": "2010-08-16 01:02:24",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9624#msg9624",
		"q": "I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine?",
		"a": "If you still show 74638 blocks then you aren't connected to any 0.3.10 nodes.\nFor today, try adding these parameters:\n-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14\nSee\nhttp://bitcointalk.org/index.php?topic=828"
	},
	{
		"id": 448,
		"date": "2010-08-16 01:12:05",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9628#msg9628",
		"q": "Most people running clients are not reading this message thread. So... Silly questions:\n1) How will this continue to affect version 3.8.1 (pre-catastrophe) clients with bad block chain?\n2) How will this affect clients that upgrade to 3.8.10 but don't remove their block chain files?",
		"a": "1) Once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations.\n2) If you didn't remove your blk*.dat files, you're not helping to contribute to that 50%, and you'll still show bad transactions until the good chain overtakes the bad chain."
	},
	{
		"id": 449,
		"date": "2010-08-16 02:16:10",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9642#msg9642",
		"q": "Of course, this happened right after the difficulty kicked up to 511.7, so all these new \"good\" blocks will have to contend with that. And a good chunk of the network grind power is off on the wrong chain, so new blocks may take a lot longer than 10min to find. At what point will the balancing figure this out and possibly kick the difficulty back down again?",
		"a": "The bad chain is also slowed down as more nodes upgrade.\nWe've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are already 0.3.10. I would say we probably already have more power than the bad chain."
	},
	{
		"id": 450,
		"type": "ignore",
		"date": "2010-08-16 02:38:21",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9648#msg9648",
		"q": "That's great news! How did you figure that out, though? I was considering writing a client specially tailored to put itself out there and try to get as many people to connect as possible, then survey their versions and write out a log (in addition to all the normal bitcoin stuff).",
		"a": "On Windows, findstr /c:\"version message\" debug.log\nIt looks like the bad chain was on block 74678 recently. Can't wait to overtake it.\nOn the stats at http://nullvoid.org/bitcoin/statistix.php there's been 5 blocks per hour in the last 3 hours. We had a difficulty adjustment about a day ago that should have put it back to 6 blocks per hour."
	},
	{
		"id": 451,
		"type": "ignore",
		"date": "2010-08-16 02:57:57",
		"src": "https://bitcointalk.org/index.php?topic=820.msg9655#msg9655",
		"q": "I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.",
		"a": "GCC 4.3.3 doesn't support -march=amdfamk10. I get:\nsha256.cpp:1: error: bad value (amdfamk10) for -march= switch"
	},
	{
		"id": 452,
		"type": "ignore",
		"date": "2010-08-16 02:57:57",
		"src": "https://bitcointalk.org/index.php?topic=820.msg9655#msg9655",
		"q": "With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way.",
		"a": "Hey, you may be onto something!\nhyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.\ntcatm's SSE2 code must be a mix of normal x86 instructions and SSE2 instructions, so while one is doing x86 code, the other can do SSE2.\nHow much of an improvement do you get with hyperthreading?\nSome numbers? What CPU is that?"
	},
	{
		"id": 453,
		"date": "2010-08-16 03:23:04",
		"src": "https://bitcointalk.org/index.php?topic=820.msg9661#msg9661",
		"q": "try -march=amdfam10",
		"a": "That works.\nThat's strange... are we sure that's the same thing? tcatm, try amdfam10 and make sure you get the same speed measurement."
	},
	{
		"id": 454,
		"date": "2010-08-16 04:36:59",
		"src": "https://bitcointalk.org/index.php?topic=820.msg9676#msg9676",
		"q": "cpu family : 6\nmodel : 26\nmodel name : Genuine Intel(R) CPU 000 @ 3.20GHz\nstepping : 4",
		"a": "cpu family 6 model 26 stepping 4 is an Intel Core i7.\nThat's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading.\n33% faster with hyperthreading than without it."
	},
	{
		"id": 455,
		"date": "2010-08-16 12:59:38",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9734#msg9734",
		"q": "Interesting.. fascinating to watch this work its way through the bowels of the system.\nIt was block 73746 that I generated.\nCTxOut(nValue=50.00000000, scriptPubKey=0x8DDD5C7DADB2D43AC5F186)\n08/12/10 02:35 generated 50.00\nAnd I sent 49.00 of it to 19Nzg21hQQDAY5GTdTTuUVPA4MaE7AusXz (using the broken chain)\nNow I'm waiting for that node to figure out it was received, and it's using the new chain.",
		"a": "It looks like we overtook the bad chain somewhere around 74689. 0.3.9 and lower nodes have been responding with the current block number for some hours now.\nThat means it's no longer necessary to delete blk*.dat before upgrading. You can just upgrade and it'll reorg away the bad block chain.\nThanks to everyone for the quick response!"
	},
	{
		"id": 456,
		"type": "ignore",
		"date": "2010-08-16 13:38:01",
		"src": "https://bitcointalk.org/index.php?topic=820.msg9736#msg9736",
		"q": "On a Core 2 Duo T7200, the default code gives about 1.8 Mhash/s, and 4way is slower at 1.0 Mhash/s. It has 4 MB of L2 cache, so it is probably not a question of cache size, as suggested at some point.\nUnfortunately, the code (from svn) no longer compiles on ARM, as it now has SSE intrinsics hardcoded. I have removed the -msse2 and -DFOURWAYSSE2 flags from the makefile, and it still produces errors like this\nsha256.cpp:8:23: error: xmmintrin.h: No such file or directory\nsha256.cpp:34: error: __m128i does not name a type\nbut hopefully this is easy to fix.",
		"a": "I wrapped sha256.cpp in\n#ifdef FOURWAYSSE2\n#endif // FOURWAYSSE2\ntry it now."
	},
	{
		"id": 457,
		"type": "ignore",
		"date": "2010-08-16 15:25:54",
		"src": "https://bitcointalk.org/index.php?topic=832.msg9754#msg9754",
		"q": "Hmm, it seems I am missing something important - disconnecting transactions which are no longer part of the accepted block chain. I'm going to have to work on this a bit - the naive approach of simply blasting away all TXNs, then reconnecting things is far too slow, and hits the transaction memory limit.",
		"a": "That's a difficult approach.\nWe need to cause a reorg, which will disconnect the invalid chain.\nThis is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best.\nHere's what I was thinking of. (I haven't tested this yet) It checks all the blocks in the main chain. If it finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg. (It can't change pindexBest without actually doing a reorg)\nThis isn't perfect yet. It still needs to receive one valid block to trigger the reorg.\nIt would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below.\nbool CTxDB::LoadBlockIndex()\n{\n...\n// Verify blocks in the main chain\nvector<CBlockIndex*> vChain;\nfor (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)\n{\nvChain.push_back(pindex);\nCBlock block;\nif (!block.ReadFromDisk(pindex))\nreturn error(\"LoadBlockIndex() : block.ReadFromDisk failed\");\nif (!block.CheckBlock())\n{\nbnBestChainWork = pindex->pprev->bnChainWork;\nforeach(CBlockIndex* pindex2, vChain)\npindex2->bnChainWork = 0;\n}\n}\nreturn true;\n}"
	},
	{
		"id": 458,
		"type": "ignore",
		"date": "2010-08-16 17:06:27",
		"src": "https://bitcointalk.org/index.php?topic=837.msg9774#msg9774",
		"q": "+1",
		"a": "Done in SVN rev 137"
	},
	{
		"id": 459,
		"date": "2010-08-16 17:08:02",
		"src": "https://bitcointalk.org/index.php?topic=832.msg9775#msg9775",
		"q": "It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below.",
		"a": "This is what I ended up doing in SVN rev 139.\nInstead of deleting the bad chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back into the best chain once they're kicked out."
	},
	{
		"id": 460,
		"date": "2010-08-16 20:20:53",
		"src": "https://bitcointalk.org/index.php?topic=834.msg9816#msg9816",
		"q": "What is a bad chain?\nCould you elaborate more on why checkpoints are bad?",
		"a": "There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work. In the design it was necessary for it to switch to a longer chain no matter how far back it has to go.\nThe only exception to that is the manual checkpoints I've added. If it weren't for those, it would be able to reorg all the way back to the first block."
	},
	{
		"id": 461,
		"date": "2010-08-16 22:54:55",
		"src": "https://bitcointalk.org/index.php?topic=823.msg9841#msg9841",
		"q": "Yes. The only exception would be if an unpatched client made another fake transaction and managed to verify it. They would be able to spread that fake block to a few other nodes that haven't upgraded, but the upgraded clients seem to have more power than the unpatched clients, so the bad link would not last long and would not be spread by upgraded clients.",
		"a": "Un-upgraded nodes have the correct chain most of the time, but they are still trying to include the overflow transaction in every block, so they're continually trying to fork and generate invalid blocks. If an old version node is restarted, its transaction pool is emptied, so it may generate valid blocks for a while until the transaction gets broadcast again. 0.3.9 and lower nodes still must upgrade.\nThe SVN now has the code we needed to automatically reorg the block chain without having to delete the blk*.dat files manually. I knew I couldn't write that code fast and carefully enough yesterday, so I went with the quick manual option."
	},
	{
		"id": 462,
		"date": "2010-08-16 23:01:48",
		"src": "https://bitcointalk.org/index.php?topic=834.msg9843#msg9843",
		"q": "How is the strength of the chain calculated?",
		"a": "Total proof-of-work."
	},
	{
		"id": 463,
		"type": "ignore",
		"date": "2010-08-18 16:58:44",
		"src": "https://bitcointalk.org/index.php?topic=850.msg10067#msg10067",
		"q": "Better than XP",
		"a": "Definitely. The old screenshots of 0.1 are very outdated.\nWindows Aero is a good choice. Windows is still the largest user group. Mind what's behind it for the transparent parts.\nWhat to have displayed in the transaction list? Not completely filled up with stuff, just a few things."
	},
	{
		"id": 464,
		"type": "ignore",
		"date": "2010-08-18 18:01:40",
		"src": "https://bitcointalk.org/index.php?topic=846.msg10076#msg10076",
		"q": "Yes, but there are two points that you overlooked. First, the software transceiver ususally requires four of these chips. (two for receive and two for transmit, one does digital signal processing and the other does digital filtering of the raw signal. Said another way, one is the virtual mike/speaker and the other is a virtual tuner. Not all such software radio setups need four, however) So if a ham has four of these, all four could be programmed to this end. The other point is one that I didn't explicitly mention, one FPGA does not equal only one sha-256 processor. It is possible, even likely, that more than one such processor could be programmed into a single FPGA chip. These chips are fairly large so that they can 'virtualize' some pretty complex logic circuts, and a talented programmer could program one chip to be several sha-256 processors running in parrallel. All this, and his main CPU and GPU are still available if still more Kh/s are desired. Any hacker with the skills to program one or more GPU's in the same system to crunch hashes is already elite, and doing multiple sha-256 cores on a single FPGA would be child's play. And we already know that there is some elite talent within the Bitcoin community, some who desire to run it, and some who desire to break it.",
		"a": "The performance numbers posted from a VIA C7's hardware SHA-256 weren't astronomical. Only in the 1500 khash/s range. If you think about it, just because it's implemented in hardware doesn't mean it's crazy fast. It still has to do all the steps. It's only if simplifying it down to single-purpose hardware makes it small enough to fit many in parallel. That's not necessarily easy or a given."
	},
	{
		"id": 465,
		"date": "2010-08-18 18:28:28",
		"src": "https://bitcointalk.org/index.php?topic=841.msg10082#msg10082",
		"q": "I assume it will take more than 1 second to do.\nDo we have to do this every time it starts up\nCan we make a menu option for it, to fire it off manually?\nAnd make a counter so that it reminds you to check every n loads/days.\nor whenever you update the software.\nIt just seems that needing to recheck the entire block chain will be a very rare event, so rechecking the block chain all the time is overkill.",
		"a": "In the next SVN rev, I'll make it only go back to the last checkpoint at block 74000. If we need to correct a problem in the future, we can always make sure it goes back at least as far back as the problem. Also, I'm adding code to verify the block index, which means the proof-of-work chain is checked.\nStill, the system won't be entirely secure against your blk*.dat files. You are trusting someone if you use a copy of their blk files."
	},
	{
		"id": 466,
		"type": "ignore",
		"date": "2010-08-19 18:44:36",
		"src": "https://bitcointalk.org/index.php?topic=867.msg10272#msg10272",
		"q": "WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.",
		"a": "wxWidgets 2.9 is their first UTF-8 version. We are UTF-8 on all platforms including Windows.\nThe distro packages of 2.8 are UTF-16, so they just trip people up. People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9. Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8.\nThis is a problem that will solve itself. With time, 2.9 will become a more mainline release."
	},
	{
		"id": 467,
		"date": "2010-08-19 18:55:48",
		"src": "https://bitcointalk.org/index.php?topic=868.msg10275#msg10275",
		"q": "An excellent guide. Thank you so much for your efforts - it will certainly help me",
		"a": "That's a really well written walkthough. Someone should confirm if they followed it and didn't run into any snags."
	},
	{
		"id": 468,
		"type": "ignore",
		"date": "2010-08-19 19:07:43",
		"src": "https://bitcointalk.org/index.php?topic=820.msg10281#msg10281",
		"q": "Any non-Mac i5 love?\nWindows i5 64-bit got slower here.",
		"a": "That's the first I've heard anyone say i5 was slower. Everyone else has said 4way was faster on i5. Moreso with hyperthreading enabled."
	},
	{
		"id": 469,
		"type": "ignore",
		"date": "2010-08-19 19:07:43",
		"src": "https://bitcointalk.org/index.php?topic=820.msg10281#msg10281",
		"q": "And i5, at least on my macbookpro",
		"a": "Good, so I take it that's a confirmation that it's working on Mac as well?\nLaszlo told me he did compile in the -4way stuff on Mac, so the -4way switch is also available to try on Mac. I don't think makefile.osx on SVN has it yet, just the built version."
	},
	{
		"id": 470,
		"type": "ignore",
		"date": "2010-08-19 19:40:30",
		"src": "https://bitcointalk.org/index.php?topic=862.msg10290#msg10290",
		"q": "Yeah, I'm having similar results. I've been running a self-compiled Linux build on a machine with roughly the same khash and haven't generated a block since mid July. Of course, it was a _broken_ Linux build for a few weeks of that, but I'm running the latest SVN version now and still no luck.",
		"a": "Make sure your computer's date and time are correct."
	},
	{
		"id": 471,
		"date": "2010-08-19 20:28:50",
		"src": "https://bitcointalk.org/index.php?topic=870.msg10300#msg10300",
		"q": "I think not. I think that when a client considers a block bad it gets the transactions that were in it and rebroadcasts them or puts them in a block themselves.",
		"a": "That's right. You don't need to be re-broadcasting your transactions for it to work.\nWhen any node disconnects a fork, it dumps all the transactions from the fork back into the transaction pool to add to the new chain. The entire network is making sure to re-integrate your transactions again. All you should see is that your number of confirmations starts over from 0.\nIn some types of forks, your transaction would have gotten into both forks already, so you're already good either way."
	},
	{
		"id": 472,
		"type": "ignore",
		"date": "2010-08-22 22:51:00",
		"src": "https://bitcointalk.org/index.php?topic=873.msg10715#msg10715",
		"q": "mizeryderia, you just copied and pasted satoshis post without adding any value.\nYou could have tried to address the points he raised, or at least put up a note explaining why this page was on the wiki and what you wanted people to do with it.",
		"a": "The clock part will be covered in the next release (0.3.11 or higher). SVN rev 141 pops up a message box if your clock is too far off."
	},
	{
		"id": 473,
		"date": "2010-08-22 23:01:02",
		"src": "https://bitcointalk.org/index.php?topic=862.msg10717#msg10717",
		"q": "My computer have date and time correct.\nI uninstalled bitcoin, i deleted absolutely all files, blocks, debug, ALL, except of course wallet.dat.\nAnd a reinstalled, i hope this can be works.\nA question, can be wallet.dat, make any problem??",
		"a": "Search debug.log for \"proof-of-work found\". If you find any, then check for any errors right after that."
	},
	{
		"id": 474,
		"date": "2010-08-22 23:01:02",
		"src": "https://bitcointalk.org/index.php?topic=862.msg10717#msg10717",
		"q": "How big of a margin on the time is allowed for things to work right.",
		"a": "The margin is 2 hours.\nThis should be solved in SVN rev 141 and the next release (0.3.11+). It'll pop up a message box alerting you if your clock is off by more than an hour."
	},
	{
		"id": 475,
		"type": "ignore",
		"date": "2010-08-22 23:21:50",
		"src": "https://bitcointalk.org/index.php?topic=820.msg10720#msg10720",
		"q": "The difference between new and older CPUs is pretty easy to explain.\nOlder microarchitectures have 64-bit mmx/sse execution units and split 128bit sse ops into 2 64bit microops.\nNewer archs have 128bit sse units.\nAMD K8: 2 64bit unitsintel Core/Core2: 3 64bit unitsAMD K10: 2 128bit unitsintel nehalem: 3 128bit unitsK10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II\nnehalem = xeon 34xx/35xx/36xx/55xx/56xx/65xx/75xx, i3/i5/i7",
		"a": "Thanks for clearing that up. I read the link someone posted about AMD making that change around 2007, but I didn't know what the story was for Intel.\nThere's no hope for Core/Core2 then. They only have half the SSE2 hardware.\nStrange that Intel has 3 128bit units, but AMD with 2 128bit units is the faster one."
	},
	{
		"id": 476,
		"date": "2010-08-22 23:57:32",
		"src": "https://bitcointalk.org/index.php?topic=890.msg10723#msg10723",
		"q": "I just posted this note over on the Trade forum:\nhttp://bitcointalk.org/index.php?topic=30.msg10592#msg10592\nThere are a few hackers who would be pretty interested in contributing patches to integrate BitCoin payments directly into the Tahoe-LAFS storage protocol. It would be a big job! It would probably take a year of effort before we would be ready to deploy it in a new stable release. Of course, the more people pitch in the faster the work goes.\nZooko\ncommunity organizer, Tahoe-LAFS project",
		"a": "Hey Zooko!\nI wanted to thank you for posting about Bitcoin on your blog a year or two ago, back when I announced it on the Cryptography mailing list."
	},
	{
		"id": 477,
		"type": "ignore",
		"date": "2010-08-24 22:43:56",
		"src": "https://bitcointalk.org/index.php?topic=820.msg11068#msg11068",
		"q": "AMD K10: 2 128bit unitsintel nehalem: 3 128bit units",
		"a": "This probably explains why hyperthreading increases performance with -4way. If three SSE2 units is excessive, then hyperthreading would help keep them all busy."
	},
	{
		"id": 478,
		"date": "2010-08-24 23:51:12",
		"src": "https://bitcointalk.org/index.php?topic=898.msg11074#msg11074",
		"q": "There should be a --disable-alerts switch.",
		"a": "If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.\nI think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do. If you decide it's a false alarm and want to take your chances, you can use the \"-disablesafemode\" switch."
	},
	{
		"id": 479,
		"type": "ignore",
		"date": "2010-08-25 15:17:37",
		"src": "https://bitcointalk.org/index.php?topic=898.msg11150#msg11150",
		"q": "That's not the point, if I'm diligent enough to change a source code I'm also diligent enough to apply a -disablesafety switch which is much easier, the issue here is default behavior of the official client. Many people are going to just notice there is a new version, download and install it never realizing this new remote control was inserted there.\nSaying that they can examine the source code or that it was openly discussed on the forum is like Facebook saying \"but we have an option to delete your account, it's in terms of service, section 76, line 346, under link named so-appalling-that-nobody-would-ever-click-it, then on page 2, just solve the capcha, confirm the dialog, that will disable your account and if you do not log in in a week it will be deleted\". In short ... nobody actually does it ... that's how badware behaves and I do not want for Bitcoin to be badware.\nIf there is a remote safety disable function every user who has it enabled should consciously enable it knowing what it does. This can be easily accomplished by presenting a dialog urging user to enable it while explaining what it does in a GUI client and presenting a warning accomplishing the same task when daemon is run. Simple, efficient and everybody is happy. That's how software that respects its users and is working for them should behave. I'm sure most people would enable it when understanding what it does ... but sneaking this feature in without making sure the user specifically wants it there is making decisions for the user, I do not like decisions being made for me\nI'm aware of this because I read the forums but what in the future? (And what about people who do not read forums) Will there be another \"feature\" inserted and I'm not going to be even notified, explained what it does and asked if I want it enabled? I do not like that if you ask me ... I want to know what software on my CPU does, if it doesn't make reasonable effort to inform me of that and assure that I'm aware of it's behavior I would consider it badware.\nThat's at least my perspective ... and the fix is extremely easy",
		"a": "It can't do arbitrary actions remotely. Maybe some of you are responding to other posters who suggested the alert system should do more?\nIf there is an alert, the following json-rpc methods return an error:\nsendtoaddress\ngetbalance\ngetreceivedbyaddress\ngetreceivedbylabel\nlistreceivedbyaddress\nlistreceivedbylabel\nThe remaining 14 methods function as normal.\nI believe the safer option should be enabled by default. If you want your server to keep trading and ignore an alert saying the money its receiving might be like the money from the overflow bug, then you can use the switch and not blame anyone else if you lose your money.\nWorst case if you leave alerts enabled, your site stops trading until you upgrade or add the -disablesafemode switch.\nGetting surprised by some temporary down time when your node would otherwise be at risk is better than getting surprised by a thief draining all your inventory.\nSomeday when we haven't found any new bugs for a long time and it has been thoroughly security reviewed without finding anything, this can be scaled back. I'm not arguing that this is the permanent way of things forever. It's still beta software."
	},
	{
		"id": 480,
		"date": "2010-08-25 16:56:15",
		"src": "https://bitcointalk.org/index.php?topic=898.msg11155#msg11155",
		"q": "A few rhetorical questions for satoshi:\nCan you resist waterboarding?\nCan you endure electric shock?\nAll forms of torture?\nLastly, are you Jack Bauer by any chance? Seriously.",
		"a": "WRT the alert system, who cares? The most the key can do is temporarily disable six json-rpc commands until the site owners either add the -disablesafemode switch or upgrade. All nodes keep running and generating, the network stays up. If I'm not available, any script kiddie can figure out how to add two characters and make a new version that disables the alert system. It would be a temporary inconvenience only."
	},
	{
		"id": 481,
		"date": "2010-08-25 16:56:15",
		"src": "https://bitcointalk.org/index.php?topic=898.msg11155#msg11155",
		"q": "So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand\nthat he hands over his key (or get it from his computer) and shut down the complete network?",
		"a": "This is what makes me think the people objecting don't know what they're talking about. It can't \"shut down the complete network\"."
	},
	{
		"id": 482,
		"type": "ignore",
		"date": "2010-08-25 17:59:30",
		"src": "https://bitcointalk.org/index.php?topic=898.msg11158#msg11158",
		"q": "So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?",
		"a": "getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.\nThe rpc methods return a json-rpc error with the error description \"Safe mode: \" followed by additional text specified by the alert.\nI added the switch \"-testsafemode\" for you. SVN rev 145.\nThis stuff is very new and may still be subject to change."
	},
	{
		"id": 483,
		"type": "ignore",
		"date": "2010-08-25 17:59:30",
		"src": "https://bitcointalk.org/index.php?topic=898.msg11158#msg11158",
		"q": "I just discovered http://www.bitcoin.org/wiki/doku.php?id=man_page and don't see any reference to -disablesafemode. Perhaps it should be added! Also others liek -4way should be added as well.",
		"a": "Many switches are intentionally undocumented, like if their functionality is still under construction or I haven't settled on their name yet, or just test code not intended for release.\n-4way should eventually be replaced by an auto-detect."
	},
	{
		"id": 484,
		"date": "2010-08-26 00:08:12",
		"src": "https://bitcointalk.org/index.php?topic=898.msg11219#msg11219",
		"q": "I've never objected this change/idea, just asking if this was possible and to what extent.\nWhat's wrong with getting informed?",
		"a": "My apologies, your post was indeed a question not a statement."
	},
	{
		"id": 485,
		"type": "ignore",
		"date": "2010-08-26 00:33:28",
		"src": "https://bitcointalk.org/index.php?topic=920.msg11224#msg11224",
		"q": "Wallet backups and other DB examination are easily possible in a safe, atomic, transactional fashion... if and only if DB_PRIVATE flag is removed.\n--- a/db.cpp\n+++ b/db.cpp\n@@ -77,7 +77,6 @@ CDB::CDB(const char* pszFile, const char* pszMode) : pdb(NULL)\nDB_INIT_MPOOL |\nDB_INIT_TXN |\nDB_THREAD |\n- DB_PRIVATE |\nDB_RECOVER,\nS_IRUSR | S_IWUSR);\nWhat, if any, problems arise from doing this? Obviously, this does not cover the non-db4 databases such as the block data file.",
		"a": "Can you provide more details about what removing DB_PRIVATE does?\nI can't remember if I had a specific reason for DB_PRIVATE, or if I just copied the flags from some example code. Does removing DB_PRIVATE make it safe for other processes to open the database simultaneously? That may be an improvement, depending what the side effects are. Does it substantially reduce performance by making it have to write out every change immediately or do other coordination? Are there additional locking or coordination files then? What else changes? You could test by timing an initial block download with and without DB_PRIVATE, preferably -connect-ing to a local machine so network isn't a factor.\nApparently, DB_PRIVATE doesn't do what you would hope it would do, which is prevent other processes from being able to open the database. It still lets them, it just screws up if they do. Another option, if there's a way, would be to make it lock the database files so they can't be accessed by other processes."
	},
	{
		"id": 486,
		"date": "2010-08-26 00:44:05",
		"src": "https://bitcointalk.org/index.php?topic=873.msg11227#msg11227",
		"q": "Instead of introducing a warning or establishing a precedence of caution and delay in handling wallet file or backups, as I suggested above, the implementation for backing up data/wallet file needs more thought/establishment.\nI am not familiar with the current process/structure of data flow that occurs, but if someone could write up or draw a diagram or something that shows how the flow of data appears then perhaps with this diagram-liek information, others, like myself, can help to understand how things work and maybe offer suggestions for improvements or to recognize things like after which data sent/received is worthy of implementing a kind of automated/triggered backup or similar action.\nsee http://bitcointalk.org/index.php?topic=921.0 for continued discussion about backups",
		"a": "Any backup process/procedure would just be a stopgap until there's time to properly work on coding solutions in software. We can try to use words to help the situation until code gets there.\nThe main backup improvement will be pre-made pool of keys, and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time."
	},
	{
		"id": 487,
		"date": "2010-08-26 00:57:40",
		"src": "https://bitcointalk.org/index.php?topic=921.msg11228#msg11228",
		"q": "http://bitcointalk.org/index.php?topic=873.msg10728#msg10728 is somewhat related",
		"a": "I started posting in the other topic but I'll repeat here, this thread seems more specific to the topic.\nThe main backup improvement will be a pre-generated pool of keys and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time.\nI was starting to post the same idea you said nelisky.\nHow about a json-rpc command that locks the wallet, flushes it, copies wallet.dat to a location you specified, then unlocks it? That would be a smaller project than the pooled keys, so maybe it could be done first.\nWhat's the simplest portable way to copy a file? Is there something in Boost?\nWhat should it be named? maybe:\nbackupwallet <destination>"
	},
	{
		"id": 488,
		"type": "ignore",
		"date": "2010-08-27 00:49:43",
		"src": "https://bitcointalk.org/index.php?topic=930.msg11342#msg11342",
		"q": "outdated\nCome to #bitcoin-gentoo on Freenode for latest",
		"a": "Try -datadir=\nLast time I tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it. There wasn't time to investigate at the time.\nOne problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there. -lwx_gtk2ud-2.9 only matches the right configuration. It fails if wxWidgets was built with the wrong configuration."
	},
	{
		"id": 489,
		"type": "ignore",
		"date": "2010-08-27 00:49:43",
		"src": "https://bitcointalk.org/index.php?topic=930.msg11342#msg11342",
		"q": "Iirc, chatting in #wxwidgets on freenode, the devs there were baffled why that was used.",
		"a": "Did they say why they were baffled?"
	},
	{
		"id": 490,
		"type": "ignore",
		"date": "2010-08-27 00:49:43",
		"src": "https://bitcointalk.org/index.php?topic=930.msg11342#msg11342",
		"q": "This is because on my system the path is /usr/include/wx-2.9/wx/wx.h",
		"a": "Why is it there? Was it included by the OS, or did you have to build it? If you built it, I wonder why it would put itself in a different place.\nHas wxWidgets 2.9 finally started to become available as a debian package?\nMaybe we should do this:\nINCLUDEPATHS= \\\n-I\"/usr/local/include/wx-2.9\" \\\n-I\"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9\" \\\n-I\"/usr/include/wx-2.9\" \\\n-I\"/usr/lib/wx/include/gtk2-unicode-debug-static-2.9\"\nAgain, those paths help make sure it's only 2.9 and will fail with 2.8.\nwxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us. It's tempting because it's so easily available as a package; a lot of people were frustrated by it until we started hardcoding 2.9 into the makefile."
	},
	{
		"id": 491,
		"type": "ignore",
		"date": "2010-08-27 01:13:42",
		"src": "https://bitcointalk.org/index.php?topic=921.msg11345#msg11345",
		"q": "Sounds quite useful!",
		"a": "If you read it into memory and write it out, it could fail in tight memory situations.\nI'm looking for something like copyfile(const char* from, const char* to) or copyfile(path from, path to), preferably something in Boost if it has it. If you find it for me, it's more likely I'll get to implementing it."
	},
	{
		"id": 492,
		"type": "ignore",
		"date": "2010-08-27 01:13:42",
		"src": "https://bitcointalk.org/index.php?topic=921.msg11345#msg11345",
		"q": "As for the file copy, why add to the boost dependency? I for one would love to get a core lib with very little deps.",
		"a": "We require Boost for JSON and a dozen things replacing dependencies on wxWidgets. Boost is good, portable stuff, we should not shy away from it."
	},
	{
		"id": 493,
		"type": "ignore",
		"date": "2010-08-27 02:54:07",
		"src": "https://bitcointalk.org/index.php?topic=921.msg11350#msg11350",
		"q": "I think you misunderstand what mmap does? mmap / CreateFileMapping does not read a file into heap memory: http://en.wikipedia.org/wiki/Mmap",
		"a": "I doubt there's an mmap(2) on Windows. I'd rather call an existing file copy function than make and test my own."
	},
	{
		"id": 494,
		"type": "ignore",
		"date": "2010-08-27 02:54:07",
		"src": "https://bitcointalk.org/index.php?topic=921.msg11350#msg11350",
		"q": "But if you are already using features from boost::filesystem you can use copy_file from that. I just think that, if not already required for something else, it's a tad overkill.",
		"a": "Thanks. I thought it would be in there somewhere.\nWe already use boost::filesystem in a dozen places. It's not a new added dependency. It gives us a lot of portable stuff that we would otherwise have to have a #ifdef for each OS and test everywhere."
	},
	{
		"id": 495,
		"type": "ignore",
		"date": "2010-08-27 15:47:57",
		"src": "https://bitcointalk.org/index.php?topic=921.msg11399#msg11399",
		"q": "The Windows version of mmap was mentioned in the message to which you replied: CreateFileMapping\nIn my earlier message, I mentioned how to use this from boost: Boost::Iostreams already has a mapped_file Source.",
		"a": "Sorry, I've been so busy lately I've been skimming messages and I still can't keep up.\nWe want to avoid Windows API calls whenever possible. They usually take about 6-8 parameters and a lot of testing to get right, it takes a page of code to do something simple.\nI usually shy away from iostreams. Seems like I too often hit limitations. They kind of botched the C++ streams standard in the 90's, which is too bad, streams can be very powerful and useful when done right. Using it in rpc.cpp may still turn out to be a mistake.\nBottom line is I'd rather call an existing file copy function than make and test my own."
	},
	{
		"id": 496,
		"date": "2010-08-27 16:13:16",
		"src": "https://bitcointalk.org/index.php?topic=928.msg11400#msg11400",
		"q": "Superb! Thanks a lot.",
		"a": "That's kind of interesting as an upside-down bar chart of how many blocks were produced each day. The target is 144 blocks per day."
	},
	{
		"id": 497,
		"type": "favorite",
		"date": "2010-08-27 16:39:26",
		"src": "https://bitcointalk.org/index.php?topic=845.msg11403#msg11403",
		"q": "There has been a lot of debate about what Bitcoins are -- i.e. currency vs. commodity. Also there has been a lot of debate about inflation vs. deflation with respect to Bitcoins, whether people would lend them, at what rates, etc.\nI think the most apt description of Bitcoins is that they are shares of stock in this communal Bitcoin enterprise we are undertaking. It is a lot like being part of a company (right now a very small company) and being paid in stock shares. There are a fixed number of Bitcoins, as there are a fixed number of shares in a company (barring new issues/etc.).\nThe primary value of Bitcoins right now is the hope that they will someday be worth significantly more than they are right now. For that to happen, the Bitcoin enterprise as a whole needs to gain collective value. We, as employee/owners of Bitcoin need to generate that added value. The most obvious way is to facilitate internet commerce by bartering shares of Bitcoin for other goods. The collective computational effort of all the employee/owners helps ensure that the barter is fair by keeping a record of each transaction. The individual efforts of some Bitcoiners are helping to make the barter of Bitcoins easier or more useful.\nRegarding lending/borrowing of Bitcoins, to me it is analogous to lending/borrowing stock. The primary reason to borrow Bitcoins would be because you think they are overvalued and will be worth less when you have to return them. When you borrow the Bitcoins, you can sell them now (barter them now) and hopefully it will cost you less to buy them back at a later date so that you can return them to your lender (probably plus a fee).\nIn essence, Bitcoins are like a \"direct public offering\" of stock in the Bitcoin enterprise.",
		"a": "Bitcoins have no dividend or potential future dividend, therefore not like a stock.\nMore like a collectible or commodity."
	},
	{
		"id": 498,
		"type": "favorite",
		"date": "2010-08-27 17:32:07",
		"src": "https://bitcointalk.org/index.php?topic=583.msg11405#msg11405",
		"q": "This might just be semantics. But I'd say that the \"pre-existing value\" was the expectation of some people that it would be a good money.",
		"a": "As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:\n- boring grey in colour\n- not a good conductor of electricity\n- not particularly strong, but not ductile or easily malleable either\n- not useful for any practical or ornamental purpose\nand one special, magical property:\n- can be transported over a communications channel\nIf it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.\nMaybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it.\nI think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value. But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something.\n(I'm using the word scarce here to only mean limited potential supply)"
	},
	{
		"id": 499,
		"type": "ignore",
		"date": "2010-08-28 14:27:15",
		"src": "https://bitcointalk.org/index.php?topic=820.msg11503#msg11503",
		"q": "I just reviewed the sourcecode as I had a few ideas to optimize it further and I noticed that 4way is partly broken:\nfrom main.cpp:\nfor (int j = 0; j < NPAR; j++)\n{\nif (thash[7][j] == 0)\n{\nfor (int i = 0; i < sizeof(hash)/4; i++)\n((unsigned int*)&hash)[i] = thash[i][j];\npblock->nNonce = ByteReverse(tmp.block.nNonce + j);\n}\n}\nThe code will only process one hash (the last with thash[7] == 0) out of 32 hashes even when there is more than one hash that might be a correct one.\nSomethine like this should fix it but it won't be safe at higher difficulties. Also, I'm not sure whether the byte order should be reversed or not. Could someone review this?\nunsigned int min_hash = ~1;\nfor (int j = 0; j < NPAR; j++)\n{\nif (thash[7][j] == 0)\n{\nif(thash[6][j] < min_hash) {\nmin_hash = thash[6][j];\nfor (int i = 0; i < sizeof(hash)/4; i++)\n((unsigned int*)&hash)[i] = thash[i][j];\npblock->nNonce = ByteReverse(tmp.block.nNonce + j);\n}\n}\n}",
		"a": "The simplification is intentional. There will only be more than one thash[7]=0 in one out of 134,217,728 cases. It only makes it 0.0000007% slower."
	},
	{
		"id": 500,
		"type": "ignore",
		"date": "2010-08-28 14:54:04",
		"src": "https://bitcointalk.org/index.php?topic=941.msg11505#msg11505",
		"q": "The \"About\" dialog still shows 0.3.10.1 beta.",
		"a": "What OS? I ran the Windows and 64-bit Linux version and checked the about dialog.\nThe Mac version is still 0.3.10.1."
	},
	{
		"id": 501,
		"type": "ignore",
		"date": "2010-08-28 14:54:04",
		"src": "https://bitcointalk.org/index.php?topic=941.msg11505#msg11505",
		"q": "iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.",
		"a": "I updated the first post to be more specific. Only the -4way code is compiled this way."
	},
	{
		"id": 502,
		"date": "2010-08-29 22:14:36",
		"src": "https://bitcointalk.org/index.php?topic=816.msg11610#msg11610",
		"q": "I think all of them can go away since SHA-256 expects it's bytestream to be big-endian. The fastest way to find out I think is to run the code through a debugger on both a BE and LE machine at the same time and compare results at every step.",
		"a": "The code assumes little-endian throughout and was written with the intention of never being ported to big-endian. Every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code. It would not be worth the extra sourcecode bloat.\nBig-endian is on its way out anyway."
	},
	{
		"id": 503,
		"type": "ignore",
		"date": "2010-09-05 23:25:32",
		"src": "https://bitcointalk.org/index.php?topic=967.msg12062#msg12062",
		"q": "Forgot to mention that I only see this error when trying to run bitcoind with sox proxy:\n~/bitcoind -proxy=127.0.0.1:10000 -gen -server\nMy proxy is the ssh channel:\nssh -n -D localhost:10000 someone@somewhere.com \"bash -c \\\"while true; do sleep 100; done\\\"\" &",
		"a": "You can probably just comment out the line\ncryptopp/secblock.h:187\n//assert(false);\nLet me know if it works, and watch if it memory leaks.\nIt looks like a template class to make sure the derived class defines its own version of allocate and deallocate. It would be weird if that was the actual problem and it made it all the way to release. Probably a false alarm."
	},
	{
		"id": 504,
		"date": "2010-09-05 23:36:20",
		"src": "https://bitcointalk.org/index.php?topic=960.msg12063#msg12063",
		"q": "If your system clock is too far off, blocks that you create would be rejected, and your client will reject any blocks that it views have been created with a future date.",
		"a": "Any suggestions for better text to put for this error message so the next person will be less likely to be confused?\nIt's trying to tell them their clock is wrong and they need to correct it.\nIt's relying on 3 time sources:\n1) the system clock\n2) the other nodes, if within an hour of the system clock\nif those disagree, then\n3) the user (asking the user to fix the system clock)\nI've thought about NTP, but this is more secure."
	},
	{
		"id": 505,
		"date": "2010-09-06 21:21:21",
		"src": "https://bitcointalk.org/index.php?topic=969.msg12130#msg12130",
		"q": "Speak now about this change or forever hold your peace... Satoshi will be including this functionality in the next version of Bitcoin (0.3.12).\nIf you use the JSON-RPC api, you should check your error-condition-handling code; again, the changes are that the error member will be an Object (with 'code' and 'message' fields) instead of a String, and the HTTP status code may be 404 instead of 500 for method-not-found.",
		"a": "This is in SVN rev 147.\nThis is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be objects not strings or other values, so we needed to change this to be correct. The code/message members have become standard in later json-rpc specs.\nIf you have code that checks the error and expects a string, you'll need to change it. When there is an error, the error member is now an object not a string.\nAlso in SVN rev 147:\n- The command line json-rpc returns the error code as its exit code. Exit codes can only be 0-255 on unix, so it's abs(code)%256.\n- The \"backupwallet <destination>\" command that was discussed in another thread. It locks the wallet and copies it, so you can be sure you get a correct copy."
	},
	{
		"id": 506,
		"type": "ignore",
		"date": "2010-09-06 21:41:06",
		"src": "https://bitcointalk.org/index.php?topic=960.msg12132#msg12132",
		"q": "\"Please check that your computer's date and time are correct. If your clock is wrong Bitcoin will not work properly.\"",
		"a": "Thanks."
	},
	{
		"id": 507,
		"type": "ignore",
		"date": "2010-09-06 21:52:45",
		"src": "https://bitcointalk.org/index.php?topic=992.msg12135#msg12135",
		"q": "I've been getting this from the start, and it is only a mild nuisance as I develop in OSX but then deploy on linux.\nAnyway, the bitcoind process doesn't daemonize itself on my system, OSX 10.6, not with nor without -daemon. I can background it with '&' or ctrl-z bg, and it works correctly.",
		"a": "Can you build?\nTry changing line 78 of init.cpp from:\n#ifdef __WXGTK__\n#ifndef __WXMSW__\nIf that works, I'll change the source. It should work."
	},
	{
		"id": 508,
		"date": "2010-09-07 16:32:21",
		"src": "https://bitcointalk.org/index.php?topic=994.msg12168#msg12168",
		"q": "The correct fee is so small right now that the psychological detriment far outweighs the benefits of charging it imo. It's like that damn place that charges me a quarter a tiny cup of water when I buy a $9 meal. Yes, I know there are costs to pressing the button, but now I don't like you anyway.\nI expect it will be a long time before a high % of nodes require a fee for normal transactions. This means most users will not attach a fee, being willing to wait 4 blocks on average or whatever. So for a good while charging a fee simply means not putting transactions in blocks, this will make bitcoin slightly less appealing and slightly reduce use which will slightly reduce the value of coins. So anyone who has coins can self interestedly include transactions for free.\nJgarzik, do you have a guess as to the resource costs of a normal transaction?",
		"a": "Another option is to reduce the number of free transactions allowed per block before transaction fees are required. Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee.\nThe threshold should probably be lower than it currently is.\nI don't think the threshold should ever be 0. We should always allow at least some free transactions."
	},
	{
		"id": 509,
		"date": "2010-09-08 17:30:14",
		"src": "https://bitcointalk.org/index.php?topic=994.msg12237#msg12237",
		"q": "http://www.bitcoin.org/wiki/doku.php?id=transaction_fee",
		"a": "Currently, paying a fee is controlled manually with the -paytxfee switch. It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee. We're so far from reaching the threshold, we don't need that yet. It's a good idea to see how things go with controlling it manually first anyway.\nIt's not a big deal if we reach the threshold. Free transactions would just take longer to get into a block.\nI did a rough tally of 4000 blocks from around 74000-78000. This is excluding the block reward transactions:\nThere were average 2 transactions per block, 17 transactions per hour, 400 transactions per day.\nAverage transaction bytes per block was 428 bytes, or 214 bytes per transaction.\nThe current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.\nThe threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event."
	},
	{
		"id": 510,
		"type": "ignore",
		"date": "2010-09-08 18:06:04",
		"src": "https://bitcointalk.org/index.php?topic=999.msg12240#msg12240",
		"q": "What does the prohibition of \"nonstandard\" transactions do?\nmain.cpp:506\n// Rather not work on nonstandard transactions\nif (GetSigOpCount() > 2 || ::GetSerializeSize(*this, SER_NETWORK) < 100)\nreturn error(\"AcceptToMemoryPool() : nonstandard transaction\"); What is included in \"GetSigOpCount\", and what does \"GetSerializeSize\" measure?\nThis is \"lightly\" enforced by the network:\nmain.cpp:1425\n// Check that it's not full of nonstandard transactions\nif (nHeight > 79400 && GetSigOpCount() > MAX_BLOCK_SIGOPS)\nreturn error(\"AcceptBlock() : too many nonstandard transactions\");",
		"a": "Bitcoin clients currently only create and recognize transactions that match two possible templates.\nThose are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit. Nodes will only work on adding those transactions to their block.\nIn the future, if we add more templates to the existing 2 types of transactions, we can change the \"rather not work on nonstandard transactions\" test to accept them."
	},
	{
		"id": 511,
		"type": "ignore",
		"date": "2010-09-08 20:27:39",
		"src": "https://bitcointalk.org/index.php?topic=955.msg12248#msg12248",
		"q": "AMD X3 @2.8ghz\n->stock client\n~3800khs ~150Watt",
		"a": "Did you try -4way?"
	},
	{
		"id": 512,
		"type": "ignore",
		"date": "2010-09-08 20:27:39",
		"src": "https://bitcointalk.org/index.php?topic=955.msg12248#msg12248",
		"q": "How many hashes can I expect with a 24 core machine? I have a quad-core generating 4,300 hashes-per-second, so I am estimating a 24-core machine could mine bitcoins at 25,000 hashes-per-second.",
		"a": "AMD Phenom (I think 4-core) CPUs are doing about 11,000khps with -4way, about 100% speedup. 24 cores should get 66,000khps. AMD is the best choice because it has the best SSE2 implementation. (or maybe because tcatm had an AMD and optimised his code for that)\nThere's been so much else to do that I haven't had time to make -4way automatic. For now you still have to do it manually.\nhttp://bitcointalk.org/index.php?topic=820.0"
	},
	{
		"id": 513,
		"date": "2010-09-10 00:23:24",
		"src": "https://bitcointalk.org/index.php?topic=1013.msg12341#msg12341",
		"q": "Rounding error? Have you received bitcoins from the faucet, then paid 0.0495 btc to someone. Ever done anything in the 3rd decimal or beyond? I have 0.01 at TAABL that I can't withdraw due to rounding error. Still, +50.00 is +50.00, and should be able to withdraw that.\nFresh blocks take something like 100 blocks to confirm. I assume you waited.",
		"a": "What version is the one where this happened? Release build, or built it yourself? Which operating system?\nWere you sending by IP or by Bitcoin Address?\nWhen you sent 49.99, did it prompt you to pay a 0.01 fee?\nThere was a change in GetMinFee, but I can't see how it would cause this. It only starts to apply when a block gets huge.\nThe reason for the difference in block number is the number displayed was reduced by 1 in 0.3.11 because it made more sense that way."
	},
	{
		"id": 514,
		"date": "2010-09-10 17:12:33",
		"src": "https://bitcointalk.org/index.php?topic=1013.msg12368#msg12368",
		"q": "You received a fee of 0.01. You didn't pay one.",
		"a": "The fix is in SVN rev 151.\nYou will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade."
	},
	{
		"id": 515,
		"type": "ignore",
		"date": "2010-09-10 18:11:06",
		"src": "https://bitcointalk.org/index.php?topic=1007.msg12372#msg12372",
		"q": "Since the function CallCPUID function contains x86 assembler, it breaks the build on other architectures. I've changed line 2770 in main.cpp to\n#if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE)\nto make it compile again, at least on ARM.",
		"a": "Added in SVN rev 152"
	},
	{
		"id": 516,
		"date": "2010-09-12 17:40:20",
		"src": "https://bitcointalk.org/index.php?topic=589.msg12483#msg12483",
		"q": "It does not -- did my own tests.",
		"a": "Is there a way to open BerkeleyDB exclusive?\nDB_PRIVATE is the worst of both worlds. DB_PRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.\nI've dropped the DB_PRIVATE flag in rev 153."
	},
	{
		"id": 517,
		"type": "ignore",
		"date": "2010-09-12 18:00:39",
		"src": "https://bitcointalk.org/index.php?topic=920.msg12484#msg12484",
		"q": "DB_PRIVATE enables a few optimizations by making the assumption that only one process will access the db4 database. Notably, this flag enables db4 to use pthreads-style mutex locking rather than heavy, operating-system-provided flock and shared memory. Ref: DB_ENV->open documentation.\nThe general motivation is that db4 databases can be safely accessed in parallel with bitcoin client, assuming (a) DB_PRIVATE is removed and (b) bitcoin properly uses db4 transactions. db4 transactions may even be employed to wrap around non-db4 data such as blk0001.dat, if the code is properly architected.",
		"a": "Trying it without the DB_PRIVATE flag in rev 153. We need to keep an eye on what's different.\nOn Windows at least, it creates six __db.001 - __db.006 files with sizes from 24K to 4MB. It doesn't delete them on exit, it just leaves them behind.\nThe docs say it uses memory mapped files. I assume they have the same file permissions as the database files, so the same user access restrictions apply.\nTests on Windows private LAN download of 78500 blocks:\nwith DB_PRIVATE 20 minutes 51 seconds\nwithout DB_PRIVATE 20 minutes 51 seconds\nI wasn't expecting them to come out exactly the same."
	},
	{
		"id": 518,
		"date": "2010-09-12 19:24:53",
		"src": "https://bitcointalk.org/index.php?topic=989.msg12494#msg12494",
		"q": "For a software like this, *only* GPL license makes any sense. It's not about an ideology but rather anyone who would trust proprietary software for their financial transactions and a system like bitcoin is a fool and deserves what's coming for them (which is a lot of stolen \"cash\"). Using proprietary software may even result in hijacking of the whole bitcoin network if significant portion of people would use such a client. There is no way to reliably test for backdoors or other nasty stuff, any closed-source software should be essentially banished by the bitcoin community. GPL allows you to make private in-house modification as much as you like so that's not an issue at all. The only situation that causes GPL to trigger is when you *distribute* the software to other people, in which case you have to provide sources along with it which is the only way anyone should accept any software dealing with bitcoin anyway.\nYou have to also realize that there are no legal consequences to any \"theft\" as using bitcoin from neutral point of view is essentially just moving some arbitrary bits around. So the bitcoin community is expected to self-regulate, which should come in a form of an enforced transparency (by all the users rejecting anything else). Considering any other license than GPL-like is playing with fire and is not going to end well.\nI did not realize current bitcoin client was released under MIT license,\nThis should be changed to GPL IMMEDIATELY!\nGPLv3 even protects you from said software to be locked up by DRM so even when it's open-source you would not have access to it. There is no disadvantage to using GPL license really. Anyone spreading FUD about GPL is either not appropriately informed/did not consider all the issues or has an ulterior motive as far as I'm concerned. I'm not going to trust any closed-source, that's for sure ... and if significant portion of the bitcoin community is, then I'm going to sell off all my bitcoins and get out as that's a prescription for disaster, sooner or later.\nAs much as adoption is concerned, I'm not interested in people who feel the need to keep the source closed and hidden from its users to \"adopt\" anything as I would hope anyone concerned about the success and reliability of the bitcoin network wouldn't either. To complain about weak adoption in that sphere is like complaining about weak adoption by criminals to me. If someone is honest, they should feel no interest in keeping the source closed ... and every sane person would accept ONLY open-sourced software anyway. It's a win-win situation",
		"a": "If the only library is closed source, then there's a project to make an open source one.\nIf the only library is GPL, then there's a project to make a non-GPL one.\nIf the best library is MIT, Boost, new-BSD or public domain, then we can stop re-writing it.\nI don't question that GPL is a good license for operating systems, especially since non-GPL code is allowed to interface with the OS. For smaller projects, I think the fear of a closed-source takeover is overdone."
	},
	{
		"id": 519,
		"type": "ignore",
		"date": "2010-09-19 17:22:03",
		"src": "https://bitcointalk.org/index.php?topic=1023.msg13201#msg13201",
		"q": "I have an unusual configuration: on my headless gateway there is bitcoind running and on my desktop standart bitcoin is running (both Linux OpenSuSE, gateway 11.1, desktop 11.3, bitcoin 0.3.12 both). TCP port 8333 forwarded on gateway to the desktop (so gateway client can't has incoming connections). I don't know why but when I start desktop client after gateway's one the desktop client can't connect and flickers between 0 and 2 connections for a long time. Eventually it may connect but while it can't the memory leaks badly. About 200Kb/sec (each 0-2 change). It may not be noticed if the client connects instantly but in my case it doesn't. If I start first the desktop and then the headless client (after the desktop one has connected) everything is fine and no leaks (or they are little enough). I guess there is unfreed memory in bootstrap function or somewhere in the bootstrap process.",
		"a": "Bouncing between 0 and 2 connections could be if it's connecting to itself. Are you using the \"-connect\" switch?\nDid you compile it or is this a release build, and what version?\nI'm not sure how the 200Kb/sec, since it waits at least a half second between connection attempts. How fast is it flickering between 0 and 2 connections? Faster than twice a second?\nThe wait function on linux is:\ninline void Sleep(int64 n)\n{\nboost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));\n}\nIf that doesn't work right, then it would be possible for it to spin through the loop as fast as it can."
	},
	{
		"id": 520,
		"type": "ignore",
		"date": "2010-09-19 18:46:46",
		"src": "https://bitcointalk.org/index.php?topic=1034.msg13206#msg13206",
		"q": "Ok...so trying to build from the commandline with nmake is still giving me the same problems:\nc:\\Users\\[myusername]\\Desktop\bitcoin-0.3.12\\src>nmake /f makefile.vc\nMicrosoft (R) Program Maintenance Utility Version 10.00.30319.01\nCopyright (C) Microsoft Corporation. All rights reserved.\ncl /c /nologo /MDd /EHsc /GR /Zm300 /Zi /D__WXDEBUG__ /DWIN32 /D__WXMSW__ /D_WINDOWS /DNOPCH /I\"/boost\" /I\"/db/build_windows\"\n/I\"/openssl/include\" /I\"/wxwidgets/lib/vc_lib/mswud\" /I\"/wxwidgets/include\" /DGUI /Foobj\\util.obj util.cpp\nutil.cpp\nc:\\[myusername]\\desktop\bitcoin-0.3.12\\src\\db.h(15) : error C2143: syntax error : missing ';' before '<'\nc:\\[myusername]\\desktop\bitcoin-0.3.12\\src\\db.h(15) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau\nlt-int\nc:\\[myusername]\\desktop\bitcoin-0.3.12\\src\\db.h(16) : error C2146: syntax error : missing ';' before identifier 'cs_mapAddressBook'\nc:\\[myusername]\\desktop\bitcoin-0.3.12\\src\\db.h(16) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau\nlt-int\nc:\\[myusername]\\desktop\bitcoin-0.3.12\\src\\db.h(16) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau\nlt-int\nc:\\[myusername]\\desktop\bitcoin-0.3.12\\src\\db.h(17) : error C2143: syntax error : missing ';' before '<'\nc:\\[myusername]\\desktop\bitcoin-0.3.12\\src\\db.h(17) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau\nlt-int\nc:\\[myusername]\\desktop\bitcoin-0.3.12\\src\\db.h(23) : error C2146: syntax error : missing ';' before identifier 'dbenv'\nc:\\[myusername]\\desktop\bitcoin-0.3.12\\src\\db.h(23) : error C4430: missing type specifier - int assumed. Note: C++ does not support defau\nlt-int\nAny additional advice would be appreciated...\nI think that the C4430 error can be ignored by adding a #pragma warning(disable:4430) to headers.h, but the other ones appear to be more serious\nIt looks like the C2143 is sometimes caused by problems with #includes, but since I am just using the files that were distributed with the source...I would assume all are functional? Maybe it is something about using vs2010 that is causing the problems?",
		"a": "The lines it's tripping on:\nERROR extern map<string, string> mapAddressBook;\nERROR extern CCriticalSection cs_mapAddressBook;\nERROR extern vector<unsigned char> vchDefaultKey;\nOK extern bool fClient;\nOK extern int nBestHeight;\nOK extern unsigned int nWalletDBUpdated;\nERROR extern DbEnv dbenv;\nSo it's acting like nothing is defined, not even map and vector.\nYet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h.\nIs VC trying to use precompiled headers and screwing it up? Could there be some leftover precompiled header files in your directory from previously failed attempts that it's finding and using?\nThere's an installer package now that makes it really easy to install MinGW. Don't use the latest version 4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0. A setup program completely installs everything, it's not hard like it used to be. I think the only thing I had to do was rename make*.exe something to make.exe.\nhttp://tdm-gcc.tdragon.net/\nOff topic, but: It would be nice if someone would hack on getting tcatm's 4-way 128-bit SSE2 code working on Windows. There's something with MinGW's optimisation, I'm not sure but maybe a problem with 16-byte alignment on the stack, that makes it segfault. With some fiddling, I was able to get his code to work in a test program, but not in Bitcoin itself for some reason."
	},
	{
		"id": 521,
		"date": "2010-09-19 19:58:11",
		"src": "https://bitcointalk.org/index.php?topic=1063.msg13211#msg13211",
		"q": "I agree with nelisky-- not a bug. Here's what the unix cat command has to say about \"\":\n> cat \"\"\ncat: : No such file or directory",
		"a": "I don't know anything about any of the bug trackers. If we were to have one, we would have to make a thoroughly researched choice.\nWe're managing pretty well just using the forum. I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker. A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion.\nI keep a list of all unresolved bugs I've seen on the forum. In some cases, I'm still thinking about the best design for the fix. This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them."
	},
	{
		"id": 522,
		"date": "2010-09-19 21:49:30",
		"src": "https://bitcointalk.org/index.php?topic=1048.msg13219#msg13219",
		"q": "But do not remove the IP-transactions at all, please!\nhttp://bitcointalk.org/index.php?topic=1042.msg13160",
		"a": "Probably best to disable receiving by IP unless you specifically intend to use it. This is a lot of surface area that nobody uses that doesn't need to be open by default.\nIn storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts. Random unidentified payments volunteered to the server's IP address would be unhelpful.\nIn general, sending by IP has limited useful cases. If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy. If you use a privacy proxy, man-in-the-middle risk is unacceptably high. If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.\nI uploaded this change to SVN rev 156. The switch to enable is \"-allowreceivebyip\".\nSenders with this version will get the error \"Recipient is not accepting transactions sent by IP address\". Older version senders will get \"Transfer was not accepted\".\nI used a different name for the switch because \"-allowiptransactions\" sounds like it includes sending. If there's a better name for the switch, we can change it again."
	},
	{
		"id": 523,
		"date": "2010-09-19 22:47:00",
		"src": "https://bitcointalk.org/index.php?topic=1032.msg13221#msg13221",
		"q": "Haha! Well, that's partially true. Ususally they have a fixed amount of pre-paid text messages that they can send each month which if the don't use are simply wasted. But they tend to forget that I still have to pay 25 cents whenever they send me a lousy spam text message!!!\nA smartphone bitcoin client with options for encrypted messaging would make for a great alternative text/sms system compared to the high fees charged by most wireless carriers for text messaging. Now, of course, I know of free text messaging apps, but they tend to contain ads. But with bitcoin, the small transaction fees for passing the message along would work as a great incentive instead...",
		"a": "Theymos already said this... ECDSA does not support encrypting messages. Only digital signatures."
	},
	{
		"id": 524,
		"type": "favorite",
		"date": "2010-09-23 16:08:35",
		"src": "https://bitcointalk.org/index.php?topic=994.msg13829#msg13829",
		"q": "The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.",
		"a": "I implemented this change in SVN rev 157.\nThe reason I previously made it so high was to allow very large transactions without hitting the transaction fee. The threshold was around 26,000 BTC for transactions made of 50 BTC generated coins. Even though it was 100 times easier to generate back then, only a few people ever encountered the fee at that level. The new threshold puts it at around 11,000 BTC for sending generated coins. It would mostly only be reached with generated bitcoins. If you bought your bitcoins, they'll be denominated in larger transactions and won't be anywhere near the fee limit, unless you bought them in several hundred separate transactions. Even if you do reach the fee level, you only have to pay it once to bundle your little transactions together."
	},
	{
		"id": 525,
		"date": "2010-09-23 16:28:25",
		"src": "https://bitcointalk.org/index.php?topic=960.msg13833#msg13833",
		"q": "Agreed. There is no need to set the system time.\nWe only need to use correct time in the program.",
		"a": "I don't understand, are you under the impression that the program sets the system clock? It doesn't."
	},
	{
		"id": 526,
		"date": "2010-09-23 16:28:25",
		"src": "https://bitcointalk.org/index.php?topic=960.msg13833#msg13833",
		"q": "We already have ways to synchronize (approximately) the clients, so why not make use of that?",
		"a": "We use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an hour. If they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock."
	},
	{
		"id": 527,
		"date": "2010-09-23 17:56:55",
		"src": "https://bitcointalk.org/index.php?topic=671.msg13844#msg13844",
		"q": "Yeah, Bitcoin serve as good captcha.",
		"a": "Bitcoin would be convenient for people who don't have a credit card or don't want to use the cards they have, either don't want the spouse to see it on the bill or don't trust giving their number to \"porn guys\", or afraid of recurring billing."
	},
	{
		"id": 528,
		"date": "2010-09-23 18:39:56",
		"src": "https://bitcointalk.org/index.php?topic=1271.msg13848#msg13848",
		"q": "Will transaction fees be applied to transfers above 0.01, but with more precision? I wasn't aware of it being that way.\nAnd yes, I am rounding for now, but I like things clean, and I can either allow withdrawal of higher precision amounts, or I can round to 2 decimals the prize handout, I just rather do the former, that's all.\nAnd no, it's not *only* for the sportsbook. I have plans...",
		"a": "I would not encourage using the extra decimal places. They're only intended for future use.\nYou are correct that above 0.01 can still have additional precision, but the recipient won't be able to see it. The UI will show it rounded down."
	},
	{
		"id": 529,
		"date": "2010-09-23 18:46:20",
		"src": "https://bitcointalk.org/index.php?topic=1269.msg13849#msg13849",
		"q": "Thanks for the heads up. I'm actually checking version on my web apps, to assert if backupwallet is available, but as my private version is now widespread, it should be very simple to cope with that change.",
		"a": "I don't think it should cause any problems for version comparisons. 31300 > 312."
	},
	{
		"id": 530,
		"type": "favorite",
		"date": "2010-09-26 17:34:26",
		"src": "https://bitcointalk.org/index.php?topic=1283.msg14136#msg14136",
		"q": "Summary: Giving BitCoin a decentralized escrow would give it an advantage over all other exchange mediums, which might increase its adoption rate. Details follow.\nFor a decentralized currency, centralized escrows seem to be the norm for BitCoin today. An example:\nAlice wants to buy $5 USD worth of BitCoins from Bob, but neither Alice nor Bob fully trust the other, so they go to a site they both trust--say Mt. Gox. There they deposit their respective monies and there they have Mt. Gox make the exchange for them.\nNo offense to Mt. Gox (a site I like), but can we do without its escrow service?\nAn almost distributed alternative:\nCharlie, a trusted third-party, generates a BitCoin private key. Charlie then uses the Unix command split to split the private key in half--giving one half to Alice and one half to Bob. Bob deposits $5 USD worth of BitCoins into the split BitCoin account; Alice verifies the transaction using the public block; Alice sends $5 USD to Bob by PayPal; Bob verifies the PayPal transaction; Bob sends Alice his half of the split private key so Alice can access the BitCoins he deposited earlier.\n(For simplicity I omit part of the PayPal details like who pays the transaction fee and how long you should wait to avoid chargeback fraud. I also omit any incentive for Bob to perform the final step.)\nMore advanced almost-distributed examples can be made if we substitute something more sophisticated for the Unix command split. For example: a Shamir's secret sharing scheme implementation like ssss[1]. A utility like ssss allows Alice and Bob to appoint an arbiter in case they get in a disagreement.\nThe problem with all of this, of course, is that we must trust Charlie to not abuse the full copy of the private key he creates.\nThe ideal solution would be for Alice and Bob to each generate half of the private key on their own. I don't fully understand the math used in modern keypairs, but I doubt this is possible with the current algorithm.\nIs there an alternative way for Alice and Bob to each acquire half of a private key without giving the whole key to any party?\n-Dave\n[1] See: http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing",
		"a": "It's not implemented yet, but the network can support a transaction that requires two signatures. It's described here:\nhttp://bitcointalk.org/index.php?topic=750.0\nIt's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.\nIn this kind of escrow, a cheater can't win, but it's still possible for you to lose. It at least takes away the profit motive for cheating you. The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion."
	},
	{
		"id": 531,
		"type": "ignore",
		"date": "2010-09-30 16:38:53",
		"src": "https://bitcointalk.org/index.php?topic=1306.msg14714#msg14714",
		"q": "ok, so i built a modified bitcoind, with the addition of 'pcoin->GetDepthInMainChain() < 1' to both SelectCoins and GetBalance.\nMy 'stock client' balance shows as 131.00139787, and my modified client balance shows as 130.92112098, so i have about 0.08xx of \"bad\" bitcoins' worth of transactions in my wallet.\nSo I guess now, all i need to do is create another wallet, and then send all the \"good coins\" from my old wallet to my new one (or, i guess... i could just use the same wallet, since my bitcoind won't try to send the bad coins, i can just ignore them....)\nBut yes, I hope the modifications as described by jgarzik (being configurable with cli switches/checkboxes) do make it into mainline - because otherwise it's too easy to 'poison' people's wallets with bogus transactions.",
		"a": "As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature.\nI made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending. This doesn't apply to transactions you sent, which you implicitly trust, since you wrote them.\nI didn't make it (+1.23) because parenthesis in accounting means negative. I hope square brackets is different enough to be clear what is meant.\nThe JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.\nI uploaded the changes to SVN rev 158. I will post a 0.3.13 RC shortly.\nIf you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon.\nIf you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up.\nif (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0)\ncontinue;\nif (pcoin->GetDepthInMainChain() < 1)\ncontinue;"
	},
	{
		"id": 532,
		"date": "2010-09-30 17:50:32",
		"src": "https://bitcointalk.org/index.php?topic=652.msg14729#msg14729",
		"q": "Can we just make different language versions of a deleted page without getting them removed? Let's do it if we can. I can write a version in Finnish.",
		"a": "If you do, I think it should be a very brief, single paragraph article like 100 words or less that simply identifies what Bitcoin is.\nI wish rather than deleting the article, they put a length restriction. If something is not famous enough, there could at least be a stub article identifying what it is. I often come across annoying red links of things that Wiki ought to at least have heard of.\nThe article could be as simple as something like:\n\"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/.\"\nThe more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash. We can probably establish a paragraph there. Again, keep it short. Just identifying what it is."
	},
	{
		"id": 533,
		"date": "2010-09-30 18:11:56",
		"src": "https://bitcointalk.org/index.php?topic=1314.msg14732#msg14732",
		"q": "The fees are a function of total transaction volume.\nRight now the volume is pretty tiny so all fees are zero.\nLater when the volume is high only some of the current transactions will be included in each\nblock so you either pay a fee to make sure your transaction is desirable to be in each block\nor wait until the trading volume drops.\n-Wayne",
		"a": "It ramps up the fee requirement as the block fills up:\n<50KB free\n50KB 0.01\n250KB 0.02\n333KB 0.03\n375KB 0.04\netc.\nIt's a typical pricing mechanism. After the first 50KB sells out, the price is raised to 0.01. After 250KB is sold, it goes up to 0.02. At some price, you can pretty much always get in if you're willing to outbid the other customers.\nJust including the minimum 0.01 goes a long way."
	},
	{
		"id": 534,
		"type": "favorite",
		"date": "2010-09-30 18:22:22",
		"src": "https://bitcointalk.org/index.php?topic=1314.msg14734#msg14734",
		"q": "That's cost per kilobyte, though, and a kilobyte can only hold ~9 TxIns, so 0.01 is not guaranteed to meet the requirement.",
		"a": "True, the switch should be something more dynamic that pays per KB. It's harder to think of how to explain it."
	},
	{
		"id": 535,
		"type": "ignore",
		"date": "2010-09-30 18:27:41",
		"src": "https://bitcointalk.org/index.php?topic=1291.msg14736#msg14736",
		"q": "Hey all...Thanks for all the feedback\nThe ssh method is great. However, all the machines are windows machines so i'd have to do an install on all of them. Better than writing a proxy app for sure though...\nI saw the entry from a few weeks ago about the -rpcallowip switch. I'll compile my own version if i have to. That said, i'd prefer to have an official release. Anyone have an idea when the next version would be posted?\nAs far as the MITM attack possibility, this only presents a problem if the network i'm exposing to is not trusted. Or is there some other effect i'm missing?",
		"a": "It can be safe if you're using it over your own LAN, like if you have multiple servers at a location that talk to each other.\n0.3.13 RC1 is available for Windows:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe"
	},
	{
		"id": 536,
		"date": "2010-10-01 00:32:46",
		"src": "https://bitcointalk.org/index.php?topic=1322.msg14787#msg14787",
		"q": "What about to add Russian localization to 0.3.13?",
		"a": "Too late for 0.3.13, but I'll try to find time to add it to the next version."
	},
	{
		"id": 537,
		"type": "ignore",
		"date": "2010-10-03 18:17:06",
		"src": "https://bitcointalk.org/index.php?topic=1327.msg15102#msg15102",
		"q": "That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.\nI still have to add the \"-4way\" switch.",
		"a": "Forgot to say, I suspected the detect might not work on 64-bit AMD. I found it hard to believe but AMD reports a different model number in 64-bit mode.\nCould you grep CPUID your debug.log and tell me what it says? (and anyone else with 64-bit AMD) And what AMD chip do you have?\nDo all AMDs that support 64-bit have the better SSE2 hardware also?"
	},
	{
		"id": 538,
		"date": "2010-10-03 19:49:32",
		"src": "https://bitcointalk.org/index.php?topic=1327.msg15112#msg15112",
		"q": "983 Mhash/s box.",
		"a": "Seriously? What hardware is that?"
	},
	{
		"id": 539,
		"type": "ignore",
		"date": "2010-10-03 20:02:24",
		"src": "https://bitcointalk.org/index.php?topic=1327.msg15116#msg15116",
		"q": "Three GPUs (ATI HD 5870).",
		"a": "diff -u old\\main.cpp new\\main.cpp\n--- old\\main.cpp Sun Oct 03 20:57:20 2010\n+++ new\\main.cpp Sun Oct 03 20:57:54 2010\n@@ -2831,6 +2831,10 @@\nbool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||\n(fAMD && nFamily * 10000 + nModel >= 160010));\n+ // AMD reports a lower model number in 64-bit mode\n+ if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160004)\n+ fUseSSE2 = true;\n+\nstatic bool fPrinted;\nif (!fPrinted)\n{\n@@ -2989,6 +2993,17 @@\n// Transaction fee based on block size\nint64 nMinFee = tx.GetMinFee(nBlockSize);\n+ //////// temporary code\n+ if (nBlockSize < MAX_BLOCK_SIZE_GEN / 10 && GetWarnings(\"statusbar\") == \"\")\n+ {\n+ if (nBestHeight < 91000)\n+ nMinFee = 0;\n+ if (nBestHeight < 100000 && nTxSize < 2000)\n+ nMinFee = 0;\n+ if (nBestHeight < 110000 && nBestHeight % 10 == 0)\n+ nMinFee = 0;\n+ }\n+ //////// temporary code\nmap<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);\nif (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))\ndiff -u old\\serialize.h new\\serialize.h\n--- old\\serialize.h Sun Oct 03 20:57:45 2010\n+++ new\\serialize.h Sun Oct 03 20:57:54 2010\n@@ -22,8 +22,8 @@\nclass CAutoFile;\nstatic const unsigned int MAX_SIZE = 0x02000000;\n-static const int VERSION = 31300;\n-static const char* pszSubVer = \"\";\n+static const int VERSION = 31301;\n+static const char* pszSubVer = \" test1\";"
	},
	{
		"id": 540,
		"type": "ignore",
		"date": "2010-10-03 20:54:07",
		"src": "https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136",
		"q": "ArtForz is already running with no fees, and he has 20-30% of the network's CPU power. The person who originally sent the broken transactions deleted his wallet, though, and the network has forgotten these historical transactions, so any transactions based on this won't confirm.",
		"a": "Transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain.\nAny transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain. If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours.\nIf a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong. It's a part of code that doesn't get much use. They should be recorded in the wallets of everyone who has a transaction depending on them."
	},
	{
		"id": 541,
		"type": "ignore",
		"date": "2010-10-03 20:54:07",
		"src": "https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136",
		"q": "The person who originally sent the broken transactions deleted his wallet",
		"a": "Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case? You should never delete a wallet."
	},
	{
		"id": 542,
		"type": "ignore",
		"date": "2010-10-03 20:54:07",
		"src": "https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136",
		"q": "It's running. Should find a block within 3 hours.",
		"a": "It may take a while to collect re-broadcast transactions. It'll help if you can accept inbound connections so you'll be listening to more nodes. Even if you find a block in 3 hours, keep it running continuously for a few days at least."
	},
	{
		"id": 543,
		"date": "2010-10-03 21:07:28",
		"src": "https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139",
		"q": "Applying this patch will make you incompatible with other Bitcoin clients.",
		"a": "+1 theymos. Don't use this patch, it'll make you incompatible with the network, to your own detriment.\nWe can phase in a change later if we get closer to needing it."
	},
	{
		"id": 544,
		"date": "2010-10-03 21:30:04",
		"src": "https://bitcointalk.org/index.php?topic=1332.msg15142#msg15142",
		"q": "When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception.",
		"a": "This is the point of confusion. extraNonce is not part of the block header, it is part of the first transaction. It does not slow down your hashing. It does not change the size of the header.\nWe need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed. It doesn't.\nextraNonce never needs to be very big. We could reset it every second whenever the time changes if we wanted. Worst case, if you didn't want to keep track of incrementing it, extraNonce could be 4 random bytes and the chance of wasting time from collision would be negligible.\nSeparate machines are automatically collision proof because they have different generated public keys in the first transaction. That also goes for each thread too."
	},
	{
		"id": 545,
		"type": "ignore",
		"date": "2010-10-03 21:43:20",
		"src": "https://bitcointalk.org/index.php?topic=1327.msg15147#msg15147",
		"q": "Will that be enough ?:\ncat /proc/cpuinfo\nprocessor : 0\nvendor_id : AuthenticAMD\ncpu family : 16\nmodel : 2\nmodel name : AMD Phenom(tm) 9850 Quad-Core Processor\nstepping : 3\ncpu MHz : 2508.353\ncache size : 512 KB\nphysical id : 0\nsiblings : 4\ncore id : 0\ncpu cores : 4\napicid : 0\ninitial apicid : 0\nfpu : yes\nfpu_exception : yes\ncpuid level : 5\nwp : yes\nflags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs npt lbrv svm_lock\nbogomips : 5018.72\nTLB size : 1024 4K pages\nclflush size : 64\ncache_alignment : 64\naddress sizes : 48 bits physical, 48 bits virtual\npower management: ts ttp tm stc 100mhzsteps hwpstate\nAlso, i have just found out how to do the cpuid thingy:\nCPUID 444d4163 family 16, model 2, stepping 3, fUseSSE2=0",
		"a": "ShadowOfHarbringer, is yours faster with -4way?\nIf it is, then I'm thinking that any AMD that supports 64-bit has 128-bit SSE2.\nThe specialbuild version I posted here looks for model 4 or higher. If yours is faster with -4way, then I should change it to always use SSE2 with any AMD with 64-bit."
	},
	{
		"id": 546,
		"type": "ignore",
		"date": "2010-10-03 22:07:00",
		"src": "https://bitcointalk.org/index.php?topic=1023.msg15150#msg15150",
		"q": "Got that leak again with 0.3.13. Here is the log: http://pastebin.com/g0gqi7kx I cut it because the connecting-disconnecting repeats again and again without any change and censored the external static IP (it's detected correctly). The port 8333 is forwarded and is seen from the outside. The RES size of bitcoin grew up to 150 Mb when I shut it down.",
		"a": "You're connecting to yourself. All 21 connection attempts were to a node with version 31300 (0.3.13). Not everyone has 0.3.13 yet.\nIRC seems to be working. It ought to have other nodes to try.\nThere may be something I need to do to make sure it doesn't try to connect to itself again right away after disconnecting. I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it.\nYou can try moving addr.dat aside. Maybe there's something wrong in it.\nAre you using -addnode?"
	},
	{
		"id": 547,
		"type": "ignore",
		"date": "2010-10-03 23:46:19",
		"src": "https://bitcointalk.org/index.php?topic=1327.msg15167#msg15167",
		"q": "The command line switches are listed in \"bitcoind -?\" instead of \"bitcoind help\". You are still right tho, those options are missing from \"-?\" too.",
		"a": "Make sure you keep your node online so it'll keep rebroadcasting transaction b412a0. It haven't seen it rebroadcast since 29/09/2010 16:41."
	},
	{
		"id": 548,
		"type": "ignore",
		"date": "2010-10-04 01:44:41",
		"src": "https://bitcointalk.org/index.php?topic=151.msg15176#msg15176",
		"q": "Maybe you should pm sirius-m directly.\nBut please first make sure that the translation is correct now, because I guess he won't be happy if we disturb him twice for a translation, especially with this language !",
		"a": "Thanks eurekafag, Russian translation added to SVN rev 160."
	},
	{
		"id": 549,
		"type": "ignore",
		"date": "2010-10-04 19:21:01",
		"src": "https://bitcointalk.org/index.php?topic=151.msg15360#msg15360",
		"q": "Where can I find the latest English .po file to keep the translation up-to-date?",
		"a": "poedit does it. Either get the src directory from a release, or download it with SVN. Place your .po file 3 directories deep under the src directory. Open it with poedit and do Catalog->Update from sources.\nSo for example, you have:\nsrc\nsrc\base58.h\nsrc\bignum.h\n...\nsrc\\util.cpp\nsrc\\util.h\nsrc\\xpm\nsrc\\locale\nu\\LC_MESSAGES\bitcoin.po\nOpen bitcoin.po with poedit, do Catalog->Update from sources. It looks for the sourcecode up 3 directories (..\\..\\..) from where bitcoin.po is.\nThis updates your existing .po file you already worked on and adds any news strings. It may try to match close strings, so check things over and make sure it didn't make any bad guesses.\nMake sure you use the .po file I uploaded to SVN or in a release, because I always fix up at least a few things. I'm attaching your Russian one to this message."
	},
	{
		"id": 550,
		"date": "2010-10-04 19:48:40",
		"src": "https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366",
		"q": "You just described a whole-network upgrade. I'd call that an incompatible change\nThe effort to raise the transaction rate limit is the same as the effort to change the fundamental nature of bitcoins: convince the vast majority to upgrade.",
		"a": "It can be phased in, like:\nif (blocknumber > 115000)\nmaxblocksize = largerlimit\nIt can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.\nWhen we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade."
	},
	{
		"id": 551,
		"type": "ignore",
		"date": "2010-10-06 15:42:39",
		"src": "https://bitcointalk.org/index.php?topic=151.msg15660#msg15660",
		"q": "Shame on me, I haven't know about this useful tool before. Thanks for the clear explanation I've updated the translation according to rev160. How often should I review and update the translation? That's not a problem to do this for every revision but I don't want to spam this topic with translations every 2-3 days. Maybe it's good to make an announce that new release is coming in a few days so translators could update their files in time?",
		"a": "poedit reorganised the file for some reason. I re-ran update from sources and it put it back in the original order so it's fine now. Did you run it on a drive where files aren't sorted alphabetically, like a FAT drive or USB flash drive?\nStrings aren't added or changed very often. It's months before enough changes build up.\nI uploaded the changes.\nThis Windows build has the Russian translation in it:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe"
	},
	{
		"id": 552,
		"type": "ignore",
		"date": "2010-10-06 16:54:23",
		"src": "https://bitcointalk.org/index.php?topic=1306.msg15672#msg15672",
		"q": "So in .13 1 confirm is good enough to pay someone with, but it takes 6 to display \"confirmed\" in the GUI. This is inconsistant. This coin is good enough to pay you with but not good enough for me to accept? I don't know the logic behind the 6, but whatever it is, if its only used to decide which word to display, then is it really representing anything at all?",
		"a": "That's going to be more of a SelectCoins thing.\nSVN rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent. This is needed because you should be able to spend your own change right away.\nThe new recursive determination is: 0/unconfirmed can be spent if it's yours and all its dependencies are either in a block or also yours.\nHere's a Windows build:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe\nThis version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it. If you were the original creator of a 0/unconfirmed transaction, you still need theymos' patch instead."
	},
	{
		"id": 553,
		"type": "ignore",
		"date": "2010-10-06 17:36:41",
		"src": "https://bitcointalk.org/index.php?topic=1375.msg15682#msg15682",
		"q": "Seeding from Tor is a snap. There are 7 .onion nodes that can provide IPs. I'd also just switch the IRC stuff off with '-noirc' to speed it up.\nSee https://www.bitcoin.org/smf/index.php?topic=59.msg14635#msg14635",
		"a": "Maybe you were just unlucky to have an exit node without reverse lookup.\nThe IRC server's response doesn't look like it was disconnecting you for that. It's supposed to go IRC SENDING: NICK after that, and it doesn't so it gets timed out.\nI see the problem. The IRC code is looking for various phrases to see when the server is ready to receive your NICK, but it's not looking for that particular phrase. I'll fix it.\nI don't know if it's really required to wait for the server to finish looking up hostname before sending nick.\nHow long did it take to get connected with TOR the first time, having to use the seed nodes?"
	},
	{
		"id": 554,
		"date": "2010-10-06 23:10:31",
		"src": "https://bitcointalk.org/index.php?topic=1268.msg15741#msg15741",
		"q": "1. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process.",
		"a": "Repeating myself here, but there is open source software for that, so it would just be a matter of bolting on a Bitcoin payment mechanism. One good one I found was Mihalism Multi Host. It's designed as a free host, so it would just need a few tweaks to loosen up restrictions consistent with paid use."
	},
	{
		"id": 555,
		"type": "ignore",
		"date": "2010-10-21 22:50:47",
		"src": "https://bitcointalk.org/index.php?topic=151.msg17965#msg17965",
		"q": "Strange enough. I ran it on my usual XFS and new untranslated strings appeared on top. Is the order so important? I guess it's not for the program and for translators because when one use poedit he can always check what the particular string belongs to. By the way, there are some similar lines that possibly may be replaced by one. They are very close by meaning and differs only by 1-2 words. Just a suggestion of course.",
		"a": "The order matters not to the program, but it matters to me maintaining it. If it jumbles the order of the .po file then I can't diff for changes. I have to update all 7 translation files when I change the English text in the program, and it's easier when they're all in the same order.\nI can still put it back into normal order by making poedit rescan it.\nIt is normal that untranslated strings are shown on top."
	},
	{
		"id": 556,
		"type": "ignore",
		"date": "2010-10-21 22:50:47",
		"src": "https://bitcointalk.org/index.php?topic=151.msg17965#msg17965",
		"q": "By the way, there are some similar lines that possibly may be replaced by one. They are very close by meaning and differs only by 1-2 words. Just a suggestion of course.",
		"a": "I know, but not easily without complicating the sourcecode."
	},
	{
		"id": 557,
		"date": "2010-10-23 18:22:49",
		"src": "https://bitcointalk.org/index.php?topic=1530.msg18241#msg18241",
		"q": "his block count remains \"stuck\" at 1698.",
		"a": "He was generating invalid blocks at difficulty 1.0. He must have a corrupted entry in his blk0001.dat or blkindex.dat file. He just needs to delete blk*.dat and let it redownload.\nThe safety lockdown detected the problem and was displaying \"WARNING: Displayed transactions may not be correct!\" because it saw a longer chain existed that it was unable to accept. The safety lockdown cannot stop generation or it would create an attack possibility."
	},
	{
		"id": 558,
		"date": "2010-10-23 18:22:49",
		"src": "https://bitcointalk.org/index.php?topic=1530.msg18241#msg18241",
		"q": "The Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint.",
		"a": "Good idea, I made a change to make sure it won't generate before checkpoint block 74000."
	},
	{
		"id": 559,
		"date": "2010-10-23 18:38:04",
		"src": "https://bitcointalk.org/index.php?topic=1530.msg18245#msg18245",
		"q": "He already did that, and the same problem occurred right away. So it's probably an antivirus issue.",
		"a": "OK, if it really won't get past block 1698 on redownload, then we're in stranger territory.\nYes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it.\nIt would be instructive to get knightmb's blk*.dat and see if that gets him past that point."
	},
	{
		"id": 560,
		"type": "ignore",
		"date": "2010-10-23 18:52:02",
		"src": "https://bitcointalk.org/index.php?topic=1540.msg18246#msg18246",
		"q": "Fault Module Name: mingwm10.dll",
		"a": "This is the important clue. I believe it's saying it crashed in that. Maybe there are other versions of it to try. mingwm10.dll is just a simple placeholder thing that satisfies some callback requirement for multithreaded apps.\nIs anyone else running OK on Windows 64-bit?"
	},
	{
		"id": 561,
		"date": "2010-10-23 19:02:57",
		"src": "https://bitcointalk.org/index.php?topic=1545.msg18250#msg18250",
		"q": "I also wonder if the message has to be taken into account for the hash computation. Not doing so would allow to delete it later.\nI very much don't like this idea of a message. Since it is not necessary to the protocol, I'm not sure if it would be easy to find a place where it really fits. I'm not a programmer though. I'd be curious to have Satoshi's thought on this.",
		"a": "ECDSA can't encrypt messages, only sign signatures.\nIt would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen.\nIf there's going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain. The messages could be signed with the bitcoin address keypairs to prove who they're from."
	},
	{
		"id": 562,
		"type": "ignore",
		"date": "2010-10-24 19:17:51",
		"src": "https://bitcointalk.org/index.php?topic=665.msg18349#msg18349",
		"q": "Yeah, it is quite obvious. I suffer for over optimization obsession syndrome I feel that as data flows only inside the application there's no need to register transactions and put that 'extra load' on the system, but quite frankly the extra load is perfectly ignorable, and the transactions help keep everything tidy. Are you planning to do anything on this regard? I'm sure I can find my way around to do it myself, it will just take time, but I don't want to duplicate any work though.",
		"a": "I have the beginning of something like this. It's mostly like what Gavin described.\nSome more rpc interface:\nmove <fromaccount> <toaccount> <amount>\nMove from one internal account to another. I think blank account name (\"\") will be your default account. If you sell something to a user, you could do move \"theiraccount\" \"\" 123.45.\nIs \"move\" the best name for this? I shied away from \"transfer\" because that sounds too close to sending a transaction.\nI'm thinking a new function getaccountaddress instead of overloading getnewaddress:\ngetaccountaddress <account>\nGives you an address allocated from getnewaddress <account>. It'll keep giving the same address until something is received on the address, then it allocates a new address. (It automatically does what the sample code I posted some time ago did)\nWould these commands make it possible in simple cases to implement your website without needing a database of your own?"
	},
	{
		"id": 563,
		"type": "ignore",
		"date": "2010-10-25 16:53:53",
		"src": "https://bitcointalk.org/index.php?topic=665.msg18508#msg18508",
		"q": "use -datadir and change the port on the source code and then use a different dir and port for every bitcoin instance",
		"a": "Here's some pseudocode of how you would use the account based commands. It sure makes website integration a lot easier.\nprint \"send to \" + getaccountaddress(username) + \" to fund your account\"\nprint \"balance: \" + getbalance(username, 0)\nprint \"available balance: \" + getbalance(username, 6)\n// if you make a sale, move the money out of their account\nmove(username, \"\", amount, 6)\n// withdrawal\nsendfrom(username, bitcoinaddress, amount, 6)"
	},
	{
		"id": 564,
		"type": "ignore",
		"date": "2010-10-25 17:27:47",
		"src": "https://bitcointalk.org/index.php?topic=1540.msg18511#msg18511",
		"q": "Ok good to know others are able to run it ok.\nUnfortunately bitcoin is not a critical application for me and need to spend my time on other things. If however there is a debugging build of the application which can provide line numbers for the crashed code (0xc0000005 - ACCESS VIOLATION) then I'd be happy to run it to identify the line causing the problem.",
		"a": "The only thing I can think of is to see if there are other versions of mingwm10.dll you can get. mingwm10.dll is a tiny little DLL that came with the MinGW compiler that you need when you build for multi-thread. I don't know exactly what it does, but it probably just says something like \"yes Windows, see I'm in a DLL like you insisted.\"\nThe end of your debug.log file might show the last thing it was doing before it crashed."
	},
	{
		"id": 565,
		"date": "2010-11-13 00:55:51",
		"src": "https://bitcointalk.org/index.php?topic=64.msg21766#msg21766",
		"q": "I like icons that Satoshi published in the first post.",
		"a": "I'm happy if someone with artistic skill wants to contribute alternatives. The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes. I think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites.\nIt'll be a lot simpler if authors could make their graphics public domain."
	},
	{
		"id": 566,
		"date": "2010-11-13 23:25:26",
		"src": "https://bitcointalk.org/index.php?topic=1668.msg21896#msg21896",
		"q": "With davidonpda's help, I did some testing myself today with Satoshi's latest code changes (setting priority based on transaction age, bitcoin amounts in, and total transaction size in bytes -- svn rev 176).\nIt behaved as expected, putting larger, older transactions ahead of the pennies being flooded into the network, so \"normal\" transactions will be confirmed promptly even if somebody decides to be a jerk and floods the network with transactions.",
		"a": "Thank you for limiting flood tests to the testnet.\nVersion 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack. The key was Gavin's idea for prioritising transactions based on the age of their dependencies. Every coin is entitled to turn over so often. The longer waited, the more priority accumulates. Priority is sum(valuein * age) / txsize. Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.\nIn support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that's all you have left. This helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly."
	},
	{
		"id": 567,
		"date": "2010-11-14 16:53:19",
		"src": "https://bitcointalk.org/index.php?topic=1668.msg21959#msg21959",
		"q": "Of course, if the network is not being flooded and you're not overly concerned about the current transaction getting held up then it's probably worth preferring to use your 0 conf transactions so that you can \"save\" the higher priority coins for when the network is being flooded.",
		"a": "You should use at least some priority in case a flood comes along before the next block.\nAs long as all dependencies have at least 1 conf, if the transaction doesn't have enough priority at first, the dependencies will age until it does."
	},
	{
		"id": 568,
		"date": "2010-11-14 16:53:19",
		"src": "https://bitcointalk.org/index.php?topic=1668.msg21959#msg21959",
		"q": "Gaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!",
		"a": "Or managing how much priority you spend on a transaction. The software would have to know your future plans to know whether to spend your priority now or save it for later. I don't think we'll need to get into that much detail though. There's a wide enough difference between normal users and flooders.\nPriority doesn't have to do everything. Once you know there's a flood, you can add -paytxfee=0.01. Hopefully with priority, your transactions before that should be at worst slow, not stuck."
	},
	{
		"id": 569,
		"date": "2010-11-15 18:37:44",
		"src": "https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119",
		"q": "After investigating some more, I found that nLockTime requires in-memory transaction replacement to be re-activated for it to be useful.\nif (mapNextTx.count(outpoint))\n{\n// Disable replacement feature for now\nreturn false;\n// Allow replacing with a newer version of the same transaction\nif (i != 0)\nreturn false;\nptxOld = mapNextTx[outpoint].ptx;\nif (!IsNewerThan(*ptxOld))\nreturn false;\nfor (int i = 0; i < vin.size(); i++)\n{\nCOutPoint outpoint = vin[i].prevout;\nif (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx != ptxOld)\nreturn false;\n}\nbreak;",
		"a": "We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.\nnTimeLock does the reverse. It's an open transaction that can be replaced with new versions until the deadline. It can't be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn't enabled or used yet, but the support is there so it could be implemented later."
	},
	{
		"id": 570,
		"date": "2010-11-19 23:50:24",
		"src": "https://bitcointalk.org/index.php?topic=1850.msg22952#msg22952",
		"q": "Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule without a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. I think that this would significantly inhibit the type of spamming attack that is currently underway.",
		"a": "I'm doing something like that. Priority is a more formalised version of the concept you're describing."
	},
	{
		"id": 571,
		"date": "2010-11-19 23:50:24",
		"src": "https://bitcointalk.org/index.php?topic=1850.msg22952#msg22952",
		"q": "As it stands now 3.15 has a lot of free transaction space and that space is given first to transactions with the highest [age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion of the free space require [age]*[value]/[size] > C ?\nMaybe set C so that a standard 1BTC transaction can get into the main free area on the next block. And a .1 can get in after waiting about 10 blocks. And make the area which allows [age]*[value]/[size] < C to let in about a dozen transactions or so.",
		"a": "Yes, like this. And the no-priority-requirement area is 3K, about a dozen transactions per block.\nI just uploaded SVN rev 185 which has a minimal priority requirement for free transactions. Transaction floods are made up of coins that are re-spent over and over, so they depend on their own 0 conf transactions repeatedly. 0 conf transactions have 0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time.\nVersion 0.3.15 doesn't write transactions using 0 conf dependencies unless that's all it has left, so normal users shouldn't usually have a problem with this.\nI think this is a good compromise short of making the default fee 0.01. It's not so much to ask that free transactions can only be used to turn coins over so often. If you're using free transactions, you're taking charity and there has to be some limit on how often you can use it with the same coins.\nWe've always said free transactions may be processed more slowly. You can help ensure your transactions go through quickly by adding -paytxfee=0.01."
	},
	{
		"id": 572,
		"type": "ignore",
		"date": "2010-11-20 17:24:20",
		"src": "https://bitcointalk.org/index.php?topic=1334.msg23097#msg23097",
		"q": "updated to SVN 186",
		"a": "Thanks m0mchil for keeping up on the updates!\nGPU miners, please upgrade as soon as possible to shut down the free transaction abuse! This version has the new priority-based limit on free transaction spam."
	},
	{
		"id": 573,
		"type": "ignore",
		"date": "2010-11-20 17:24:20",
		"src": "https://bitcointalk.org/index.php?topic=1334.msg23097#msg23097",
		"q": "Just updated to SVN 181 and fixed getwork patch to wait 60 seconds between rebuilding the block with new transactions. This is actually the behavior of the original client, was forgotten in the patch by mistake. Fixes heavy CPU usage on every getwork request (this became obvious with recent heavy transaction spam). Please upgrade.",
		"a": "Before SVN 184, compiling transactions into a block used an n^2 algorithm. The new efficient single-pass algorithm is orders of magnitude quicker. (O(n) vs O(n^2)/2 algorithm, n=200 maybe 10 to 100 times quicker)"
	},
	{
		"id": 574,
		"type": "ignore",
		"date": "2010-11-23 20:55:27",
		"src": "https://bitcointalk.org/index.php?topic=1901.msg23891#msg23891",
		"q": "I understand the use case for external miners, but I rather like the all-in-one approach. Will I still be able to compile in my own mining code? I really enjoyed the revamped interface you introduced some time ago, and would very much like to keep on using it.",
		"a": "It's not an exact drop-in replacement. I wanted to clean up the interface a little. It only requires a few changes.\nScanHash_ functions aren't going away. BTW, the interface of this is designed to mirror the parameters of that (midstate, data, hash1)."
	},
	{
		"id": 575,
		"date": "2010-11-24 17:21:01",
		"src": "https://bitcointalk.org/index.php?topic=1901.msg24095#msg24095",
		"q": "I suspect something weird going on with ByteReverse (or lack thereof). It's quite unclear whether or not 'data' and 'nonce' must be byte-reversed, and in what way.",
		"a": "getwork does the byte-reversing. midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don't have to do any byte-reversing. They're the same data that is passed to the ScanHash_ functions. You can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1, nHashesDone). If a nonce is found, patch it into data and call getwork.\nI should probably change the ScanHash_ functions to use pdata instead of pdata + 64 so they're consistent.\ntarget is little endian, it's supposed to be the same as how m0mchil's did it. (if it's not, then it should be fixed) That's the only case where you would use byte reverse. I think you do it like: if ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6]."
	},
	{
		"id": 576,
		"date": "2010-11-24 17:21:01",
		"src": "https://bitcointalk.org/index.php?topic=1901.msg24095#msg24095",
		"q": "Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification",
		"a": "This is the new spec. It shouldn't be hard to update your miner to use it.\nThe changes are:\n- It does not return work when you submit a possible hit, only when called without parameter.\n- The block field has been split into data and hash1.\n- state renamed to midstate for consistency.\n- extranonce not needed."
	},
	{
		"id": 577,
		"type": "ignore",
		"date": "2010-11-24 17:53:09",
		"src": "https://bitcointalk.org/index.php?topic=1334.msg24101#msg24101",
		"q": "Hi m0mchil, firstly thank you for your work. Is there any way to include getwork patch into official client? I'm using bitcoin on old centos server and compiling is pain here!",
		"a": "A revised version of getwork is now in the official client, but the miners need to be updated a little to use it."
	},
	{
		"id": 578,
		"date": "2010-11-25 17:51:39",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438",
		"q": "Indeed, shipping the data with the client is just a kludge.\nIf the main reason that the bitcoin P2P protocol is so inefficient in transferring large amounts of blocks, that should be fixed. I think that's because of the HDD syncing going on. Maybe this should be held off for the initial download, or the protocol should be made more bittorrent-like for the blocks [0..last-10000], as they are basically set in stone.",
		"a": "It's not the downloading that takes the time, it's verifying and indexing it.\nBandwidthwise, it's more efficient than if you downloaded an archive. Bitcoin only downloads the data in blk0001.dat, which is currently 55MB, and builds blkindex.dat itself, which is 47MB. Building blkindex.dat is what causes all the disk activity.\nDuring the block download, it only flushes the database to disk every 500 blocks. You may see the block count pause at ??499 and ??999. That's when it's flushing.\nDoing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.\nMaybe Berkeley DB has some tweaks we can make to enable or increase cache memory."
	},
	{
		"id": 579,
		"date": "2010-11-26 17:32:01",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg24662#msg24662",
		"q": "Which of the ACID properties do you need, while downloading?\nAdding BDB records is simply appending to a log file, until you issue a checkpoint. The checkpoint then updates the main database file.\nUnder a normal BDB transaction, you are guaranteed that each log record will be sync'd to disk platter, before the transaction commit succeeds. This is very strict, but required for full ACID. Enabling DB_TXN_NOSYNC still gives you a lot:\n\"database integrity will be maintained, but if the application or system fails, it is possible\nsome number of the most recently committed transactions may be undone during recovery\"\nbitcoin can obviously recover if recent transactions are undone, so, it seems useful for this flag to be set for 100% of the initial block download.\nThat leaves checkpointing, which is a balance between amount of work performed at checkpoint time -- number of records that must be copied from log to database file -- and wall clock time. Just gotta try some values and see what \"feels\" right -- maybe checkpoint every 10,000 blocks?",
		"a": "I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck. Initial download took 1 hour 20 minutes.\nIf it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong. It would be nice to know what appears to be the bottleneck when that happens.\nEvery 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node. When the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest. At least, that's how it should work."
	},
	{
		"id": 580,
		"date": "2010-11-26 17:32:01",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg24662#msg24662",
		"q": "Which of the ACID properties do you need, while downloading?",
		"a": "It may only need more read caching. It has to read randomly all over blk0001.dat and blkindex.dat to index. It can't assume the file is smaller than memory, although it currently still is. Caching would be effective, since most dependencies are recent.\nSomeone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars."
	},
	{
		"id": 581,
		"date": "2010-11-26 17:32:01",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg24662#msg24662",
		"q": "Adding BDB records is simply appending to a log file, until you issue a checkpoint. The checkpoint then updates the main database file.",
		"a": "We checkpoint every 500 blocks."
	},
	{
		"id": 582,
		"date": "2010-11-26 18:23:30",
		"src": "https://bitcointalk.org/index.php?topic=1946.msg24673#msg24673",
		"q": "Who's in charge of the OSX build? Given it usually lags behind I assume it is done by someone not using OSX as the primary OS. I can help with this if that's the case, just point me to how things are done right now.",
		"a": "Laszlo does them, but I haven't asked him to do one for a while because there wasn't anything major. I'll ask him to do this version."
	},
	{
		"id": 583,
		"date": "2010-11-26 21:31:13",
		"src": "https://bitcointalk.org/index.php?topic=1901.msg24708#msg24708",
		"q": "It would be immensely useful if you'd return if what I sent to the client actually was an actual hit. It makes it easier to debug issues in miners due to sanity checking.",
		"a": "That's what it does, it returns true/false."
	},
	{
		"id": 584,
		"type": "ignore",
		"date": "2010-11-26 22:02:41",
		"src": "https://bitcointalk.org/index.php?topic=1925.msg24719#msg24719",
		"q": "It's been tested with jansson 1.2 and 1.3 release versions.\nIf you lack jansson, current cpuminer.git will build an in-tree version. Thus, you may opt to fix the problem by... removing jansson from your system.",
		"a": "You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp. It compiles fine as a C file, just rename sha256.cpp to sha256.c. I was able to get it to work in simple tests on Windows, but not when linked in with Bitcoin. It may have a better chance of working as part of a C program instead of C++.\nCurrently it's only enabled in the Linux build, so if you get it to work you could make it available to Windows users. It's about 100% speedup on AMD CPUs."
	},
	{
		"id": 585,
		"type": "favorite",
		"date": "2010-11-28 16:03:30",
		"src": "https://bitcointalk.org/index.php?topic=1976.msg25119#msg25119",
		"q": "I think I initially misunderstood the blocks in that the hashes that we compute are independent of the address. Now, I believe that we are looking for something like sha256 (bitcoint address + amount (I am not sure whether the value is implicit, so this value might not be there) + <answer>) with some desired properties (of which the number of final zeros is an approximation), where + means some concatenation operator of bits.\nIf the computation is like that, _then_ it might work, but I don't see why someone cannot just only send you the worthless hashes (for you) and don't send those that are useful to you. By this mechanism they can bankrupt you. Anyway, I think it is a bad way to communicate with natural language only about these topics. Just write out the computations that you intend to do on the server and the client and then we can see whether it is a brilliant idea or a flawed one. Annotations on the computations as to which goal they intend to achieve is also useful for communication.\nForcing cooperation out of nodes is not easy.",
		"a": "ribuck's description is spot on.\nPool operators can modify their getwork to take one additional parameter, the address to send your share to.\nThe easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as:\nuser's near-hits/total near-hits from everyone\nThat would be easier and safer to start up. It also has the advantage that multiple hits from the same user can be combined into one transaction. A lot of your hits will usually be from the same people.\nThe instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.\nEither way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.\nNew users wouldn't really even need the Bitcoin software. They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone's pool server. When the miner says it found something, a while later a few coins show up in their account.\nMiner writers better make sure they never false-positive near-hits. Users will depend on that to check if the pool operator is cheating them. If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator."
	},
	{
		"id": 586,
		"type": "ignore",
		"date": "2010-11-28 17:13:01",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138",
		"q": "My understanding was that the client already did a blockchain recheck upon startup if the index was missing. I did this when I first started, and it sure seemed like it was marching through the chain. Doesn't it require an index to function anyway? Why would it assume that the blockchain was valid upon startup? Anyone could have edited it. The genesis block is encoded into the client, isn't it? That and the blockchain checkpoints are the only parts that are assumed correct, or am I wrong? There is no good reason to prevent a blockchain download via other methods. In a future with the bitcoin network running close to it's capacity, downloading the entire blockchain over the P2P network will be harmful.\nEven a chain that has already been pruned of it's merkle trees should be able to be verified from the start, otherwise what good is using a merkle tree at all?",
		"a": "Despite everything else said, the current next step is:"
	},
	{
		"id": 587,
		"type": "ignore",
		"date": "2010-11-28 17:13:01",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138",
		"q": "Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.",
		"a": "In particular, I suspect that more read caching might help a lot."
	},
	{
		"id": 588,
		"type": "ignore",
		"date": "2010-11-28 17:13:01",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138",
		"q": "Another new user on IRC, Linux this time, was downloading at a rate of 1 block every 4 seconds -- estimated total download time around 4 days.",
		"a": "Then something more specific was wrong. That's not due to normal initial download time. Without more details, it can't be diagnosed. If it was due to slow download, did it speed up after 10-20 minutes when the next block broadcast should have made it switch to a faster source? debug.log might have clues. How fast is their Internet connection? Was it steadily slow, or just slow down at one point?"
	},
	{
		"id": 589,
		"type": "ignore",
		"date": "2010-11-28 17:13:01",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138",
		"q": "We have the hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so there's no reason why we shouldn't be able to automatically download a compressed zipfile of the block database from anywhere, unpack it, verify it, and start running.",
		"a": "The 74000 checkpoint is not enough to protect you, and does nothing if the download is already past 74000. -checkblocks does more, but is still easily defeated. You still must trust the supplier of the zipfile.\nIf there was a \"verify it\" step, that would take as long as the current normal initial download, in which it is the indexing, not the data download, that is the bottleneck."
	},
	{
		"id": 590,
		"type": "ignore",
		"date": "2010-11-28 17:13:01",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138",
		"q": "Presumably at some point there will be a lightweight client that only downloads block headers, but there will still be hundreds of thousands of those...",
		"a": "80 bytes per header and no indexing work. Might take 1 minute."
	},
	{
		"id": 591,
		"type": "ignore",
		"date": "2010-11-28 17:13:01",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138",
		"q": "uncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer.",
		"a": "The data is mostly hashes and keys and signatures that are uncompressible.\nThe speed of initial download is not a reflection of the bulk data transfer rate of the protocol. The gating factor is the indexing while it downloads."
	},
	{
		"id": 592,
		"type": "ignore",
		"date": "2010-11-28 18:06:39",
		"src": "https://bitcointalk.org/index.php?topic=1986.msg25154#msg25154",
		"q": "Will it be synchronized automatically?",
		"a": "Very much not. Using multiple copies of wallet.dat is not recommended or supported, in fact all of Bitcoin is designed to defeat that. Both copies will get screwed up.\nIf you're trying to consolidate your generated coins into one wallet, a better solution now is to run getwork miners on the additional systems. jgarzik has a CPU miner, and it supports tcatm's 4-way SSE2, so on Windows it's up to twice as fast as the built-in SHA if you have an AMD or recent Intel (core 3, 5 or 7).\nNew demonstration CPU miner available:\nhttp://bitcointalk.org/index.php?topic=1925.0"
	},
	{
		"id": 593,
		"type": "ignore",
		"date": "2010-11-29 20:19:12",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25449#msg25449",
		"q": "The following code in AddToBlockIndex(main.cpp) is horribly inefficient, and dramatically slows initial block download:\nCTxDB txdb;\ntxdb.WriteBlockIndex(CDiskBlockIndex(pindexNew));\n// New best\nif (pindexNew->bnChainWork > bnBestChainWork)\nif (!SetBestChain(txdb, pindexNew))\nreturn false;\ntxdb.Close();\nThis makes it impossible to use a standard technique for loading large amounts of records into a database (db4 or SQL or otherwise): wrap multiple record insertions into a single database transaction. Ideally, bitcoin would only issue a TxnCommit() for each 1000 blocks or so, during initial block download. If a crash occurs, the database remains in a consistent state.\nFurthermore, database open + close for each new block is incredibly expensive. For each database-open and database-close operation, db4\ndiagnose health of database, to determine if recovery is needed. this test may require data copying.re-init memory poolsread database file metadataacquire file locksread and initialize b-tree or hash-specific metadata. build hash table / b-tree roots.forces a sync, even if transactions called with DB_TXN_NOSYNCfsync memory pool\nAnd, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.\nThat's right, that long list of operations is executed per-database (DB), not per-environment (DB_ENV), for a database close+open cycle. To bitcoin, that means we do this for every new block. Incredibly inefficient, and not how db4 was designed to be used.\n1) bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown. db4 is designed to handle crashes, if proper transactional use is maintained -- and bitcoin already uses db4 transactions properly.\n2) For the initial block download, txn commit should occur once every N records, not every record. I suggest N=1000.\nUpdated a couple minor details, and corrected some typos.",
		"a": "It seems like you're inclined to assume everything is wrong more than is actually so.\nWriting the block index is light work. Building the tx index is much more random access per block. I suspect reading all the prev txins is what's slow. Read caching would help that. It's best if the DB does that. Maybe it has a setting for how much cache memory to use."
	},
	{
		"id": 594,
		"type": "ignore",
		"date": "2010-11-29 20:19:12",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25449#msg25449",
		"q": "1) bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown.",
		"a": "Already does that. See CDB. The lifetime of the (for instance) CTxDB object is only to support database transactions and to know if anything is still using the database at shutdown."
	},
	{
		"id": 595,
		"type": "ignore",
		"date": "2010-11-29 20:19:12",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25449#msg25449",
		"q": "And, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.",
		"a": "If it was doing that it would be much slower. It's supposed to be only once a minute or 500 blocks:\nif (strFile == \"blkindex.dat\" && IsInitialBlockDownload() && nBestHeight % 500 != 0)\nnMinutes = 1;\ndbenv.txn_checkpoint(0, nMinutes, 0);\nProbably should add this:\nif (!fReadOnly)\ndbenv.txn_checkpoint(0, nMinutes, 0);"
	},
	{
		"id": 596,
		"type": "ignore",
		"date": "2010-11-29 20:19:12",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg25449#msg25449",
		"q": "2) For the initial block download, txn commit should occur once every N records, not every record. I suggest N=1000.",
		"a": "Does transaction commit imply flush? That seems surprising to me. I assume a database op wrapped in a transaction would be logged like any other database op. Many database applications need to wrap almost every pair of ops in a transaction, such as moving money from one account to another. (debit a, credit b) I can't imagine they're required to batch all their stuff up themselves.\nIn the following cases, would case 1 flush once and case 2 flush twice?\ncase 1:\nwrite\nwrite\nwrite\nwrite\ncheckpoint\ncase 2:\nbegin transaction\nwrite\nwrite\ncommit transaction\nbegin transaction\nwrite\nwrite\ncommit transaction\ncheckpoint\nContorting our database usage will not be the right approach. It's going to be BDB settings and caching."
	},
	{
		"id": 597,
		"type": "ignore",
		"date": "2010-11-30 19:02:31",
		"src": "https://bitcointalk.org/index.php?topic=2007.msg25799#msg25799",
		"q": "Bitcoin version 3.17.1 beta\nDefault data directory /home/david/.bitcoin\nBound to port 8333\nbitcoin server starting\nLoading addresses...\ndbenv.open strLogDir=/home/david/.bitcoin/database strErrorFile=/home/david/.bitcoin/db.log\nLoaded 5017 addresses\naddresses 122ms\nLoading block index...\nLoadBlockIndex(): hashBestChain=00000000000013587f18 height=94571\nblock index 1294ms\nLoading wallet...\n************************\nEXCEPTION: NSt8ios_base7failureE\nCDataStream::read() : end of data\nbitcoin in AppInit()\nterminate called after throwing an instance of 'std::ios_base::failure'\n************************\nEXCEPTION: NSt8ios_base7failureE\nCDataStream::read() : end of data\nbitcoin in AppInit()\nwhat(): CDataStream::read() : end of data",
		"a": "What was this wallet used with? An early accounts patch or git build?\nIt's while loading the wallet. I assume it must be in this:\nelse if (strType == \"acentry\")\n{\nstring strAccount;\nssKey >> strAccount;\nuint64 nNumber;\nssKey >> nNumber;\nif (nNumber > nAccountingEntryNumber)\nnAccountingEntryNumber = nNumber;\n}\nYou could check that with this:\nelse if (strType == \"acentry\")\n{\nstring strAccount;\nassert(!ssKey.empty());\nssKey >> strAccount;\nuint64 nNumber;\nif (ssKey.size() != 8 )\nprintf(\"***** %s %d\n\", strAccount.c_str(), ssKey.size());\nassert(ssKey.empty() == false);\nssKey >> nNumber;\nif (nNumber > nAccountingEntryNumber)\nnAccountingEntryNumber = nNumber;\n}\nWas there an interim version of accounts on git at some point that had just (\"acentry\", \"account\") for the key?\nIf you have gdb, you could run it in gdb and do a backtrace.\ngdb --args bitcoin ...\nrun\n(wait for exception)\nbt"
	},
	{
		"id": 598,
		"type": "ignore",
		"date": "2010-12-01 21:25:39",
		"src": "https://bitcointalk.org/index.php?topic=1931.msg26016#msg26016",
		"q": "I timed two runs with clean data directories (no contents), -noirc, -addnode=10.10.10.1, Linux 64-bit. Hardware: SATA SSD\nMainline, no patches:\n32 minutes to download 94660 blocks.\nMainline + TxnBegin/TxnCommit in AddToBlockIndex():\n25 minutes to download 94660 blocks.",
		"a": "That's a good optimisation. I'll add that next time I update SVN.\nMore generally, we could also consider this:\ndbenv.set_lk_max_objects(10000);\ndbenv.set_errfile(fopen(strErrorFile.c_str(), \"a\")); /// debug\ndbenv.set_flags(DB_AUTO_COMMIT, 1);\n+ dbenv.set_flags(DB_TXN_NOSYNC, 1);\nret = dbenv.open(strDataDir.c_str(),\nDB_CREATE |\nDB_INIT_LOCK |\nDB_INIT_LOG |\nWe would then rely on dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes."
	},
	{
		"id": 599,
		"type": "favorite",
		"date": "2010-12-05 09:08:08",
		"src": "https://bitcointalk.org/index.php?topic=1735.msg26999#msg26999",
		"q": "Basically, bring it on. Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.",
		"a": "No, don't \"bring it on\".\nThe project needs to grow gradually so the software can be strengthened along the way.\nI make this appeal to WikiLeaks not to try to use Bitcoin. Bitcoin is a small beta community in its infancy. You would not stand to get more than pocket change, and the heat you would bring would likely destroy us at this stage."
	},
	{
		"id": 600,
		"type": "ignore",
		"date": "2010-12-08 20:21:49",
		"src": "https://bitcointalk.org/index.php?topic=2151.msg28228#msg28228",
		"q": "Surely since the WalletTx are added sequentially to the wallet, we can assume that older txid's appear earlier in the wallet?\nThen it's simply trivial to do a linear lookup and then continue on spitting out the txid's after that one.\nCan anyone confirm this?",
		"a": "It's not safe to use listtransactions this way.\nI know I've been criticized for being reluctant about listtransactions. Let me explain my reluctance.\nTransactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.\nProgrammers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:\n1) How do you know if a past transaction becomes invalid and disappears?\n2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.\n3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.\nThe model where you assume you only need to see new transactions because you've already seen previous transactions is not true. Old transactions can change at any time.\nAny time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.\nNow that we have the Accounts feature making it easier to do it the right way, we're better prepared to have listtransactions."
	},
	{
		"id": 601,
		"type": "ignore",
		"date": "2010-12-08 22:36:45",
		"src": "https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292",
		"q": "At some point, a website or person accepting a transaction must take this risk. It is unavoidable, whether you use listreceivedbyaddress or listtransactions. This is why listtransactions reluctance seems so unusual.\nAlmost every exchange or website accepting bitcoins achieves a binary decisionpoint, where the transaction is accepted, and goods are shipped or money is exchanged. After that binary decisionpoint, even if the block chain is reorg'd or transactions disappear, there is nothing the website can do but take a loss (or pursue a refund outside of bitcoin).\nFrom the website's point of view, there is zero effective difference between 'listtransactions 6' and 'listreceivedbyaddress 6', because the end result to the website operator is the same: the goods have been shipped / order accepted / money exchanged.",
		"a": "Then how do you cope with the issues I listed in the message you quoted?"
	},
	{
		"id": 602,
		"type": "ignore",
		"date": "2010-12-09 00:12:17",
		"src": "https://bitcointalk.org/index.php?topic=2151.msg28313#msg28313",
		"q": "So it would be a design problem in the developper's app, not a problem inherent to listtransactions. What you're saying is: if listtransactions is used without care, it can be dangerous. OK, but many programmatic tools have traps too. For example, programming with threads is full of design traps. That doesn't mean that that tool shouldn't be made available to developpers, but that the documentation must warn strongly about those traps.\nMy point: let's make listtransactions available, but document it precisely, like any API, and explain the design mistakes that shouldn't be made when using it.",
		"a": "I'm not talking about the normal risk for a given minconf level, I'm talking about additional pitfalls from listtransactions when used this way."
	},
	{
		"id": 603,
		"type": "ignore",
		"date": "2010-12-09 00:12:17",
		"src": "https://bitcointalk.org/index.php?topic=2151.msg28313#msg28313",
		"q": "2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.",
		"a": "The OP's example of listtransactions <account> [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case. It would be very easy to double-count payments if you don't maintain your own persistent map or dictionary to track which txid's you've already accepted.\nIt doesn't seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap."
	},
	{
		"id": 604,
		"type": "ignore",
		"date": "2010-12-09 00:12:17",
		"src": "https://bitcointalk.org/index.php?topic=2151.msg28313#msg28313",
		"q": "listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.",
		"a": "Suppose both spends are to the same address. getreceivedbyaddress would always count only one or the other spend at any given time, never both.\nUsing listtransactions, it would be very easy to count both. You see the first spend, you count it. You see the second spend, you count it. Total is double counted."
	},
	{
		"id": 605,
		"date": "2010-12-09 14:37:05",
		"src": "https://bitcointalk.org/index.php?topic=2162.msg28533#msg28533",
		"q": "Well I spport Satoshi completely in this matter.\nLeaving a possibility to store data in bitcoin chain is an accident waiting to happen. Just wait until somebody encodes kiddie porn into the chain - it would stay there forever. And the governments would have a perfect propaganda possibility for fighting it. \"Normal\" people won't use bitcoin at all if it is associated with perverts, mafia, and financial scams.",
		"a": "New transaction templates can be added as needed. Within a few days, there will be plenty of GPU power that accepts and works on it. Network support will be thorough long before there'll be enough clients who understand how to receive and interpret the new transaction.\nTimestamp hashes are still already possible:\ntxin: 0.01\ntxout: 0.00 <appid, hash> OP_CHECKSIG\nfee: 0.01\nIf there's an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.\nI like Hal Finney's idea for user-friendly timestamping. Convert the hash of a file to a bitcoin address and send 0.01 to it:"
	},
	{
		"id": 606,
		"type": "favorite",
		"date": "2010-12-09 15:17:53",
		"src": "https://bitcointalk.org/index.php?topic=2162.msg28549#msg28549",
		"q": "Several months ago, around the time when the 0.3.9 bugs were found, I privately told Satoshi that I thought whitelisting acceptable transaction types was a better way to go, rather than blacklisting transaction types that we find out cause problems.\nThe danger is similar websites that try to blacklist <script> tags in HTML entered by users to prevent cross-site-scripting hacks. See http://ha.ckers.org/xss.html for a nice sampling of how creative hackers can be.\nI haven't asked Satoshi if the recent discussion of BitDNS putting extra data in the block chain swayed his opinion or if he woke up in the middle of the night and realized that a creative use of OP_SOMETHING might lead to an exploit. I don't think it matters; I'm still convinced that whitelisting acceptable transaction types is the right thing to do.\nAs for \"the above option was thrown out by the developers\" -- nothing has been thrown out! Again, I haven't talked to Satoshi, but I'm open to the idea of a third 'standard' transaction type that includes extra, arbitrary data. Lets have that discussion, implement it on the -testnet, poke at it, try to imagine all the possible ways it can be misused, try to estimate the benefits and costs... and if there's general consensus that it is a good idea, roll it into production.",
		"a": "I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added."
	},
	{
		"id": 607,
		"type": "favorite",
		"date": "2010-12-09 15:17:53",
		"src": "https://bitcointalk.org/index.php?topic=2162.msg28549#msg28549",
		"q": "why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?",
		"a": "That's already possible. <pubkey> OP_CHECKSIG. <pubkey> can be 33 to 120 bytes.\nI also support a third transaction type for timestamp hash sized arbitrary data. There's no point not having one since you can already do it anyway. It would tell nodes they don't need to bother to index it."
	},
	{
		"id": 608,
		"date": "2010-12-09 18:08:08",
		"src": "https://bitcointalk.org/index.php?topic=2151.msg28640#msg28640",
		"q": "I agree with you and satoshi about \"txs after <txid>\". My listtransactions (now xlisttransactions) patch pointedly does not have that feature, and never has.",
		"a": "As long as the interface is designed for things like showing the user the last N transactions history, it's fine, now that we have the Accounts feature making it easier to do payment detection the right way.\nGavin, could listtransactions have an option to list transactions for all accounts?\nI'm not sure what the interface could be, maybe:\nlisttransactions <JSON null type> [count]\nIt would be hard to do that from the command line though.\nI can't think of a good solution for the interface, that's the problem. Maybe \"*\" special case like \"\" is. Everyone would have to make sure no user can create account name \"*\"."
	},
	{
		"id": 609,
		"date": "2010-12-09 18:08:08",
		"src": "https://bitcointalk.org/index.php?topic=2151.msg28640#msg28640",
		"q": "Sure, and that's easy enough to track with transactions.",
		"a": "I don't get how that's \"easy\" to track with transactions."
	},
	{
		"id": 610,
		"type": "ignore",
		"date": "2010-12-09 18:28:45",
		"src": "https://bitcointalk.org/index.php?topic=644.msg28643#msg28643",
		"q": "Actually the openSuse Build Service is more meant for packages that have to be reliably built for a multitude of systems and updated consistently across all of the distros, but adding a small cron job can pull SVN and push the changes to the Build Service, kicking off a recompile. I wouldn't abuse it though.\nI think we should sooner or later add a continuous integration tool, to check code submissions against the (until now inexisting) unit tests. That would also be able to create nightly builds ^^",
		"a": "Thanks for setting this up Cdecker.\nIs there any chance of getting it to build the GUI version also? If this is Ubuntu, if you get wxWidgets 2.9.0 it should just be a matter of following the steps in build-unix.txt exactly. Is this an environment where you can build wxWidgets once and leave it there and just keep using it?"
	},
	{
		"id": 611,
		"date": "2010-12-09 21:02:42",
		"src": "https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696",
		"q": "Our code repository is non-existent and we're still debating the best route for DomainChain/BitDNS.\n* kiba is anxious.",
		"a": "I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.\nThe networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.\nI think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.\nInstead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners."
	},
	{
		"id": 612,
		"date": "2010-12-09 22:46:50",
		"src": "https://bitcointalk.org/index.php?topic=1790.msg28715#msg28715",
		"q": "seems that the miner would have to basically do \"extra work\". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?",
		"a": "The incentive is to get the rewards from the extra side chains also for the same work.\nWhile you are generating bitcoins, why not also get free domain names for the same work?\nIf you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.\nYou have one piece of work. If you solve it, it will solve a block from both Bitcoin and BitDNS. In concept, they're tied together by a Merkle Tree. To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.\nIn practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal. You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility. We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.\nNote that the chains are below this new Merkle Tree. That is, each of Bitcoin and BitDNS have their own chain links inside their blocks. This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain. This is two timestamp servers not sharing a chain."
	},
	{
		"id": 613,
		"date": "2010-12-09 23:58:54",
		"src": "https://bitcointalk.org/index.php?topic=2181.msg28729#msg28729",
		"q": "See the discussion of locktime for transaction replacement.",
		"a": "Not locktime.\nThere's a possible design for far in the future:\nYou intentionally write a double-spend. You write it with the same inputs and outputs, but this time with a fee. When your double-spend gets into a block, the first spend becomes invalid. The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.\nIt's easier said than implemented. There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases. Every assumption in the existing code is that you're not trying to write double-spends.\nThere would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher. Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block."
	},
	{
		"id": 614,
		"type": "favorite",
		"date": "2010-12-10 17:29:28",
		"src": "https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917",
		"q": "Got you now. Yes, keeping two chains synchronised is fraught with difficulty.",
		"a": "Piling every proof-of-work quorum system in the world into one dataset doesn't scale.\nBitcoin and BitDNS can be used separately. Users shouldn't have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.\nThe networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.\nFears about securely buying domains with Bitcoins are a red herring. It's easy to trade Bitcoins for other non-repudiable commodities.\nIf you're still worried about it, it's cryptographically possible to make a risk free trade. The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both. The second signer can't release one without releasing the other."
	},
	{
		"id": 615,
		"date": "2010-12-10 19:55:12",
		"src": "https://bitcointalk.org/index.php?topic=1790.msg28959#msg28959",
		"q": "additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?",
		"a": "Right, the exchange rate between domains and bitcoins would float.\nA longer interval than 10 minutes would be appropriate for BitDNS.\nSo far in this discussion there's already a lot of housekeeping data required. It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin's chain. Some transactions:\nChanging the IP record.\nName change. A domain object could entitle you to one domain, and you could change it at will to any name that isn't taken. This would encourage users to free up names they don't want anymore. Generated domains start out blank and the miner sells it to someone who changes it to what they want.\nRenewal. Could be free, or maybe require consuming another domain object to renew. In that case, domain objects (domaincoins?) could represent the right to own a domain for a year. The spent fee goes to the miners in the next block fee."
	},
	{
		"id": 616,
		"type": "favorite",
		"date": "2010-12-10 20:19:39",
		"src": "https://bitcointalk.org/index.php?topic=1790.msg28963#msg28963",
		"q": "OK so if there are going to be bitdnscoins (aka DCCs, DomainChain Coins) then they have to be useful for something. Otherwise every BitDNS miner is going to fill every block with his own domain name registrations, rather than replace one with someone else's registration in exchange for a transaction fee in a useless currency.\nThe rules have to be that you have to spend a certain amount of bitdnscoins/DCCs in order to register your names and/or do other BitDNS transactions. That's the only way to make this alternative currency desirable and valuable.\n(Well we could do like Bitcoin and say there would only ever be 22 million DCCs ever created, so they'd get valuable from scarcity just like bitcoins. But that seems weak.)",
		"a": "I agree. All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.\nYou might consider a certain amount of work to generate a domain, instead of a fixed total circulation. The work per domain could be on a schedule that grows with Moore's Law. That way the number of domains would grow with demand and the number of people using it."
	},
	{
		"id": 617,
		"date": "2010-12-11 13:08:30",
		"src": "https://bitcointalk.org/index.php?topic=1790.msg29159#msg29159",
		"q": "This seems like a sound plan. It includes the proposal of theymos and nanotube and includes what satoshi is wanting. I like the fact that there is no free lunch and everyone would have to pay their way.",
		"a": "@dtvan: all 3 excellent points.\n1) IP records don't need to be in the chain, just do registrar function not DNS. And CA problem solved, neat.\n2) Pick one TLD, .web +1.\n3) Expiration and significant renewal costs, very important."
	},
	{
		"id": 618,
		"date": "2010-12-11 13:08:30",
		"src": "https://bitcointalk.org/index.php?topic=1790.msg29159#msg29159",
		"q": "However, thinking more about this now I support inclusion of additional coinbases / tracking systems in the main network. The reason for doing this is so as not to water down CPU power into multiple networks. We want one strong network, so the network should be versatile.",
		"a": "Avoiding CPU power fragmentation is no longer a reason. Independent networks/chains can share CPU power without sharing much else. See: http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696 and http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715"
	},
	{
		"id": 619,
		"date": "2010-12-11 13:32:37",
		"src": "https://bitcointalk.org/index.php?topic=2208.msg29165#msg29165",
		"q": "direct to IP address transfers seems like a obvious surface area to attack.",
		"a": "If you ever find anyone who turned it on. It's disabled by default."
	},
	{
		"id": 620,
		"date": "2010-12-11 13:32:37",
		"src": "https://bitcointalk.org/index.php?topic=2208.msg29165#msg29165",
		"q": "There is no way to be absolutely sure that there are no buffer overflow attacks. Although it would help to implement the client in a language that doesn't have buffer overflows because it checks array indices (Python, Java, C#, ...).",
		"a": "It's all STL. There are almost no buffers."
	},
	{
		"id": 621,
		"type": "favorite",
		"date": "2010-12-11 22:07:04",
		"src": "https://bitcointalk.org/index.php?topic=2188.msg29259#msg29259",
		"q": "I'd like to hear some specific criticisms of the code. To me it looks like an impressive job, although I'd wish for more comments. Now I've mostly studied the init, main, script and a bit of net modules. This is some powerful machinery.",
		"a": "That means a lot coming from you, Hal. Thanks."
	},
	{
		"id": 622,
		"type": "favorite",
		"date": "2010-12-11 23:39:16",
		"src": "https://bitcointalk.org/index.php?topic=2216.msg29280#msg29280",
		"q": "This article is surprisingly balanced and accurate for a mainstream publication.\nPC World is a big deal. I am psycheless. Time to restore the Wikipedia article.",
		"a": "It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us."
	}
]